Interviewfragen für Security Engineer

Praktisch nein. AES-128 erfordert bereits etwa 2^128 Aufwand für Brute Force — völlig undurchführbar — daher macht AES-256 dich gegen Brute Force nicht spürbar sicherer; es gibt vor allem Reserve (post-quanten Spielraum, Compliance). Beide sind standardisiert und ungebrochen. Dein Modus (GCM), Nonce-Handhabung und Schlüsselverwaltung zählen weit mehr als 128 gegen 256. „AES-256 ist doppelt so sicher“ ist der Irrtum.

Nein. Man kann die rohe Schlüssellänge nicht über verschiedene Algorithmusfamilien hinweg vergleichen. Wegen der Art, wie die zugrunde liegende Mathematik jeweils härtet, bietet ein 256-Bit-Schlüssel auf elliptischer Kurve etwa dieselbe Sicherheit wie ein 3072-Bit-RSA-Schlüssel — rund 128 Bit Stärke, laut NIST. Größer ist nicht einfach stärker: ECC erreicht gleichwertige Stärke mit weit kleineren Schlüsseln, weshalb moderne Systeme es bevorzugen. Innerhalb eines Algorithmus helfen längere Schlüssel sehr wohl, bis zu einem Punkt.

Nein. Die drei Kategorien von Authentifizierungsfaktoren sind etwas, das man weiß (Passwort/PIN), etwas, das man hat (Token/Telefon) und etwas, das man ist (Biometrie). Ein Fingerabdruck oder Gesichtsscan gehört zu „etwas, das man ist“, einem gemessenen physischen Merkmal. Der Haken: Biometrie ist kein Geheimnis und lässt sich nicht erneuern — leckt die Vorlage deines Fingerabdrucks, kannst du deinen Fingerabdruck nicht ändern. Deshalb funktioniert Biometrie am besten als ein Faktor, der oft einen lokalen Schlüssel entsperrt, statt als eigenständiger Passwortersatz.

Nein. Das Löschen des Cookies entfernt nur die Anmeldedaten aus deinem Browser — der Session-Datensatz (oder ein noch gültiges JWT) auf dem Server bleibt typischerweise nutzbar, bis er abläuft oder explizit invalidiert wird. Ein Angreifer, der das Token bereits abgegriffen hat, kann es weiter nutzen. Der Irrtum hält das Cookie für die Session selbst; es ist nur ein Zeiger auf serverseitigen Zustand. Echtes Abmelden muss die Session serverseitig invalidieren oder das Token widerrufen und mit kurzer TTL versehen.

Nicht zwangsläufig. Doppelte Verschlüsselung mit demselben Algorithmus verdoppelt die Sicherheit nicht einfach — das klassische Ergebnis ist, dass 2DES wegen Meet-in-the-Middle-Angriffen nur etwa ein Bit effektive Stärke hinzufügt, weshalb es 3DES gibt. Wichtiger noch: Selbstgebaute Mehrschichtschemata neigen dazu, Implementierungsfehler einzuführen, die das Ganze schwächen. Nutze stattdessen ein gut geprüftes authentifiziertes Verfahren (AES-GCM) mit solider Schlüsselverwaltung.

Größtenteils nein. Der Ziel-Hostname wird im Klartext in der SNI-Erweiterung des TLS-ClientHello gesendet, und Ihre DNS-Abfrage verrät ihn meist ebenfalls, sodass ein Provider oder Netzwerk sehen kann, WELCHE Seite Sie besuchen — selbst über HTTPS. Sie können nur den Pfad und Inhalt nicht lesen. Encrypted ClientHello (ECH) und DNS-over-HTTPS können diese Lücke schließen, sind aber nicht universell. „HTTPS verbirgt alles“ ist der Irrtum.

Nein. TLS/HTTPS sichert Daten bei der Übertragung zwischen Client und Server; nach dem Empfang werden sie von der App entschlüsselt und im Klartext verarbeitet und dann je nach Datenbankkonfiguration gespeichert. Daten im Ruhezustand zu schützen ist ein eigenes Thema — Datenträger-/Spaltenverschlüsselung, ein KMS und Zugriffskontrolle. „Wir nutzen HTTPS“ mit „unsere gespeicherten Daten sind verschlüsselt“ zu verwechseln ist ein verbreiteter und gefährlicher Irrtum.

Nein. Der ganze Bereich 127.0.0.0/8 ist für Loopback reserviert, also lösen 127.0.0.2, 127.1.1.1 und so weiter alle zum lokalen Host auf. Das ist wichtig für SSRF und das Umgehen von Allow-Lists — ein Angreifer kann 127.0.0.2 oder andere Kodierungen nutzen, um eine naive Prüfung „127.0.0.1 blockieren“ zu umgehen — und für das Binden mehrerer lokaler Dienste. (In IPv6 ist Loopback die einzelne Adresse ::1.)

Nein. MFA hebt die Hürde stark, aber OTP- und Push-Faktoren sind phishbar: Adversary-in-the-Middle-Kits (z. B. Evilginx) leiten Login und Code in Echtzeit weiter, und MFA-Müdigkeit/Push-Bombing bringt Nutzer zum Bestätigen. Abgefangene Codes sind innerhalb ihres kurzen Fensters wiederverwendbar. Der Irrtum ist „MFA = nicht phishbar”; entscheidend ist der Faktortyp. Phishing-resistente MFA — FIDO2/WebAuthn-Passkeys, an den Origin der Seite gebunden — ist das, was dies tatsächlich vereitelt.

Nein. NAT (und PAT) bildet private Adressen auf eine öffentliche IP ab und verwirft als Nebeneffekt unaufgeforderte eingehende Verbindungen, weil für sie keine Zuordnung existiert. Das ist keine Sicherheitsrichtlinie — keine Inspektion, keine Regeln, kein Logging — und NAT-Traversal, Hole Punching sowie ausgehend initiiertes C2 passieren ungehindert. NAT ist ein Adressierungswerkzeug; Sie brauchen trotzdem eine echte Firewall. „NAT = Firewall“ ist der Irrtum.

Nein. Ein Salt ist ein eindeutiger Zufallswert, der direkt neben dem Hash gespeichert wird; seine Aufgabe ist es, identische Passwörter unterschiedlich hashen zu lassen und vorberechnete Rainbow Tables zu vereiteln — nicht geheim zu bleiben. Es ist unproblematisch, wenn ein Angreifer, der die Datenbank stiehlt, auch die Salts erhält. Was Passwörter wirklich schützt, ist ein langsamer, gesalzener Hash (bcrypt, scrypt, Argon2). Ein separater, optionaler geheimer „Pepper“ ist ein anderes Konzept.

Nein. Ein VPN verschlüsselt den Traffic bis zum VPN-Server und verbirgt Ihre IP vor dem Ziel, aber der Anbieter kann Ihre Aktivität sehen und protokollieren, und Logins, Cookies sowie Browser-Fingerprinting identifizieren Sie weiterhin. Es verlagert das Vertrauen von Ihrem lokalen Netzwerk/Provider auf den VPN-Betreiber — das ist Privatsphäre gegenüber dem lokalen Netzwerk, keine Anonymität. Tor und strenge operative Disziplin sind andere Werkzeuge für ein anderes Ziel.

Passwortspeicherung braucht einen absichtlich langsamen, gesalzenen, speicherharten Hash — bcrypt, scrypt oder Argon2 — damit das Knacken gestohlener Hashes teuer ist und Rainbow Tables nicht greifen. Ein schneller Hash wie SHA-256 lässt sich im großen Maßstab trivial per Brute Force knacken; reversible Verschlüsselung bedeutet, dass eine einzige Schlüsselkompromittierung alle Passwörter auf einmal offenlegt; und Klartext ist unhaltbar, egal wie abgeriegelt die Datenbank ist. Wählen Sie Argon2id (oder bcrypt) mit einem abgestimmten Kostenfaktor und einem einzigartigen Salt pro Benutzer.

SSLv3, TLS 1.0 und RC4 sind gebrochen oder veraltet und ermöglichen Downgrade- und Entschlüsselungsangriffe; deaktivieren Sie sie daher und verlangen Sie TLS 1.2 oder 1.3 mit starken, forward-secret Cipher-Suiten, wobei der seltene Verlust sehr alter Clients in Kauf genommen wird. Sie aus Kompatibilitätsgründen aktiviert zu lassen, hält die Schwäche ausnutzbar. Ein zweites Zertifikat hinzuzufügen oder auf ein selbstsigniertes zu wechseln, entfernt die schwachen Protokolle nicht, und das selbstsignierte schadet dem Vertrauen, ohne die Kryptografie zu beheben.

Das Austrittsrisiko ist der verbleibende Zugriff, daher ist die zu verifizierende Kontrolle das zeitnahe Deprovisioning jedes Zugriffswegs — Verzeichniskonten, SSO, VPN, privilegierte und Dienstkonten sowie Drittanbieter-SaaS — abgeglichen mit dem Joiner/Mover/Leaver-Prozess (JML). Anzunehmen, die Personalabteilung erledige alles ohne Verifizierung, hinterlässt Lücken, die niemandem gehören. Das Konto „für den Fall der Rückkehr“ aktiv zu lassen ist ein dauerhaftes, unüberwachtes Risiko. Nur die E-Mail zu deaktivieren ignoriert die vielen anderen Systeme, die die Person noch erreichen könnte. Es geht darum, zu verifizieren, dass der Zugriff tatsächlich und vollständig entfernt ist, nicht darauf zu vertrauen.

Ungenutzte, überprivilegierte Dienstkonten sind bevorzugte Ziele und eine große Angriffsfläche. Inventarisieren Sie sie, deaktivieren oder löschen Sie die ungenutzten (mit Blick auf Ausfälle), beschränken Sie die verbleibenden auf Least Privilege und geben Sie jedem einen Eigentümer sowie eine wiederkehrende Überprüfung. Sie zu belassen ist ein dauerhaftes Risiko, pauschale Admin-Rechte maximieren den Schadensradius, und alles auf ein gemeinsames Konto zu konsolidieren zerstört Least Privilege und Nachvollziehbarkeit.

Ein Open Redirect in einem Authentifizierungsfluss erlaubt einem Angreifer, einen vertrauenswürdig wirkenden Login-Link zu basteln, der den Benutzer nach der Authentifizierung — und möglicherweise einen Autorisierungscode oder ein Token — an eine vom Angreifer kontrollierte Domain sendet und so Kontoübernahme und überzeugendes Phishing ermöglicht. Beheben Sie es, indem Sie exakte Redirect-URIs serverseitig streng per Allow-List freigeben und alles andere ablehnen. Es ist weder kosmetisch noch ein Performance-Problem, und HTTPS hilft nicht, weil das Ziel des Angreifers ebenfalls eine gültige HTTPS-Site sein kann.

Eine SUID-root-Binärdatei läuft mit Root-Rechten, und wenn sie für alle beschreibbar ist, kann ein Angreifer sie ersetzen oder verändern, um beliebigen Code als root auszuführen — ein klassischer Pfad zur lokalen Rechteausweitung. Entfernen Sie das SUID-Bit, korrigieren Sie Eigentümer und Berechtigungen und untersuchen Sie, wie die Fehlkonfiguration entstanden ist, da sie auf eine Kompromittierung hindeuten kann. Das Verschlüsseln der Datei lässt den ausführbaren Pfad intakt, und das Umbenennen verschiebt das Problem nur, ohne die Ausweitung zu beseitigen. Keine dieser Optionen behebt die Ursache.

Da Firewalls Regeln von oben nach unten auswerten, kurzschließt eine breite any/any-Erlauben-Regel nahe dem Anfang alle darunterliegenden Regeln und lässt allen Verkehr durch — die Firewall hört praktisch auf, irgendetwas durchzusetzen. Ersetzen Sie sie durch explizite Least-Privilege-Regeln für die tatsächlich benötigten Flüsse, so geordnet, dass spezifische Erlaubnisse und Verweigerungen wirken, abschließend mit einer Standardverweigerung. Sie effizient zu nennen ist falsch, sie ans Ende zu verschieben kann die Standardverweigerung weiterhin verdecken, und ein Umbenennen ändert nichts daran, was sie erlaubt.

Das serverseitige Abrufen von durch Angreifer kontrollierten URLs ist Server-Side Request Forgery (SSRF): Es ermöglicht den Zugriff auf interne Dienste oder den Cloud-Metadaten-Endpunkt, um Zugangsdaten zu stehlen. Mildern Sie es durch eine Allow-List erlaubter Hosts und Schemata, das Sperren privater und Link-Local-Bereiche (mit erneuter Prüfung nach jeder Weiterleitung) und das Härten des Metadatenzugriffs mit IMDSv2. Zu sagen, es gebe kein Risiko, ignoriert den Zugriff, den die Anfrage gewährt, und ein Lade-Spinner oder Caching ändert nichts daran, wohin der Server sich verbinden darf.

Das ist fehlerhafte Zugriffskontrolle (IDOR): Der Server prüft nicht, ob der authentifizierte Benutzer auf das angeforderte Objekt zugreifen darf. Die Behebung ist eine objektbezogene Autorisierung, die serverseitig bei jeder Anfrage erzwungen wird. Das Bereinigen der Zahl belegt keine Eigentümerschaft. Das Verschlüsseln oder Verschleiern der ID ist Obskurität und bleibt erratbar, leakbar oder wiederholbar. Die HTTP-Methode ist für die Autorisierung irrelevant. Prüfe stets das Recht des Aufrufers auf das konkrete Objekt, bevor du es zurückgibst.

Parametrisierte Abfragen sind die eigentliche Behebung: Sie trennen Code von Daten, sodass Benutzereingaben stets als Wert behandelt werden, niemals als SQL, das die Abfragestruktur ändern kann. Manuelles Escaping ist fehleranfällig und je nach Kodierung und Dialekt umgehbar. Ein WAF ist eine kompensierende Maßnahme, keine Behebung, und Kodierungstricks hebeln es aus. Eine Längenprüfung stoppt Injection überhaupt nicht. Behebe es auf der Abfrageebene.

Verschlüsselung im Ruhezustand wehrt genau eine Bedrohung ab — den physischen oder Datenträgerdiebstahl — und hilft nichts gegen eine kompromittierte Anwendung, gestohlene Zugangsdaten oder abgehörten Datenverkehr, da die Datenbank für jede autorisierte Abfrage transparent entschlüsselt. Ein solides Design verlangt zusätzlich TLS im Transit, starke Authentifizierung und Autorisierung sowie ein ordentliches Schlüsselmanagement mit Funktionstrennung. Eine zweite Ruhezustand-Verschlüsselung erhöht nur die Kosten, ohne das Bedrohungsmodell zu ändern, und nur die Backups zu verschlüsseln lässt die Produktivdaten und ihre Zugriffswege offen.

Liegt der Schlüssel beim Chiffrat, bekommt jeder, der die Datenbank stiehlt, beides — die Verschlüsselung schützt also nichts; es ist ein Schloss mit angeklebtem Schlüssel. Schlüssel gehören in ein dediziertes KMS oder HSM, getrennt von den Daten, mit strenger Zugriffskontrolle, Rotation und Funktionstrennung. Den Schlüssel zu hashen macht ihn einwegig und zum Entschlüsseln unbrauchbar, und zusätzliche Kopien am selben Ort vervielfachen nur die Exposition, statt sie zu verringern.

Die manuelle Konsolenänderung ist Konfigurations-Drift: Das nächste terraform apply kann den Fix still zurücksetzen, und die Änderung hat zudem Review und Audit umgangen. Gleiche sie ab, indem du die Änderung in Terraform codierst, plan/apply ausführst, damit Code und Realität übereinstimmen, und Leitplanken gegen Ad-hoc-Konsolenänderungen ergänzt (Konsolenzugriff nach Least Privilege, SCPs, Drift-Erkennung). Nichts zu tun hinterlässt eine Mine für das nächste apply. Den Terraform-State zu löschen ist destruktiv und kann Ressourcen verwaisen lassen oder duplizieren. Terraform aufzugeben wirft Reproduzierbarkeit, Review und Audit-Spuren weg.

Eine nicht authentifizierte RCE auf einem internetexponierten Server ist Notfall-Niveau: verkleinere das Expositionsfenster mit einem getesteten, gestaffelten oder rollierenden Deployment und ergänze in der Zwischenzeit kompensierende Kontrollen (Zugriff beschränken, WAF-Regeln). Auf das Quartalsfenster zu warten lässt ein wurmfähiges Loch wochenlang offen. Blind in der Produktion zur Geschäftszeit ohne Tests zu patchen riskiert einen Ausfall und einen verpfuschten Rollback. Sich auf die Perimeter-Firewall zu verlassen bringt nichts — der Dienst ist bereits exponiert und der Exploit braucht keine Anmeldedaten.

Führungskräfte sind genau die Konten, die Angreifer wollen (BEC, Überweisungsbetrug), daher kehrt eine Ausnahme das Risikomodell um. Löse die Reibung, nicht die Kontrolle: setze phishing-resistente FIDO2/Passkeys ein, die schneller sind als Codes. Der Ausnahme nachzugeben zerstört die Glaubwürdigkeit des Programms und lässt deine wertvollsten Konten ungeschützt. Das MFA-Projekt einzustellen gibt eine erstklassige Kontrolle auf. Es heimlich hinter ihrem Rücken zu aktivieren zerstört Vertrauen und Rechenschaft.

Flache Netzwerke lassen ein einziges kompromittiertes Gästegerät direkt die wertvollsten Systeme erreichen. Segmentiere nach Vertrauensstufe und erzwinge Verkehr mit geringsten Rechten zwischen den Zonen, damit laterale Bewegung eingedämmt und überwacht wird. Eine Edge-Firewall tut nichts für Ost-West-Verkehr zwischen Hosts, die bereits drinnen sind. Die Finanzserver neu zu adressieren ist Security-by-Obscurity, die jeder Scan aushebelt. Antivirus ist eine Erkennungsschicht, kein Ersatz für die architektonische Kontrolle der Isolierung sensibler Systeme.

Geringste Rechte plus Just-in-Time-Zugriff: gewähre die minimal nötigen Berechtigungen, zeitlich begrenzt und protokolliert, sodass Debugging möglich ist, ohne dass stehender Admin zu einem dauerhaften Risiko und einer Audit-Lücke wird. Dauerhafter Cluster-Admin verletzt das Prinzip der geringsten Rechte und vergrößert den Schadensradius jeder Kompromittierung. Eine pauschale Verweigerung blockiert legitime Arbeit und lädt zu riskanten Schatten-Workarounds ein. Das gemeinsame Anmeldeinformation des Admin-Dienstkontos zu teilen zerstört die Rechenschaft — Aktionen sind keiner Person mehr zuzuordnen.

Behandle jedes gepushte Geheimnis als verbrannt: widerrufe und rotiere es zuerst, denn Bots scrapen öffentliche Commits innerhalb von Sekunden, prüfe dann CloudTrail auf Missbrauch und entferne es aus der Historie. Den Commit zu löschen hilft nicht — der Schlüssel ist bereits geklont, geforkt und von Dritten gecacht. Das Repo privat zu machen lässt einen bereits geleakten, aktiven Schlüssel in den Händen von Angreifern. Die Datei in die .gitignore aufzunehmen ändert nichts an einem bereits committeten Geheimnis.

Sensible Daten sollten niemals in Logs gelangen: redigiere oder maskiere zuerst an der Quelle, um die Blutung zu stoppen, behebe dann die historischen Logs und verschärfe die Zugriffe. PCI DSS verbietet, vollständige PANs und CVVs so zu speichern, und Passwörter sollten überhaupt nie protokolliert werden. „Interne" Logs sind weiterhin ein erstrangiges Angriffsziel. Den Speicher zu verschlüsseln oder mit ACLs zu versehen lässt trotzdem Klartext-Geheimnisse in den Logs liegen, lesbar für jeden mit Lesezugriff — Backups, SIEM-Pipelines und Administratoren sehen sie alle.

Manuelle Erneuerungen scheitern, also beseitige das Problem technisch mit automatisierter ACME-Erneuerung plus Ablaufüberwachung, die Tage im Voraus alarmiert. Eine Kalendererinnerung ist der manuelle Prozess, der bereits versagt hat. Ein langlebiges selbstsigniertes Zertifikat zerstört das öffentliche Vertrauen und verstößt gegen moderne Laufzeitgrenzen (CAs deckeln die Gültigkeit bei ~398 Tagen, Tendenz fallend). TLS zu deaktivieren tauscht einen Verfügbarkeitsausfall gegen einen katastrophalen Verlust von Vertraulichkeit und Integrität.

Reduzieren Sie Fehlalarme durch Detection Engineering, nicht indem Sie sich blind machen. Passen Sie die Regel neu an, sodass Alarme nur bei relevanten Mustern auslösen — ein Passwort gegen viele Konten (Spraying), ein Konto vielfach angegriffen (Stuffing/Brute Force), unmögliche Reise — während die Rohereignisse auf einem Dashboard durchsuchbar bleiben. Messen Sie dann die Alarmpräzision über die Zeit. Die Regel zu deaktivieren entfernt ein echtes Signal, eine pauschale Unterdrückung schafft einen dauerhaften blinden Fleck, und Leute für die Triage von reinem Rauschen einzustellen skaliert nicht und brennt sie aus.

KI hilft dem SOC, indem sie Alerts triagiert und dedupliziert, Vorfälle zusammenfasst, Kontext anreichert, Detections entwirft und das Onboarding von Analysten beschleunigt — was Ermüdung und Verweildauer reduziert. Die Risiken: halluzinierte oder selbstbewusst falsche Schlüsse, Automation Bias, bei dem Analysten aufhören zu prüfen, Prompt Injection über vom Angreifer kontrollierte Log- oder Alert-Daten, das Abfließen sensibler Daten an Drittmodelle, und Angreifer, die dieselben Tools nutzen. Halte einen Menschen in der Schleife, prüfe die Ausgaben und isoliere nicht vertrauenswürdige Eingaben.

Direkte Prompt Injection liegt vor, wenn ein Nutzer gegnerische Anweisungen direkt in den Prompt tippt, um den System-Prompt oder Sicherheitsregeln zu überschreiben. Indirekte Prompt Injection verbirgt bösartige Anweisungen in externen Inhalten, die das Modell später einliest — eine Webseite, eine E-Mail, ein PDF oder ein RAG-Dokument —, sodass der Angriff auslöst, ohne dass das Opfer ihn je tippt. Indirekte Injection ist das größere Risiko, weil Angreifer und Opfer verschiedene Personen sind und die Payload in Daten mitreist, denen die App implizit vertraut.

Unsichere Ausgabeverarbeitung bedeutet, dem zu vertrauen, was das Modell zurückgibt, und es ohne Validierung oder Codierung an ein nachgelagertes System weiterzureichen. Weil die Modellausgabe von Angreifern beeinflussbar ist, führt das Rendern als rohes HTML zu XSS, das Einspeisen in einen URL-Fetcher zu SSRF und das Übergeben an eine Shell oder SQL-Abfrage zu Command- oder SQL-Injection. Die Lösung ist, die Modellausgabe genauso wie nicht vertrauenswürdige Benutzereingaben zu behandeln: kontextbewusste Ausgabecodierung, Allowlisting, Sanitization und Parametrisierung, bevor sie einen Sink erreicht.

Ein Jailbreak zielt auf das Sicherheits-Alignment des Modells: Er bringt das Modell dazu, Inhalte zu erzeugen, die der Anbieter zu verbieten versuchte, etwa schädliche Anleitungen. Prompt Injection zielt auf die Anweisungshierarchie der Anwendung: Sie überschreibt den System-Prompt des Entwicklers oder kapert das Verhalten des Modells innerhalb einer App, oft über nicht vertrauenswürdige Daten. Jailbreaks greifen das Modell an; Prompt Injection greift das umgebende System an. Sie überschneiden sich, aber das Ziel und die überschrittene Vertrauensgrenze unterscheiden sich.

Die LLM-Supply-Chain umfasst Basismodelle, fine-getunte Varianten, Datensätze, Embeddings, Plugins, Bibliotheken und die Hosting-Plattform — jede davon ein Punkt, an dem Risiko entstehen kann. Zu den Bedrohungen zählen das Herunterladen manipulierter oder mit Backdoors versehener Modellgewichte, bösartige Fine-Tunes, vergiftete oder lizenzbelastete Datensätze, anfällige oder überberechtigte Plugins sowie typosquattete Modell-Repos. Verteidigung: Modelle aus vertrauenswürdigen Registries beziehen, Integrität und Provenienz prüfen, eine AI Bill of Materials pflegen, Abhängigkeiten scannen und pinnen, Plugins prüfen und das Least-Privilege-Prinzip auf alles anwenden, mit dem das Modell integriert wird.

Das NIST AI Risk Management Framework (AI RMF 1.0) ist ein freiwilliges, risikobasiertes Framework zur Governance vertrauenswürdiger KI über ihren gesamten Lebenszyklus. Sein Kern sind vier Funktionen: Govern (Kultur, Richtlinien, Verantwortlichkeit — und es zieht sich durch die anderen), Map (Kontext und Risikoidentifikation), Measure (Risiken bewerten und nachverfolgen) und Manage (priorisieren und reagieren). Es definiert außerdem Vertrauenswürdigkeitsmerkmale — valide und zuverlässig, sicher, abgesichert und widerstandsfähig, rechenschaftspflichtig und transparent, erklärbar, datenschutzfördernd und fair. Es ergänzt technische Listen wie die OWASP LLM Top 10 auf der Programmebene.

Die OWASP Top 10 für LLM-Anwendungen sind die Konsensliste der kritischsten Risiken beim Entwickeln mit großen Sprachmodellen. Die Ausgabe 2025 umfasst Prompt Injection, Offenlegung sensibler Informationen, Supply Chain, Daten- und Modellvergiftung, unsichere Ausgabeverarbeitung, übermäßige Handlungsvollmacht, Leakage von System-Prompts, Schwachstellen in Vektoren und Embeddings, Fehlinformation sowie unbegrenzten Ressourcenverbrauch. Sie existiert, weil klassische AppSec-Listen die LLM-spezifischen Fehlerbilder nicht erfassen, und gibt Teams ein gemeinsames Vokabular sowie eine Checkliste, um Maßnahmen zu priorisieren.

RAG-Sicherheit bedeutet, jedes abgerufene Dokument als nicht vertrauenswürdige Eingabe zu behandeln. Zentrale Risiken: indirekte Prompt Injection, die in abgerufenen Inhalten versteckt ist, Vergiftung der Wissensbasis oder der Embeddings sowie fehlende benutzerbezogene Autorisierung, sodass das Modell Daten zurückgibt, auf die der Benutzer keinen Zugriff hat. Zu den Verteidigungsmaßnahmen zählen Zugriffskontrolle beim Retrieval, Inhaltsprovenienz und Prüfung der Ingestion, Behandeln von abgerufenem Text als Daten statt als Anweisungen, Ausgabevalidierung und Isolierung der Vektordatenbank pro Mandant.

Ein LLM-Agent verwandelt Text über Tools und Function Calls in Aktionen, sodass eine Prompt Injection zu einer realen Aktion wird — das Risiko übermäßiger Handlungsvollmacht. Sichere ihn ab, indem du jedem Tool das geringste benötigte Privileg und den engsten Geltungsbereich gibst, Tool-Argumente validierst und einschränkst, menschliche Bestätigung für sensible oder irreversible Aktionen verlangst, die Ausführung sandboxt, Aufrufe rate-limitierst und budgetierst und jeden Tool-Aufruf protokollierst. Lass niemals zu, dass die von nicht vertrauenswürdigen Daten beeinflusste Ausgabe des Modells direkt eine folgenschwere Aktion autorisiert.

LLM-Apps geben Daten auf mehrere Arten preis: Das Modell memoriert und gibt sensible Trainings- oder Fine-Tuning-Daten wieder, der System-Prompt (der Geheimnisse oder Logik enthalten kann) wird extrahiert, abgerufene RAG-Dokumente legen Daten offen, die der Benutzer nicht sehen sollte, und Kontext aus einer Benutzer- oder Sitzung blutet in eine andere über. Vorbeugung bedeutet Datenminimierung vor dem Training, niemals Geheimnisse in Prompts, das Erzwingen benutzerbezogener Autorisierung beim Retrieval, Ausgabefilterung und PII-Redaktion sowie Mandantenisolierung.

Trainingsdaten-Vergiftung liegt vor, wenn ein Angreifer die Daten manipuliert, die zum Pre-Training, Fine-Tuning oder Einbetten eines Modells verwendet werden, sodass das resultierende Modell sich bösartig verhält — durch Einbetten eines Backdoor-Triggers, Einschleusen von Verzerrungen oder Verschlechtern der Genauigkeit. Es nutzt aus, dass Modelle große, oft aus dem Web stammende Datensätze scrapen und ihnen vertrauen. Zu den Verteidigungsmaßnahmen zählen das Kuratieren und Signieren von Datenquellen, Provenienz- und Integritätsprüfungen, Anomalieerkennung in Trainingsdaten, Datensatz-Versionierung und das Beschränken, wer zu Trainings- und RAG-Korpora beitragen darf.

Credential Stuffing spielt bekannte Benutzername:Passwort-Paare aus fremden Datenlecks ab und setzt auf Passwort-Wiederverwendung – hohe Erfolgsrate pro Versuch, oft über viele IPs und Geräte verteilt, um menschlich zu wirken. Password Spraying probiert ein oder zwei gängige Passwörter (wie Winter2026!) über viele Konten, um unter den Sperrschwellen zu bleiben. Stuffing nutzt Wiederverwendung aus; Spraying nutzt schwache gemeinsame Passwörter aus. MFA schlägt beide.

Die Cyber Kill Chain modelliert einen Einbruch als sieben aufeinanderfolgende Stufen: Aufklärung, Bewaffnung, Auslieferung, Ausnutzung, Installation, Command and Control (C2) und Actions on Objectives. Verteidiger ordnen jeder Stufe Erkennungen und Maßnahmen zu; da die Stufen sequenziell sind, stört das Brechen eines einzelnen Glieds – die Phishing-Mail blockieren, das C2 abschalten – den gesamten Angriff. Sie drängt dazu, früh zu erkennen statt erst beim finalen Einbruch.

DNS-Exfiltration kodiert gestohlene Daten in DNS-Anfragen (z. B. lange Subdomain-Labels an einen vom Angreifer kontrollierten autoritativen Server) und nutzt aus, dass DNS fast immer ausgehend erlaubt und oft unüberwacht ist. Erkenne sie über Anomalien: ungewöhnlich hohes Anfragevolumen zu einer Domain, lange Subdomains mit hoher Entropie, viele eindeutige Subdomains je Eltern-Domain, Missbrauch von TXT/NULL-Records und Anfragen an neu registrierte oder seltene Domains.

Herkömmliches Antivirus gleicht Dateien mit Signaturen bekannter Malware ab und blockiert oder isoliert sie – gut gegen bekannte Bedrohungen, schwach gegen neuartige oder dateilose Angriffe. EDR zeichnet kontinuierlich das Endpunktverhalten auf (Prozesse, Netzwerk, Registry, Speicher), nutzt Verhaltensanalytik zur Erkennung verdächtiger Aktivität und ermöglicht Respondern, aus der Ferne zu untersuchen, zu jagen und einzudämmen oder zurückzurollen. AV ist Prävention per Signatur; EDR ergänzt Sichtbarkeit, Erkennung und Reaktion.

Unter Windows liegen die Hashes lokaler Konten (NTLM) in der SAM-Hive unter C:\Windows\System32\config\SAM, geschützt solange das OS läuft; lebende Anmeldedaten sitzen im LSASS-Speicher, und Domänen-Hashes liegen in NTDS.dit auf einem Domänencontroller. Unter Linux liegen Hashes in /etc/shadow (nur für root lesbar), während /etc/passwd Kontometadaten enthält. Angreifer stehlen diese, um Passwörter offline zu knacken oder Pass-the-Hash zu betreiben.

SPF veröffentlicht, welche IPs für eine Domain Mail senden dürfen. DKIM fügt eine kryptografische Signatur hinzu, damit der Empfänger prüfen kann, dass die Nachricht nicht verändert wurde und von der Domain stammt. DMARC bindet die SPF/DKIM-Ergebnisse über das Alignment an den sichtbaren From:-Header, sagt Empfängern, was bei Fehlschlag zu tun ist (none/quarantine/reject), und sendet Berichte. SPF und DKIM allein schützen das vom Nutzer gesehene From nicht – DMARC erzwingt das.

Ein Honeypot ist ein Ködersystem oder -dienst ohne legitimen geschäftlichen Zweck, das bewusst exponiert wird, um Angreifer anzulocken. Da nichts Gutartiges ihn je berühren sollte, ist jede Interaktion ein hochsicherer Alarm. Honeypots mit niedriger Interaktion emulieren Dienste günstig; solche mit hoher Interaktion sind echte Systeme, die reichere Intel liefern, aber mehr Risiko bergen. Honeytokens sind dieselbe Idee, angewandt auf gefälschte Anmeldedaten, Dateien oder Datensätze. Wert: frühe Erkennung, wenige Fehlalarme und Threat Intelligence.

DAC lässt den Dateneigentümer den Zugriff nach eigenem Ermessen gewähren; MAC erzwingt den Zugriff zentral über Labels/Freigaben und ist nicht-diskretionär; RBAC gewährt Zugriff über Jobrollen; ABAC bewertet Attribute (Benutzer, Ressource, Umgebung) gegen eine Richtlinie für feingranulare, kontextbewusste Entscheidungen.

Defense in Depth schichtet mehrere, vielfältige und unabhängige Kontrollen über Menschen, Prozesse und Technik, sodass der Ausfall einer einzelnen Kontrolle nicht zur Kompromittierung führt. Es geht davon aus, dass jede Kontrolle irgendwann versagt, und nutzt Redundanz und Vielfalt, um einen Angreifer zu verlangsamen, zu erkennen und einzudämmen.

Das Identity-Lifecycle-Management steuert ein Konto von der Erstellung bis zur Stilllegung: Bereitstellung beim Onboarding (Joiner), Anpassung der Berechtigungen bei Rollenwechsel (Mover) und zeitnahe Deaktivierung beim Austritt (Leaver), mit durchgängigen periodischen Zugriffsüberprüfungen. Die häufigsten Fehler sind schleichende Rechteanhäufung bei Movern und verwaiste Konten durch versäumte Deaktivierungen.

Beginne mit einem minimalen, vertrauenswürdigen Basis-Image (distroless oder slim), um die Angriffsfläche zu verkleinern, scanne Images in der CI und in der Registry auf bekannte CVEs, fixiere und verifiziere Image-Digests, führe als Nicht-Root-Benutzer aus und vermeide es, Secrets einzubacken. Signiere Images und erzwinge Admission-Richtlinien, sodass nur gescannte, signierte Images laufen. Baue regelmäßig neu, damit gepatchte Basis-Layer durchfließen.

Verschlüsselung während der Übertragung (TLS) schützt Daten, die über das Netz wandern, vor Abhören und Manipulation; erzwinge TLS überall und lehne Klartext ab. Verschlüsselung im Ruhezustand schützt gespeicherte Daten auf Festplatten und Backups, typischerweise über KMS-verwaltete Schlüssel mit Umschlagverschlüsselung. Beide sind Basiskontrollen, aber keine stoppt eine autorisierte, aber bösartige Anfrage — der Dienst entschlüsselt transparent für gültige Aufrufer — daher bleibt Zugriffskontrolle am wichtigsten.

Ein Benutzer ist eine langlebige Identität mit permanenten Anmeldedaten; eine Rolle ist eine Identität ohne permanente Anmeldedaten, die jeder vertrauenswürdige Principal annehmen kann, um kurzlebige Tokens zu erhalten; eine Richtlinie ist das JSON-Dokument, das Berechtigungen gewährt und an beide angehängt wird. Geringste Rechte bedeutet, Rollen Benutzern vorzuziehen, Richtlinien auf konkrete Aktionen und Ressourcen einzugrenzen und nur das zu gewähren, was eine Aufgabe braucht — und im Lauf der Zeit zu überprüfen und auszumisten.

IMDS ist ein link-lokaler Endpunkt (169.254.169.254), der einer Instanz ihre Metadaten liefert, einschließlich temporärer Anmeldedaten für ihre angehängte IAM-Rolle. SSRF kann den Server dazu bringen, diese URL abzurufen und diese Anmeldedaten zu leaken. IMDSv2 verlangt ein PUT, um ein kurzlebiges Session-Token zu erhalten, setzt ein standardmäßiges IP-TTL/Hop-Limit von 1 und lehnt Anfragen mit bestimmten Headern ab — sodass ein einfaches SSRF-GET es nicht mehr erreichen kann.

RBAC steuert, was Identitäten gegen die Kubernetes-API tun können — Roles und ClusterRoles gewähren Verben auf Ressourcen, über RoleBindings an Subjekte gebunden — und sollte geringste Rechte befolgen, indem cluster-admin und Wildcards vermieden werden. Network Policies steuern den Pod-zu-Pod-Verkehr, der standardmäßig alles erlaubt, bis du ein Default-Deny anwendest und dann erforderliche Flüsse explizit zulässt. Zusammen begrenzen sie den Wirkungsradius, wenn ein Pod oder Token kompromittiert wird.

Die klassischen Fehler sind öffentliche ACLs oder Bucket-Richtlinien, die anonymen Zugriff oder Zugriff für alle AWS-Benutzer erlauben, zu weit gefasste Principals oder Wildcard-Aktionen, fehlende Standardverschlüsselung und fehlendes Logging. Man verhindert sie, indem man Block Public Access auf Kontoebene aktiviert, IAM-/Bucket-Richtlinien nach dem Prinzip der geringsten Rechte einsetzt, Standardverschlüsselung und TLS erzwingt und Zugriffs-Logging sowie Config-Regeln einschaltet, um Abweichungen zu erkennen.

Speichere Secrets in einem dedizierten verwalteten Dienst (Secrets Manager, Parameter Store, Vault), verschlüsselt mit einem KMS-Schlüssel, und gewähre den Zugriff über IAM-Rollen, sodass Workloads sie zur Laufzeit mit kurzlebigen Anmeldedaten abrufen. Backe Secrets niemals in Code, Container-Images oder eingecheckte .env-Dateien ein. Füge automatische Rotation, eingegrenzte Schlüsselrichtlinien und Audit-Logging hinzu, sodass jeder Abruf nachvollziehbar ist.

Security Groups sind zustandsbehaftete Firewalls, die an Instanzen/ENIs angehängt sind: Sie haben nur Allow-Regeln, und der Rückverkehr eines erlaubten Flusses wird automatisch zugelassen. Network ACLs sind zustandslose Filter an der Subnetzgrenze: Sie haben geordnete Allow- und Deny-Regeln, und du musst den Rückverkehr auf ephemeren Ports explizit erlauben. Security Groups sind die primäre Kontrolle; NACLs ergänzen grobe Leitplanken auf Subnetzebene wie das Blockieren eines IP-Bereichs.

Der Anbieter sichert die Cloud selbst ab — physische Rechenzentren, Hardware, den Hypervisor und die von ihm betriebenen verwalteten Dienste. Du sicherst ab, was du in die Cloud stellst — deine Daten, Identitäten, Konfigurationen, das OS-Patching wo zutreffend und die Zugriffskontrollen. Die genaue Grenze verschiebt sich: Bei IaaS besitzt du das OS aufwärts, bei SaaS besitzt du vor allem Daten und Zugriff.

RSA ist ein asymmetrischer Algorithmus, der Daten verschlüsselt oder digitale Signaturen mit einem Schlüsselpaar erstellt. Diffie-Hellman ist ein Schlüsselaustauschprotokoll, mit dem zwei Parteien über einen öffentlichen Kanal ein gemeinsames Geheimnis ableiten, ohne es je zu übertragen. Sie lösen verschiedene Probleme: RSA beweist Identität und kann Schlüssel einpacken; DH handelt einen Sitzungsschlüssel aus, und seine flüchtige Variante bietet Forward Secrecy.

Eine digitale Signatur ist der mit dem privaten Schlüssel des Unterzeichners umgewandelte Hash einer Nachricht. Der Prüfer berechnet den Hash neu, wendet den öffentlichen Schlüssel des Unterzeichners an und prüft auf Übereinstimmung. Da nur der Unterzeichner den privaten Schlüssel besitzt, beweist eine gültige Signatur, dass die Nachricht von ihm stammt (Authentizität), nicht verändert wurde (Integrität) und dass er es nicht glaubhaft abstreiten kann (Nichtabstreitbarkeit).

Ein HMAC ist ein schlüsselbasierter Nachrichtenauthentifizierungscode: Er hasht die Nachricht zusammen mit einem geheimen Schlüssel über eine verschachtelte Konstruktion (innerer und äußerer Hash mit schlüsselabgeleiteten Pads). Er beweist sowohl Integrität (die Nachricht wurde nicht verändert) als auch Authentizität (sie stammt von jemandem mit dem Schlüssel). Ein einfacher Hash beweist keines von beiden, da ihn jeder neu berechnen kann; HMAC widersteht zudem Length-Extension-Angriffen.

Ein JWT besteht aus drei base64url-Teilen – Header, Payload (Claims) und Signatur – durch Punkte verbunden. Der Server signiert Header und Payload mit einem Geheimnis oder privaten Schlüssel und verifiziert diese Signatur bei jeder Anfrage, um den Claims ohne serverseitigen Sitzungszustand zu vertrauen. Fallstricke: alg=none akzeptieren, RS256-zu-HS256-Schlüsselverwechslung, Ablauf/Aussteller/Zielgruppe nicht zu validieren, Geheimnisse in die lesbare Payload zu legen und keinen Widerrufsweg zu haben.

Kerberos stützt sich auf ein vertrauenswürdiges Key Distribution Center (KDC). Der Client authentifiziert sich einmal beim Authentication Server und erhält ein mit dem Schlüssel des KDC verschlüsseltes Ticket-Granting-Ticket (TGT). Um einen Dienst zu erreichen, legt er das TGT dem Ticket-Granting-Service vor und erhält ein mit dem Schlüssel dieses Dienstes verschlüsseltes Service-Ticket. Der Dienst entschlüsselt es und vertraut ihm. Passwörter durchqueren nie das Netz, und Tickets sind zeitlich begrenzt.

Die App leitet den Benutzer zum Autorisierungsserver weiter, um sich anzumelden und einzuwilligen. Der Server leitet mit einem kurzlebigen Autorisierungscode zurück. Das Backend der App tauscht diesen Code (plus sein Client-Geheimnis) dann am Token-Endpunkt über einen Server-zu-Server-Back-Channel gegen ein Access-Token. Das hält Tokens aus Browser/URL fern. Öffentliche Clients ergänzen PKCE, um den Code an den ursprünglichen Anforderer zu binden.

Speichere Passwörter mit einer bewusst langsamen, gesalzenen, adaptiven Passwort-Hashfunktion – bcrypt, scrypt oder Argon2 – nie mit einem schnellen Allzweck-Hash wie SHA-256 oder MD5. Schnelle Hashes sind auf Geschwindigkeit ausgelegt, sodass Angreifer mit GPUs Milliarden Versuche pro Sekunde gegen eine geleakte Datenbank testen können. Langsame Hashes haben einen einstellbaren Arbeitsfaktor (und Speicherkosten), der jeden Versuch teuer macht und Brute Force selbst nach einem Leak unpraktikabel hält.

Perfect Forward Secrecy (PFS) bedeutet, dass jede Sitzung einen einzigartigen Schlüssel aus einem flüchtigen Schlüsselaustausch ableitet, der danach verworfen wird. Stiehlt ein Angreifer später den langlebigen privaten Schlüssel des Servers, kann er zuvor erfassten Verkehr dennoch nicht entschlüsseln, weil dieser Schlüssel nie zur Ableitung der Sitzungsschlüssel diente. Erreicht wird das mit flüchtigem Diffie-Hellman (DHE/ECDHE).

Der Client baut eine Kette vom Server-Zertifikat (Leaf) über eine oder mehrere Zwischen-CAs bis zu einer Root-CA in seinem Vertrauensspeicher auf. Er verifiziert die Signatur jedes Zertifikats mit dem öffentlichen Schlüssel des nächsten Ausstellers, prüft Gültigkeitsdaten, Name-/Hostname-Übereinstimmung, Schlüsselverwendung und Widerruf (CRL/OCSP). Das Vertrauen endet an einer selbstsignierten, vorab vertrauten Wurzel; die Kette ist nur gültig, wenn jedes Glied stimmt.

Ein Salt ist ein einzigartiger Zufallswert, der pro Benutzer erzeugt und vor dem Hashing mit dem Passwort kombiniert wird. Er sorgt dafür, dass identische Passwörter unterschiedliche Hashes ergeben, und macht vorberechnete Angriffe wie Rainbow Tables nutzlos, da der Angreifer pro Salt eine eigene Tabelle bräuchte. Salts werden neben dem Hash gespeichert. Ein Pepper ist ein zusätzlicher geheimer Wert, für alle Benutzer gleich, getrennt aufbewahrt (z. B. in der App-Konfiguration oder einem HSM), sodass ein Datenbankleck allein nicht genügt.

SSO zentralisiert die Authentifizierung bei einem Identity Provider (IdP). Besucht ein Benutzer einen Service Provider (die App), leitet die App zum IdP weiter; der Benutzer meldet sich einmal an, und der IdP gibt eine signierte Assertion oder ein Token zurück, das seine Identität bürgt. SAML trägt dies als signierte XML-Assertion; OIDC trägt es als signiertes JSON-ID-Token auf OAuth 2.0. Die App vertraut der Signatur des IdP, statt Passwörter selbst zu handhaben.

TOTP (Time-based One-Time Password) kombiniert ein bei der Einrichtung festgelegtes gemeinsames Geheimnis mit der aktuellen, in feste Fenster (meist 30 Sekunden) unterteilten Zeit. Es führt HMAC über den Zeitschritt-Zähler mit dem Geheimnis aus und kürzt das Ergebnis dann auf einen 6-stelligen Code. Sowohl App als auch Server halten dasselbe Geheimnis und dieselbe Uhr, sodass sie unabhängig denselben Code berechnen – ohne Netzwerkaufruf. Der Code wechselt mit jedem Fenster.

Lockfiles pinnen exakte Abhängigkeitsversionen und Hashes, sodass jeder Build dieselben verifizierten Bytes auflöst — das macht Builds reproduzierbar und blockiert stille bösartige Updates. Pinning per Digest, das Prüfen von Integritäts-Hashes und das Scoping interner Pakete auf eine private Registry schützen zudem vor Dependency Confusion, bei der ein Angreifer ein öffentliches Paket mit höherer Version veröffentlicht, das einem internen Namen entspricht, um die Auflösung zu kapern. Das Prinzip: Den Build niemals still ungeprüften Code ziehen lassen.

SAST liest den Quellcode, ohne ihn auszuführen, und findet Fehler wie Injection-Sinks früh, aber mit vielen Fehlalarmen. DAST greift die laufende Anwendung von außen ohne Code-Einblick an und findet echte ausnutzbare Probleme, aber spät und mit oberflächlicher Abdeckung. IAST instrumentiert die laufende Anwendung, um Laufzeitverhalten mit dem Code zu korrelieren, und liefert präzise Ergebnisse mit Code-Kontext, benötigt aber eine ausgeübte Anwendung und Agent-Unterstützung.

Setzen Sie auf Defense in Depth: Pre-Commit-Hooks (z. B. gitleaks) fangen Secrets ab, bevor sie landen, serverseitiges CI-Scanning fängt, was durchrutscht, und regelmäßige Scans des gesamten Verlaufs finden alte Lecks. Entscheidend: Ein Secret, das ein Remote-Repository erreicht hat, muss als kompromittiert behandelt und rotiert werden — den Commit zu löschen hilft nicht, da es im Verlauf, in Forks und Logs lebt. Kombinieren Sie das mit einem echten Secrets-Manager, damit Secrets gar nicht erst im Code stehen.

Behandeln Sie die Pipeline wie Produktionsinfrastruktur: Sie hält die Zugangsdaten, um Code auszuliefern und die Produktion zu erreichen, sodass ihre Kompromittierung jede nachgelagerte Kontrolle umgeht. Härten Sie sie mit isolierten, kurzlebigen Runnern; Tokens mit minimalen Rechten und kurzer Lebensdauer (OIDC-Föderation statt langlebiger Secrets); geschützten Branches und geprüfter Pipeline-Konfiguration; per Digest gepinnten Drittanbieter-Actions; und vollständigem Audit-Logging. Die Pipeline ist ein erstklassiges Ziel, keine Klempnerei.

Brich den Build nur bei hochgradig zuverlässigen, schwerwiegenden, neu eingeführten Befunden; warne (blockiere nicht) bei allem anderen, damit Entwickler dem Gate weiter vertrauen. Manage False Positives mit getunten Regeln, Baselining bereits bestehender Probleme und dokumentierten, befristeten, geprüften Unterdrückungen statt Scanner zu deaktivieren. Ein Gate, das ständig fälschlich Alarm schlägt, wird ignoriert oder umgangen — Signalqualität ist also das Ganze.

Shift-Left bedeutet, Sicherheit nach vorn zu verlagern — ins Design, in die IDE und in den Pull Request —, wo Probleme billiger zu beheben sind als in der Produktion. Du vermeidest es, Entwickler zu blockieren, indem du den sicheren Pfad zum einfachen Pfad machst: schnelles kontextbezogenes Feedback, Gates mit wenigen False Positives, die nur bei schwerwiegenden neuen Problemen hart fehlschlagen, sichere Defaults und Paved-Road-Templates und das Behandeln von Sicherheit als Ermöglicher statt als spätes Veto.

SCA inventarisiert die Open-Source- und Drittanbieter-Komponenten, die eine Anwendung einbindet — einschließlich transitiver Abhängigkeiten — und markiert jene mit bekannten CVEs oder problematischen Lizenzen. Sie ist wichtig, weil der meiste moderne Code aus Abhängigkeiten besteht, die du nicht geschrieben hast, und ein einziges anfälliges transitives Paket (wie Log4j) die gesamte App gefährden kann. Gute SCA priorisiert nach Erreichbarkeit und Ausnutzbarkeit, nicht nur nach reinen CVE-Zahlen.

Client und Server einigen sich in einem einzigen Roundtrip mittels ephemerem Diffie-Hellman (ECDHE) auf ein gemeinsames Geheimnis. Das ClientHello trägt die unterstützten Gruppen und einen Key Share; der Server antwortet mit seinem Key Share und Zertifikat, beide Seiten leiten dieselben Schlüssel ab, und Anwendungsdaten fließen sofort, mit Forward Secrecy als Standard.

Die CIA-Triade umfasst die drei Kernziele der Informationssicherheit: Vertraulichkeit (nur autorisierte Parteien können Daten lesen), Integrität (Daten werden nicht unbefugt verändert) und Verfügbarkeit (autorisierte Nutzer können bei Bedarf auf Systeme zugreifen). Nahezu jede Maßnahme lässt sich einem oder mehreren dieser Ziele zuordnen.

Defense in Depth bedeutet, mehrere unabhängige Sicherheitsmaßnahmen zu schichten, sodass bei Ausfall einer Maßnahme die anderen das Asset weiterhin schützen. Sie geht davon aus, dass keine einzelne Maßnahme perfekt ist — etwa durch die Kombination von Firewall, Netzwerksegmentierung, Endpunktschutz, MFA, Least Privilege und Verschlüsselung, statt sich allein auf den Perimeter zu verlassen.

Kodierung (wie Base64) ist eine reversible Formatänderung ohne Geheimnis — keine Sicherheit. Verschlüsselung ist mit einem Schlüssel reversibel und schützt die Vertraulichkeit. Hashing ist eine Einwegfunktion, die einen Digest fester Länge erzeugt, für Integritätsprüfungen und Passwortspeicherung verwendet wird und nicht zur Eingabe zurückgerechnet werden kann.

Ein IDS (Intrusion Detection System) überwacht den Datenverkehr und löst Alarme aus, blockiert aber nicht — es liegt typischerweise außerhalb des Datenpfads. Ein IPS (Intrusion Prevention System) sitzt inline im Datenpfad und kann bösartigen Verkehr aktiv verwerfen oder blockieren. Das IPS verhindert, aber ein Fehlalarm kann legitimen Verkehr unterbrechen.

Least Privilege bedeutet, dass jeder Nutzer, Prozess und Dienst nur den für seine Aufgabe minimal erforderlichen Zugriff erhält und nicht mehr. Es begrenzt den Wirkungsradius eines kompromittierten Kontos, senkt das Insider-Bedrohungsrisiko und verkleinert die Angriffsfläche. Man wendet es über rollenbasierten Zugriff, regelmäßige Zugriffsüberprüfungen und Just-in-Time-Erhöhung an.

MFA erfordert zwei oder mehr Authentifizierungsfaktoren aus unterschiedlichen Kategorien — etwas, das man weiß (Passwort), etwas, das man hat (Telefon/Token), etwas, das man ist (Biometrie). Sie hilft, weil ein Angreifer, der einen Faktor wie ein Passwort stiehlt, sich ohne die anderen trotzdem nicht anmelden kann. Phishing-resistente MFA wie FIDO2 ist am stärksten.

Symmetrische Verschlüsselung nutzt einen einzigen gemeinsamen geheimen Schlüssel zum Ver- und Entschlüsseln und ist schnell, doch beide Parteien müssen den Schlüssel bereits teilen. Asymmetrische nutzt ein öffentlich/privates Schlüsselpaar und löst das Problem der Schlüsselverteilung, aber langsamer. Echte Protokolle wie TLS nutzen asymmetrische Kryptografie, um einen symmetrischen Schlüssel auszutauschen, und wechseln dann für die Massendaten zu symmetrischer.

TCP ist verbindungsorientiert und zuverlässig: Es nutzt einen Drei-Wege-Handshake, garantiert geordnete Zustellung und überträgt verlorene Pakete erneut. UDP ist verbindungslos und schnell, ohne Garantien für Zustellung, Reihenfolge oder Überlastkontrolle. Nutzen Sie TCP für Genauigkeit (Web, E-Mail, Dateiübertragung) und UDP für geschwindigkeitssensiblen Verkehr (DNS, VoIP, Streaming, Gaming).

Eine Schwachstelle ist eine Schwäche (ungepatchte Software). Eine Bedrohung ist ein Akteur oder Ereignis, das sie ausnutzen könnte (eine Ransomware-Gruppe). Risiko ist die Kombination aus der Wahrscheinlichkeit, dass eine Bedrohung eine Schwachstelle ausnutzt, und der Auswirkung, falls dies geschieht. Risiko = Bedrohung x Schwachstelle x Auswirkung, und das ist es, was man tatsächlich priorisiert.

Eine Firewall steuert den Verkehr zwischen Netzwerkzonen, indem sie ihn anhand von Regeln zulässt oder verweigert. Eine zustandslose Firewall bewertet jedes Paket isoliert gegen die Regeln; eine zustandsbehaftete Firewall verfolgt den Zustand von Verbindungen, um Rückverkehr für von ihr erlaubte Sitzungen zuzulassen. Next-Gen-Firewalls ergänzen das Bewusstsein für die Anwendungsschicht.

Zuerst komprimieren, dann verschlüsseln. Gute Verschlüsselung erzeugt eine Ausgabe, die statistisch nicht von Zufall zu unterscheiden ist, sodass im Chiffretext keine Muster mehr zum Komprimieren übrig bleiben — danach zu komprimieren ist sinnlos. Der wichtige Vorbehalt: geheime und vom Angreifer kontrollierte Daten vor der Verschlüsselung gemeinsam zu komprimieren kann über die Chiffretext-Länge Informationen verraten, genau das sind die Angriffe CRIME und BREACH.

Nein. CORS ist keine Abwehr gegen CSRF — es lockert tatsächlich die Same-Origin-Policy, damit eine Seite Cross-Origin-Antworten lesen kann, die sie sonst nicht lesen dürfte. CSRF muss die Antwort nicht lesen; es genügt, dass der Browser des Opfers eine authentifizierte zustandsändernde Anfrage sendet. Die echten Abwehrmechanismen sind Anti-CSRF-Tokens, das SameSite-Cookie-Attribut und das Prüfen von Origin/Referer.

Gefiltert. Ein gefilterter Port verwirft das Paket still, sodass der Scanner keine Antwort erhält und auf ein Timeout warten muss — er erfährt nichts darüber, ob der Host überhaupt existiert, und der Scan wird drastisch verlangsamt. Ein geschlossener Port sendet ein TCP-RST zurück, das bestätigt, dass der Host lebt und antwortet, und liefert dem Angreifer so gratis Aufklärungswert.

Nicht von allein. HTTPS verhindert MITM nur, wenn die Zertifikatsvalidierung strikt erzwungen wird und der Client die Website von Anfang an über HTTPS erreicht. Wenn einer Rogue-CA vertraut wird (Unternehmens-Proxy, von Malware installierte Root), wenn der Nutzer Zertifikatswarnungen wegklickt oder wenn SSL-Stripping die Verbindung auf HTTP herabstuft, bevor TLS startet, kann ein Angreifer sich weiterhin dazwischensetzen.

HTTPS ist kein eigenes Protokoll — es ist ganz normales HTTP, das innerhalb eines verschlüsselten TLS-Tunnels läuft. SSL ist der alte Name: SSL 2.0/3.0 sind die veralteten, unsicheren Vorgänger von TLS, das sie abgelöst hat (TLS 1.0 bis 1.3). Wenn Leute „SSL-Zertifikat“ oder „SSL“ sagen, meinen sie fast immer eigentlich TLS.

Weil sie schnell sind. MD5 und SHA-256 sind auf Geschwindigkeit ausgelegt, was für Passwörter genau falsch ist: Ein Angreifer, der die Hashes stiehlt, kann auf einer GPU Milliarden von Versuchen pro Sekunde berechnen. Die Lösung ist eine bewusst langsame, speicherharte Schlüsselableitungsfunktion — bcrypt, scrypt oder Argon2 — kombiniert mit einem Salt pro Nutzer und einem einstellbaren Arbeitsfaktor.

Eine Baseline ist ein Modell des normalen Verhaltens für einen Host, Benutzer, ein Konto oder ein Netzwerksegment — welche Prozesse laufen, wer sich von wo und wann anmeldet, typische Datenmengen, normale Beaconing-Intervalle. Sobald man den Normalzustand kennt, werden Anomalien (seltene Eltern-Kind-Prozesspaare, erstmals gesehene Binärdateien, Anmeldungen zu ungewöhnlichen Zeiten, ungewöhnlicher Datenabfluss) als Abweichungen erkennbar. Baselining ist die Grundlage der Anomalieerkennung, erfordert aber genügend saubere Historie und einen sorgfältigen Umgang mit legitimen Änderungen, um nicht in Fehlalarmen zu ertrinken.

C2-Beaconing ist das periodische Einchecken, das ein Implantat bei seinem Controller durchführt. Jagen Sie es in Netzwerk-/Proxy-/DNS-Telemetrie, indem Sie nach Regelmäßigkeit suchen: Verbindungen zu einem Ziel in nahezu festen Intervallen (selbst mit Jitter), kleine, gleichförmige Anfragen, niedrige Verhältnisse von eingehenden zu ausgehenden Daten, langlebige seltene Ziele sowie verdächtige TLS/JA3-Fingerabdrücke oder merkwürdige User-Agents. Das Signal ist der Rhythmus und die Seltenheit des Ziels, nicht der Payload — der in der Regel verschlüsselt ist.

Beginnen Sie bei den Techniken, die Sie erkennen wollen, und arbeiten Sie rückwärts zur Telemetrie, die sie offenbart — ATT&CKs Datenquellen-Mapping hilft. In der Praxis sind die wertvollsten Quellen die Endpoint-Telemetrie zu Prozessen/Befehlszeilen und Modul-Ladevorgängen (EDR/Sysmon), Authentifizierungs- und Identitätslogs, DNS und Proxy-/Netzwerkflüsse sowie Cloud-Control-Plane-Logs. Anschließend prüfen Sie, was Sie tatsächlich sammeln und aufbewahren, gegen das, was jede Technik benötigt, und decken so Sichtbarkeitslücken auf. Eine Technik, die in keinem Log sichtbar ist, ist noch nicht jagbar.

Detection Engineering behandelt Erkennungen als Softwareprodukt mit einem Lebenszyklus: eine abzudeckende Bedrohung oder Technik identifizieren, Telemetrie und Verhalten erforschen, die Regel entwickeln, sie gegen Echt-Positiv- und gutartige Daten testen, sie bereitstellen (oft gestaffelt), per Adversary-Emulation validieren, dann fortlaufend auf Fehlalarme abstimmen und Regeln ausmustern, die sich nicht mehr lohnen. Jede Phase wird dokumentiert und versioniert, und die Abdeckung wird gegen ein Rahmenwerk wie ATT&CK verfolgt.

LOLBins (Living-off-the-Land-Binaries) sind legitime, signierte, vorinstallierte Systemwerkzeuge — wie certutil, bitsadmin, mshta, rundll32, regsvr32, wmic, powershell — die Angreifer missbrauchen, um herunterzuladen, auszuführen oder zu persistieren, während sie sich in die normale Administratortätigkeit einfügen. Da die Binärdatei selbst vertrauenswürdig ist, kann man nicht auf die Datei erkennen; man erkennt auf den Kontext: anomale Befehlszeilenargumente, ungewöhnliche Elternprozesse, unerwartete Netzwerkverbindungen von diesen Werkzeugen sowie Ausführung aus merkwürdigen Pfaden oder durch merkwürdige Benutzer.

Die Pyramid of Pain ordnet Indikatortypen danach, wie aufwendig es für einen Angreifer ist, sie zu ändern, sobald Sie darauf erkennen. Hashes sind trivial zu verändern (unten), dann IP-Adressen, Domainnamen, Netzwerk-/Host-Artefakte, Werkzeuge und schließlich TTPs an der Spitze — die ein Angreifer nur ändern kann, indem er sein Verhalten grundlegend umrüstet. Auf höheren Ebenen zu erkennen verursacht mehr «Schmerz» und ist dauerhafter, daher investieren reife Programme den Erkennungsaufwand eher in Verhalten und TTPs als nur in IOCs.

TTP-basiertes Hunting nutzt MITRE ATT&CK als Karte: Wählen Sie eine für Ihr Bedrohungsmodell relevante Technik (idealerweise eine mit schwacher Abdeckung), bilden Sie eine konkrete Hypothese, wie sie in Ihrer Telemetrie erscheinen würde, identifizieren Sie die Datenquellen, die sie offenbaren, fragen Sie ab und analysieren Sie die Treffer. Ein guter Hunt ist abgegrenzt, hypothesengetrieben, an ein echtes Angreiferverhalten gebunden, wiederholbar und erzeugt ein dauerhaftes Ergebnis — eine neue Erkennung, eine dokumentierte Abdeckungslücke oder den Nachweis, dass die Technik nicht vorhanden ist — unabhängig davon, ob er eine Kompromittierung findet.

UEBA (User and Entity Behaviour Analytics) erstellt Verhaltens-Baselines für Benutzer und Entitäten (Hosts, Dienstkonten, Geräte) und nutzt Statistik oder maschinelles Lernen, um Abweichungen als Risiko zu bewerten. Es glänzt bei Bedrohungen ohne saubere Signatur: kompromittierte Anmeldedaten, Insider- Missbrauch und laterale Bewegung — z. B. ein Benutzer, der plötzlich auf Systeme zugreift, die er nie berührt, zu ungewöhnlichen Zeiten oder anomale Datenmengen bewegt. Es ergänzt die regelbasierte Erkennung, statt sie zu ersetzen, und braucht Abstimmung, um Fehlalarme durch legitime Verhaltensänderungen zu vermeiden.

Threat Hunting ist die proaktive, hypothesengetriebene Praxis, Telemetrie nach Aktivitäten eines Angreifers zu durchsuchen, die vorhandene Erkennungen verpasst haben. Anders als das Alarm-Triage — das reaktiv ist und darauf wartet, dass ein Werkzeug auslöst — beginnt das Hunting mit einer Frage («wenn ein Angreifer X täte, welche Spuren würde ich sehen?»), prüft sie gegen die Daten und findet entweder etwas oder erzeugt eine neue Erkennung. Es geht davon aus, dass Prävention und Alarme unvollkommen sind und ein entschlossener Angreifer bereits drinnen sein könnte.

Sigma ist ein offenes, herstellerneutrales YAML-Format zur Beschreibung von SIEM-Detections. Du definierst eine logsource (Produkt/Kategorie, z. B. Windows process_creation), einen detection-Block mit benannten Selektionen von Feld/Wert-Treffern und eine condition, die sie kombiniert. Ein Konverter (wie sigma-cli/pySigma) übersetzt die Regel in die Abfragesprache deines tatsächlichen Backends — Splunk, Sentinel, Elastic —, sodass eine Regel portabel ist. Sie trägt außerdem Metadaten: title, level, status, False Positives und ATT&CK-Tags.

Zugriffsüberprüfungen (Rezertifizierung) sind periodische Prüfungen, bei denen ein verantwortlicher Eigentümer bestätigt, dass der Zugriff jeder Person weiterhin gerechtfertigt ist, und widerruft, was es nicht ist. Sie sind das Sicherheitsnetz, das Privilegienwucherung, verwaiste Konten und für ein beendetes Projekt erteilte Berechtigungen aufspürt. Die Kontrolle funktioniert nur, wenn ein sachkundiger Eigentümer — meist der Vorgesetzte oder Ressourceneigentümer — den Zugriff wirklich prüft, statt ihn gedankenlos abzunicken, und wenn Widerrufe durchgesetzt werden.

Bedingter Zugriff macht die Zugriffsentscheidung vom Kontext abhängig statt von einer festen Regel. Er wertet Signale aus — wer der Benutzer ist, Gerätekonformität, Standort, die App und einen aus Anomalieerkennung berechneten Risikowert — und reagiert verhältnismäßig: erlauben, blockieren oder eine Verschärfung wie MFA oder ein konformes Gerät verlangen. Risikobasierter Zugriff ist die dynamische Variante, bei der ein Echtzeit-Risikosignal die Richtlinie steuert.

Just-in-Time-Zugriff gewährt erhöhte Privilegien nur bei Bedarf, für begrenzte Zeit, meist mit Genehmigung — danach laufen sie automatisch ab, sodass es kein dauerhaftes Privileg zu stehlen gibt. Break-Glass-Konten sind die bewusste Ausnahme: hochprivilegierte Notfallkonten, normalerweise ruhend, hinter strengen Kontrollen und starken Alarmen verriegelt, die nur genutzt werden, wenn die normalen Zugriffswege versagen. JIT verkleinert die alltägliche Angriffsfläche; Break-Glass garantiert, dass man in einer Krise dennoch hineinkommt.

Das moderne NIST SP 800-63B stellt Länge über Komplexität: lange Passphrasen erlauben (mindestens 8, 64+ unterstützen), alle Zeichen einschließlich Leerzeichen akzeptieren und keine Zusammensetzungsregeln wie «ein Großbuchstabe, ein Symbol» vorschreiben. Neue Passwörter gegen Listen geleakter Passwörter prüfen, den verpflichtenden periodischen Ablauf streichen (nur bei Hinweis auf Kompromittierung wechseln) und wissensbasierte «Sicherheitsfragen» verwerfen. Ziel sind Regeln, die echten Angriffen standhalten, statt Benutzer in vorhersehbare Muster zu drängen.

Phishing-resistente MFA bedeutet, dass der zweite Faktor nicht gegen die echte Seite wiedereingespielt werden kann, selbst wenn der Benutzer getäuscht wird. FIDO2/WebAuthn-Passkeys erreichen das mit ursprungsgebundener Public-Key-Kryptografie: Der Authentikator signiert eine an die Domain der echten Seite gebundene Challenge, sodass eine von einer Nachahmerseite oder einem Angreifer-in-der-Mitte erbeutete Anmeldeinformation nutzlos ist. TOTP-Codes und Push-Aufforderungen bleiben phishbar, weil sie in Echtzeit weitergeleitet werden können.

PAM kontrolliert und überwacht die Konten, die den größten Schaden anrichten können — Domänenadministratoren, root, Dienstkonten. Es tresoriert und rotiert ihre Anmeldedaten, damit keine Geheimnisse geteilt oder hartkodiert werden, vermittelt Sitzungen, sodass Administratoren das rohe Passwort nie sehen, zeichnet auf, was privilegierte Benutzer tun, und gewährt die Erhöhung idealerweise just-in-time statt als dauerhaften Zugriff. Ziel ist es, den Schadensradius der Konten zu verkleinern, die Angreifer am meisten begehren.

RBAC vergibt Berechtigungen über Rollen, die Benutzern zugewiesen werden — einfach nachzuvollziehen, aber anfällig für eine Rollenexplosion, je mehr Sonderfälle entstehen. ABAC wertet Richtlinien über Attribute von Benutzer, Ressource, Aktion und Umgebung aus und skaliert so auf feingranulare, kontextbewusste Entscheidungen, allerdings auf Kosten der Komplexität. Die meisten reifen Systeme kombinieren beides: Rollen für grobe Vergaben, Attribute und Richtlinien für die bedingten Details.

SCIM (System for Cross-domain Identity Management) ist eine standardisierte REST/JSON-API und ein Schema zum Erstellen, Aktualisieren und Löschen von Benutzerkonten über Anwendungen hinweg. An ein HR-System oder einen IdP angebunden, automatisiert es den Joiner-Mover-Leaver-Lebenszyklus: Konten und Berechtigungen werden bei Einstellung provisioniert, bei Rollenwechsel angepasst und — am wichtigsten — beim Austritt deprovisioniert, was die verwaisten Konten beseitigt, die Angreifer lieben.

Halte Access-Tokens kurzlebig (Minuten), damit ein gestohlenes schnell abläuft, und nutze langlebigere Refresh-Tokens, um neue Access-Tokens zu erhalten, ohne den Benutzer erneut aufzufordern. Rotiere Refresh-Tokens bei jeder Verwendung und erkenne die Wiederverwendung eines verbrauchten Tokens als Diebstahlsignal, das die Kette widerruft. Das Ziel ist, das Begrenzen des Fensters eines kompromittierten Tokens gegen das Vermeiden ständiger erneuter Anmeldungen abzuwägen.

Zero Trust verwirft die Annahme, dass das Sich-im-Netzwerk-Befinden dich vertrauenswürdig macht. Jede Anfrage an eine Ressource wird auf ihre eigenen Merkmale hin authentifiziert und autorisiert — Verifikation von Identität, Gerätegesundheit und Kontext — durch einen Policy Decision Point, der Least-Privilege-Zugriff pro Session gewährt. Es gibt keine vertrauenswürdige interne Zone; der Netzwerkstandort einer Anfrage ist nur ein Signal, kein Freifahrtschein.

Coordinated Vulnerability Disclosure ist ein Prozess, bei dem ein Forscher eine Schwachstelle privat an den Hersteller meldet, beide Seiten sich auf Behebung und Zeitplan einigen und Details erst veröffentlicht werden, sobald ein Fix verfügbar ist (oder eine vereinbarte Frist abläuft). Sie wägt die Zeit zum Patchen für Verteidiger gegen das Recht der Öffentlichkeit auf Information ab. Eine security.txt-Datei und eine klare Richtlinie machen das Melden reibungslos; Bug-Bounty-Programme fügen darauf strukturierte Belohnungen hinzu.

ATT&CK ist eine Wissensbasis realer Angreifer-Taktiken (das Warum), Techniken (das Wie) und Prozeduren. Sie nutzen es, um Ihre bestehenden Detektionen auf die Matrix zu mappen, Abdeckungslücken zu finden und die Techniken zu priorisieren, die von Akteuren genutzt werden, die tatsächlich Ihre Branche angreifen. Es bietet eine gemeinsame Sprache zwischen CTI, Detection Engineering und IR und verwandelt die Frage nach der Sicherheit in eine konkrete, messbare Abdeckungskarte, getrieben vom realen Angreiferverhalten.

Ein sicherer SDLC bettet Sicherheit in jede Phase ein, statt am Ende zu testen: Anforderungen (Sicherheits- und Missbrauchsfälle), Design (Threat Modeling), Implementierung (sichere Coding-Standards, SAST/SCA in der IDE und CI), Test (DAST, Pentest), Release (Gates und Freigabe) und Betrieb (Monitoring, Patching, Feedback). Shift-Left verlagert Defekte nach vorne, wo sie billig zu beheben sind; Reifegradmodelle wie OWASP SAMM und BSIMM messen, wie gut man es tatsächlich tut.

Schwachstellenmanagement ist eine fortlaufende Schleife: Assets und Schwachstellen entdecken (Scanning, Asset-Inventar), nach echtem Risiko priorisieren (CVSS plus Ausnutzbarkeit, Exposition und Asset-Kritikalität — Frameworks wie EPSS und SSVC helfen), beheben oder mindern, den Fix verifizieren und über Trends und SLAs berichten. Der Scan ist der leichte Teil; die Disziplin liegt darin, zu priorisieren und die Schleife zu schließen, damit das Risiko mit der Zeit tatsächlich sinkt.

SSH nutzt TCP 22, HTTP TCP 80, HTTPS TCP 443, DNS den 53 (UDP und TCP), RDP TCP 3389 und SMB TCP 445. Die Well-Known-Ports zu kennen, erlaubt es, Scan-Ausgaben zu lesen, Firewall-Regeln zu schreiben und Alarme schnell zu triagieren — ein Dienst auf seinem erwarteten Port statt auf einem unerwarteten ist ein sofortiges Signal.

Ein Stub-Resolver fragt einen rekursiven Resolver nach einem Namen. Ist er nicht im Cache, durchläuft der rekursive Resolver die Hierarchie: Er fragt einen Root-Server (der auf die TLD verweist), den TLD-Server (der auf die autoritativen Server der Domain verweist) und schließlich den autoritativen Server, der den eigentlichen Eintrag hält. Die Antwort wird unterwegs gemäß ihrer TTL gecacht. DNS nutzt Port 53 — UDP für die meisten Anfragen, TCP für große.

Ein Forward-Proxy steht vor den Clients und stellt ausgehende Anfragen in deren Namen — für Egress-Kontrolle, Filterung, Caching und Anonymität. Ein Reverse-Proxy steht vor den Servern und empfängt eingehende Anfragen in deren Namen — für Lastausgleich, TLS-Terminierung, Caching und als Sicherheitsfassade für eine WAF. Die Richtung, in die er zeigt, clientseitig oder serverseitig, ist die entscheidende Unterscheidung.

Traceroute entdeckt die Router zwischen Ihnen und einem Ziel, indem es das TTL-Feld ausnutzt. Es sendet Pakete mit TTL=1, dann 2, dann 3 und so weiter. Jeder Router verringert die TTL; erreicht die TTL null, verwirft dieser Router das Paket und gibt eine ICMP-Time-Exceeded-Nachricht zurück, die seine Adresse offenbart. Durch das schrittweise Erhöhen der TTL bildet traceroute jeden Hop der Reihe nach ab, bis das Ziel erreicht ist.

NAT (Network Address Translation) schreibt die Quell- und/oder Ziel-IP um, während Pakete eine Grenze überqueren, und bildet typischerweise private interne Adressen auf öffentliche ab. PAT (Port Address Translation oder NAT Overload) erweitert dies, indem es auch Ports übersetzt, sodass viele interne Hosts sich eine einzige öffentliche IP teilen — jeder Fluss durch seinen Port unterschieden. PAT ist das, was Heim- und Büro-Router nutzen, um ein ganzes LAN hinter eine Adresse zu setzen.

Das OSI-Modell teilt Netzwerke in sieben Schichten, von denen jede eine Verantwortung hinzufügt: Bitübertragung (Bits auf dem Kabel), Sicherung (Frames und MAC-Adressierung), Vermittlung (IP-Routing), Transport (TCP/UDP, Ports, Zuverlässigkeit), Sitzung (Verwaltung von Verbindungen), Darstellung (Kodierung, Verschlüsselung, Kompression) und Anwendung (Protokolle wie HTTP). Jede Schicht kapselt die darüberliegende, während die Daten den Stapel hinabwandern.

Ein Subnetz ist eine logische Unterteilung eines IP-Netzes. Die Subnetzmaske markiert, welche Bits einer IP-Adresse der Netz-Anteil und welche der Host-Anteil sind — zum Beispiel bedeutet /24 (255.255.255.0), dass die ersten 24 Bit das Netz und die letzten 8 die Hosts kennzeichnen. Subnetting steuert, wie Verkehr geroutet wird, und erlaubt es, ein Netz in kleinere Broadcast-Domänen zu segmentieren.

TCP öffnet eine Verbindung in drei Schritten. Der Client sendet ein SYN mit einer initialen Sequenznummer, der Server antwortet mit SYN-ACK (bestätigt die Nummer des Clients und sendet seine eigene), und der Client gibt ein ACK zurück. Nach diesem Austausch haben sich beide Seiten auf die Start-Sequenznummern geeinigt, und die Verbindung ist für eine zuverlässige, geordnete Byte-Zustellung aufgebaut.

TCP ist verbindungsorientiert: es macht einen Handshake, nummeriert Bytes, überträgt Verluste neu und steuert die Überlastung, was eine zuverlässige geordnete Zustellung auf Kosten von Latenz und Overhead bietet. UDP ist verbindungslos und nach dem Prinzip senden-und-vergessen — kein Handshake, keine Neuübertragung, keine Ordnung. Nutzen Sie TCP, wenn Korrektheit zählt (Web, E-Mail, Dateiübertragung), und UDP, wenn Geschwindigkeit mehr zählt als Perfektion (DNS, VoIP, Gaming, Video).

Das TCP/IP-Modell hat vier Schichten — Netzzugang, Internet, Transport und Anwendung — und beschreibt, wie das reale Internet funktioniert. OSI hat sieben. Sie bilden eng aufeinander ab: Die Anwendungsschicht von TCP/IP nimmt die Anwendungs-, Darstellungs- und Sitzungsschicht von OSI auf; seine Netzzugangsschicht vereint die Bitübertragungs- und Sicherungsschicht von OSI. OSI ist die bessere Referenz zum Lehren und zur Fehlersuche; TCP/IP ist die tatsächlich umgesetzte Protokollsuite.

Ein VLAN (Virtual LAN) partitioniert einen physischen Switch logisch in getrennte Layer-2-Broadcast-Domänen, sodass Geräte in unterschiedlichen VLANs sich selbst auf derselben Hardware nicht direkt erreichen können. Es wird auf Trunk-Verbindungen mit einem 802.1Q-Tag gekennzeichnet. Der Sicherheitswert ist die Segmentierung: das Isolieren von Benutzer-, Server-, Gast- und IoT-Verkehr begrenzt die Broadcast-Reichweite und die laterale Bewegung, wobei VLAN-übergreifender Verkehr durch einen Router oder eine Firewall geleitet wird, wo Richtlinien angewendet werden.

Ein VPN erstellt einen verschlüsselten Tunnel auf Netz-/Betriebssystemebene, sodass der gesamte Verkehr eines Geräts hindurchgeleitet und Ende-zu-Ende geschützt wird — genutzt für sicheren Fernzugriff. Ein Proxy arbeitet auf Anwendungsebene, leitet den Verkehr bestimmter Anwendungen oder Protokolle weiter und verschlüsselt ihn nicht zwingend. Die großen Unterschiede sind der Geltungsbereich (ganzes Gerät vs. pro Anwendung) und dass ein VPN per Design verschlüsselt, während viele Proxys das nicht tun.

Eine DMZ (demilitarisierte Zone) ist ein Netzsegment, das zwischen dem nicht vertrauenswürdigen Internet und dem vertrauenswürdigen internen Netz sitzt und öffentlich erreichbare Dienste wie Web-, Mail- und DNS-Server beherbergt. Firewall-Regeln lassen das Internet die DMZ erreichen, beschränken aber den Zugriff der DMZ auf das interne Netz streng. Das Ziel ist Eindämmung: wird ein öffentlicher Server kompromittiert, steckt der Angreifer in der Pufferzone fest, statt im LAN zu landen.

Man beginnt mit einem vollständigen TCP-Portscan und enumeriert dann jeden offenen Dienst gründlich — Banner, Versionen, Standardanmeldedaten, anonymer Zugriff und Webinhalte — bevor man irgendeinen Exploit anrührt. Die meisten Maschinen fallen durch gründliche Enumerierung, nicht durch clevere Exploits, was den Kern der „try harder“-Haltung ausmacht.

Nutze den kompromittierten Host als Relais in das unerreichbare Subnetz. Richte eine Portweiterleitung für einen einzelnen Dienst ein oder einen dynamischen SOCKS-Proxy (SSH -D oder chisel) und leite deine Werkzeuge mit proxychains darüber, damit deine Angreifer-Maschine interne Hosts über den Pivot erreicht.

Enumeriere die aktuellen Privilegien (whoami /priv), fehlkonfigurierte Dienste (schwache Berechtigungen, ungequotete Dienstpfade), AlwaysInstallElevated, geplante Aufgaben, gespeicherte Anmeldedaten und fehlende Patches. WinPEAS oder PowerUp automatisieren den Durchlauf; Token-Privilegien-Missbrauch wie SeImpersonate ist ein häufiger, wertvoller Treffer.

Defense in Depth bedeutet, mehrere unabhängige Sicherheitskontrollen zu staffeln, sodass bei Versagen einer Kontrolle die anderen das Asset weiterhin schützen. Keine Kontrolle gilt als perfekt, daher stapelt man präventive, detektierende und reagierende Maßnahmen über die Schichten Netzwerk, Host, Anwendung und Daten.

Angriffsfläche reduzieren (ungenutzte Pakete/Dienste entfernen), SSH nur per Schlüssel und ohne Root-Login erzwingen, das System gepatcht halten, eine Default-Deny-Firewall betreiben, die nur nötige Ports freigibt, geringste Rechte über sudo und Dateirechte durchsetzen, auditd und zentrales Logging aktivieren sowie Integritätsüberwachung plus ein MAC wie SELinux oder AppArmor ergänzen.

Verschlüsselung ist umkehrbar – mit dem Schlüssel erhältst du den Klartext zurück; sie schützt die Vertraulichkeit. Hashing ist eine Einwegfunktion, die einen Digest fester Größe erzeugt, den man nicht umkehren kann; es verifiziert Integrität und Identität. Passwörter sollten mit einem langsamen, gesalzenen Algorithmus wie bcrypt oder Argon2 gehasht, niemals verschlüsselt werden.

Geringste Rechte bedeutet, dass jeder Benutzer, Prozess oder Dienst nur den minimal für seine Aufgabe nötigen Zugriff erhält, und nicht mehr. Das verkleinert den Wirkungsradius jeder Kompromittierung oder jedes Fehlers. Man setzt es mit rollenbasiertem Zugriff, Just-in-Time-Erhöhung, regelmäßigen Zugriffsüberprüfungen und der Abschaffung dauerhafter Adminrechte durch.

Secrets niemals fest im Quellcode codieren oder in Git committen. In einem dedizierten Secrets Manager oder Vault speichern, zur Laufzeit injizieren, den Zugriff mit geringsten Rechten begrenzen, regelmäßig rotieren und kurzlebige dynamische Anmeldeinformationen langlebigen statischen vorziehen. Jeden Zugriff auditieren.

Ein sicherer SDLC verankert Sicherheit in jeder Phase, statt sie am Ende anzuflanschen. Anforderungen umfassen Sicherheits- und Missbrauchsfälle, Design ergänzt Threat Modeling, Entwicklung nutzt sicheres Coding und SAST plus Dependency Scanning, Tests ergänzen DAST und Penetrationstests, und Betrieb ergänzt Monitoring, Patching und Incident Response – Sicherheit nach links verlagert.

Überall TLS erzwingen, jede Anfrage authentifizieren (z. B. OAuth2/OIDC-Tokens) und pro Objekt autorisieren, sodass Benutzer nur ihre eigenen Daten erreichen. Eingabevalidierung, Rate Limiting und Kontingente, Schemavalidierung sowie gründliches Logging ergänzen. Der häufigste API-Fehler ist gebrochene objektbezogene Autorisierung, also prüfe bei jedem Ressourcenzugriff die Eigentümerschaft.

Segmentierung teilt ein Netzwerk in isolierte Zonen, sodass ein Einbruch in einer die anderen nicht ungehindert erreichen kann, was laterale Bewegung begrenzt. Zero Trust geht weiter: Es entfernt implizites Vertrauen auf Basis des Netzwerkstandorts vollständig und authentifiziert und autorisiert jede Anfrage, egal woher sie stammt – Mikrosegmentierung ist eine Möglichkeit, es umzusetzen.

Symmetrische Verschlüsselung nutzt einen gemeinsamen Schlüssel zum Ver- und Entschlüsseln – schnell, aber der Schlüssel muss sicher geteilt werden. Asymmetrische Verschlüsselung nutzt ein Schlüsselpaar aus öffentlich/privat, was die Schlüsselverteilung löst, aber langsam ist. Reale Systeme nutzen asymmetrische Kryptografie, um einen symmetrischen Sitzungsschlüssel auszutauschen, und dann die schnelle symmetrische Chiffre für die Massendaten.

Eine PKI ist das System aus CAs, Zertifikaten und Richtlinien, das öffentliche Schlüssel an Identitäten bindet. Um ein Serverzertifikat zu validieren, baut ein Client eine Kette zu einer vertrauenswürdigen Wurzel auf, prüft jede Signatur, kontrolliert Gültigkeitsdaten und Hostname, bestätigt die Schlüsselverwendung und prüft die Sperrung über CRL oder OCSP.

Alert-Fatigue ist die Abstumpfung, die einsetzt, wenn Analysten mit zu vielen wertarmen Alerts oder Fehlalarmen konfrontiert sind, sodass sie echte Alerts übersehen oder überhastet bearbeiten. Man bekämpft sie, indem man laute Regeln tunt, nach Risiko priorisiert, zusammenhängende Alerts dedupliziert und gruppiert, repetitive Anreicherung mit einem SOAR automatisiert und die Qualität der Alerts misst, nicht nur die Menge.

Fast alles berührt DNS, daher offenbaren DNS-Logs Bedrohungen, die andere Quellen verpassen: Command-and-Control-Beaconing (regelmäßige Callbacks zu einer Domain), DNS-Tunneling und -Exfiltration (hohes Volumen langer, kodierter Subdomains) sowie algorithmisch generierte (DGA) Domains. Man erkennt sie über Muster wie Abfrageregelmäßigkeit, Entropie, Record-Typen und Volumen statt über eine einzelne verdächtige Abfrage.

EDR ist endpointfokussiert: Es zeichnet Prozess-, Datei- und Netzwerkaktivität auf Hosts auf und reagiert darauf. XDR erweitert diese Korrelation über mehrere Domänen — Endpoint, Netzwerk, Identität, E-Mail, Cloud — als eine herstellerintegrierte Stack. SIEM ist die breite Log-Aggregationsschicht, die Daten aus allem aufnimmt, auch aus sicherheitsfremden Quellen, für Detektion, Suche und Compliance.

Verstehen Sie zuerst, warum die Regel so oft auslöst — finden Sie das gemeinsame harmlose Muster hinter dem Rauschen. Schreiben Sie dann die engstmögliche Ausnahme (bestimmter Host, Konto oder Verhalten), dokumentieren Sie die Begründung und prüfen Sie, dass ein echter Treffer weiterhin auslösen würde. Vermeiden Sie breite Unterdrückungen, die still blinde Flecken schaffen.

ATT&CK ist eine Wissensbasis realer gegnerischer Taktiken und Techniken. In einem SOC bildet man jede Detektionsregel auf die Techniken ab, die sie abdeckt, baut eine Abdeckungskarte (oft mit dem ATT&CK Navigator) und priorisiert dann das Schließen von Lücken danach, welche Techniken für das eigene Bedrohungsmodell am relevantesten sind und auf welche man keinerlei Sichtbarkeit hat.

Ein SIEM nimmt Logs aus dem gesamten Bestand auf und korreliert sie, um Alerts zu erzeugen — es ist Ihre Detektions- und Suchschicht. Ein SOAR sitzt nachgelagert und automatisiert die Reaktion: Es führt Playbooks aus, reichert Alerts über Integrationen an und übernimmt das Case-Management, damit Analysten weniger Zeit für repetitive Schritte aufwenden.

Content-Security-Policy ist ein HTTP-Antwort-Header, der dem Browser mitteilt, welche Quellen von Skripten, Stilen, Bildern und anderen Inhalten auf einer Seite geladen und ausgeführt werden dürfen. Indem sie Inline-Skripte und nicht vertrauenswürdige Quellen untersagt — idealerweise über Nonces oder Hashes — dient sie als Defense-in-Depth-Absicherung, die eingeschleuste XSS-Payloads neutralisiert, selbst wenn eine durchrutscht.

CSRF bringt den Browser eines angemeldeten Nutzers dazu, eine zustandsändernde Anfrage an eine Website zu senden, bei der er authentifiziert ist, und nutzt dabei aus, dass Cookies automatisch mitgesendet werden. Verhindert wird es mit Anti-CSRF-Tokens (ein geheimer Wert pro Sitzung, den der Angreifer weder lesen noch erraten kann) und dem SameSite-Cookie-Attribut, das verhindert, dass Cookies bei Cross-Site-Anfragen mitgeschickt werden.

Die OWASP Top 10 sind ein von der Community getragenes Bewusstseinsdokument, das die kritischsten Sicherheitsrisiken von Webanwendungen einstuft und alle paar Jahre auf Basis realer Daten aktualisiert wird. Es ist weder eine Checkliste noch ein Standard, sondern ein Ausgangspunkt — aktuelle Einträge sind unter anderem fehlerhafte Zugriffskontrolle (Nr. 1), kryptografische Fehler, Injection und unsicheres Design.

Speichere Passwörter niemals im Klartext oder umkehrbar verschlüsselt und niemals mit schnellen Allzweck-Hashes wie MD5 oder SHA-256. Verwende eine langsame, speicherintensive Passwort-Hashfunktion — Argon2id (bevorzugt) oder bcrypt — mit einem eindeutigen Zufalls-Salt pro Passwort und einem abgestimmten Arbeitsfaktor, sodass ein Angreifer, der die Datenbank stiehlt, die Hashes nicht realistisch knacken kann.

Prepared Statements senden zuerst die Abfragevorlage mit Platzhaltern an die Datenbank, sodass die Struktur feststeht, bevor irgendwelche Nutzerdaten eintreffen. Parameter werden danach als reine Daten gebunden und können niemals als SQL geparst werden — eine Eingabe wie ' OR 1=1 wird also als Zeichenkettenliteral behandelt, nicht als Code. Diese Trennung ist die kanonische, zuverlässige Lösung gegen Injection.

Die primäre Verteidigung ist kontextbezogene Ausgabecodierung — nicht vertrauenswürdige Daten genau für die Stelle codieren, an der sie landen (HTML-Körper, Attribut, JavaScript, URL). Kombiniere das mit sicheren DOM-APIs (textContent statt innerHTML), dem automatischen Escaping von Frameworks, Eingabevalidierung und einer Content-Security-Policy als Defense-in-Depth-Absicherung, die begrenzt, welche Skripte laufen dürfen.

Die Same-Origin Policy ist die Browser-Regel, dass ein Skript aus einem Origin (Schema + Host + Port) die Antworten eines anderen Origins nicht lesen kann, was authentifizierte Sitzungen schützt. CORS ist eine kontrollierte Lockerung: Ein Server gibt Access-Control-Allow-Origin-Header zurück, um bestimmten Origins ausdrücklich das Lesen seiner Antworten zu erlauben, und lockert so die SOP, statt sie zu umgehen.

HttpOnly verbirgt das Cookie vor JavaScript, sodass XSS es nicht über document.cookie stehlen kann. Secure stellt sicher, dass das Cookie nur über HTTPS gesendet wird, und blockiert das Abfangen im Netzwerk. SameSite steuert, ob das Cookie bei Cross-Site-Anfragen gesendet wird, und mildert CSRF ab. Zusammen härten sie Sitzungs-Cookies gegen die häufigsten Diebstahl- und Missbrauchswege.

Zu den wichtigsten Sicherheits-Headern zählen Strict-Transport-Security (erzwingt HTTPS, blockiert SSL-Stripping), Content-Security-Policy (begrenzt Skriptquellen, mildert XSS), X-Frame-Options oder CSP frame-ancestors (blockiert Clickjacking), X-Content-Type-Options: nosniff (stoppt MIME-Sniffing) und Referrer-Policy (steuert das Durchsickern des Referrers). Jeder adressiert eine bestimmte Angriffsklasse.

SQL-Injection erlaubt einer Angreifereingabe, eine Abfrage zu verändern. In-Band-Techniken geben Daten direkt zurück: Die UNION-basierte hängt ein UNION SELECT an, um zusätzliche Spalten zu ziehen, und die fehlerbasierte lässt Daten über Datenbank-Fehlermeldungen durchsickern. Wenn keine Ausgabe sichtbar ist, nutzen Angreifer blinde SQLi — die boolesche schließt Daten aus Unterschieden in Wahr/Falsch-Antworten, die zeitbasierte nutzt Verzögerungen wie SLEEP(), um Daten Bit für Bit zu lesen.

HTTP ist zustandslos — jede Anfrage ist unabhängig und hat keine Erinnerung an vorherige. Sitzungen fügen darauf Zustand hinzu: Nach der Anmeldung gibt der Server eine Kennung aus, die der Browser in einem Cookie speichert und bei jeder Anfrage erneut sendet. Serverseitige Sitzungen halten den Zustand auf dem Server, indiziert über eine undurchsichtige Sitzungs-ID; zustandslose Tokens wie JWTs legen signierten Zustand in das Token selbst, sodass der Server ohne Speicher prüfen kann.

Jedes XSS schleust vom Angreifer kontrolliertes Skript in den Browser eines Opfers ein. Stored XSS speichert die Payload dauerhaft auf dem Server (z. B. einen Kommentar) und trifft jeden, der sie ansieht; Reflected XSS spiegelt die Payload in einer einzelnen Antwort vom Server zurück, meist über einen präparierten Link; DOM-basiertes XSS erreicht nie die Serverlogik — verwundbares clientseitiges JavaScript schreibt nicht vertrauenswürdige Eingaben in die Seite.

XXE missbraucht einen XML-Parser, der externe Entitäten auflöst, die in der DTD eines Dokuments definiert sind. Ein Angreifer deklariert eine Entität, die auf eine lokale Datei oder interne URL zeigt, und der Parser ruft sie ab — was Dateioffenlegung, SSRF und Dienstverweigerung ermöglicht. Die Lösung ist, DTD-Verarbeitung und externe Entitätsauflösung in der Parser-Konfiguration zu deaktivieren.