Interviewfragen zu CISSP

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 Cloud läuft nach einem Modell geteilter Verantwortung: Der Anbieter sichert die zugrunde liegende Infrastruktur („Sicherheit der Cloud“), aber du bleibst verantwortlich für deine Daten, das Identitäts- und Zugriffsmanagement, die Konfiguration und — bei IaaS — das Betriebssystem und Patches („Sicherheit in der Cloud“). Die große Mehrheit der Cloud-Verstöße sind kundenseitige Fehlkonfigurationen wie öffentliche Buckets und zu freizügiges IAM, keine Anbieterausfälle. Anzunehmen, der Anbieter sichere deine Daten, ist genau, wie diese Verstöße entstehen.

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.

Eine zuverlässige Vorfallrekonstruktion entsteht durch die Korrelation unabhängiger Telemetrie zu einer Zeitachse: Authentifizierungsprotokolle, EDR-Prozess-/Ausführungsdaten, MAC-Zeitstempel des Dateisystems, Netzwerkflüsse und SIEM-Ereignisse, um Aktionen zu ordnen und den Umfang einzugrenzen. Ein einzelnes Protokoll oder das jüngste Ereignis allein verfehlt die Kette und kann irreführend oder manipuliert sein. Aus einer Quelle zu raten oder den Angreifer zu fragen, sind keine Ermittlungsmethoden. Die Korrelation über unabhängige Quellen offenbart die vollständige Angreiferaktivität und übersteht einen Angreifer, der eine davon bearbeitet hat.

Beweisintegrität beruht darauf, das Abbild bei der Erfassung zu hashen (z. B. SHA-256) und den Hash später zu verifizieren, um zu beweisen, dass es unverändert ist, eine dokumentierte Beweiskette zu führen und eine Arbeitskopie zu analysieren, damit das Original makellos bleibt. Das Umbenennen der Datei tut nichts für die Integrität, und das Komprimieren zum Platzsparen beweist weder Integrität noch hilft es der Zulässigkeit. Das Original anzufassen riskiert eine Beweisvernichtung, die dazu führen kann, dass der Beweis verworfen wird. Hashen, Verwahrung dokumentieren und an einer verifizierten Kopie arbeiten.

Balanciere Nutzbarkeit und Risiko: erzwinge Conditional Access gebunden an die Geräte-Posture und isoliere Unternehmensdaten in einem verwalteten Container (MAM/MDM), sodass sie kontrolliert und selektiv gelöscht werden können, ohne das gesamte Privatgerät zu übernehmen. Uneingeschränkter Zugriff riskiert Datenabfluss auf nicht verwalteten, womöglich kompromittierten Endpunkten. Ein striktes Verbot treibt zu unsicheren Umgehungen wie dem Weiterleiten an private Mail. Und Daten als Anhang zu mailen verstreut sie unkontrollierbar auf Geräte, die du nie zurückholst.

Kein einzelnes Produkt stoppt jeden Angriff; reife Sicherheit staffelt unabhängige Kontrollen — Defense in Depth — damit der Ausfall einer nicht die Kompromittierung bedeutet. Ordne die geplante Ausgabe den tatsächlichen Lücken in Identität, Netzwerk, Endpunkt, Daten und Erkennung zu und behalte die bereits funktionierenden, ergänzenden Kontrollen. Alles auf ein Werkzeug zu setzen schafft einen Single Point of Failure, und bestehende Kontrollen herauszureißen, um sie zu ersetzen, verringert die Abdeckung. Gar nichts auszugeben ignoriert echte Lücken.

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.

Bedrohungsmodellierung ist in der Designphase am günstigsten und wirksamsten, bevor Code Entscheidungen festzurrt: gehe die Datenflüsse durch, zähle Bedrohungen mit einem Rahmenwerk wie STRIDE auf, baue Gegenmaßnahmen ein und überarbeite sie, während sich das Design entwickelt. Sie erst nach einem Vorfall oder beim jährlichen Pentest zu machen, findet Probleme, wenn sie teuer zu beheben und bereits exponiert sind. Und sich auf „sorgfältige Entwickler" zu verlassen ist Hoffnung, keine wiederholbare, prüfbare Kontrolle.

Vertrauen anhand des Netzwerkstandorts bedeutet, dass ein einziger Fuß in der Tür breite laterale Bewegung gewährt — eine gephishte VPN-Zugangsdatei und der Angreifer ist „drin". Zero Trust beseitigt implizites Vertrauen: Jeder Zugriff wird authentifiziert, autorisiert und laufend anhand von Identität und Geräte-Posture neu bewertet, mit Least Privilege und Segmentierung (NIST SP 800-207). Ein zweites oder breiteres VPN dehnt nur dasselbe Flat-Trust-Problem aus, und dem LAN statt dem VPN zu vertrauen wiederholt den ursprünglichen Fehler.

Ohne Control-Plane-Audit-Logs bist du blind, wer auf Cloud-Ebene was getan hat, und Erkennung, Forensik und Compliance hängen alle von diesem Protokoll ab. Aktiviere CloudTrail sofort, organisationsweit, mit Lieferung an einen separaten, zugriffskontrollierten, manipulationssicheren (unveränderlichen) Bucket. Zu sagen, es sei egal, solange nichts schiefläuft, ignoriert, dass du keine Historie hättest, wenn doch etwas schiefläuft. Bis zu einem Vorfall zu warten bedeutet, dass die prägenden frühen Aktionen bereits unprotokolliert und unwiederbringlich sind. Anwendungslogs erfassen keine API-, IAM- oder Konsolenaktivität auf der Control Plane.

Eine überprivilegierte Instanzrolle macht jeden Fehler auf Anwendungsebene – insbesondere ein SSRF, das den Instance-Metadata-Service erreicht – zur vollständigen Konto-Übernahme, weil der Angreifer die Anmeldedaten der Rolle erbt. Ersetze den Wildcard durch die minimalen Aktionen und Ressourcen-ARNs, die die Workload tatsächlich nutzt, und erzwinge IMDSv2, um den Metadaten-Endpunkt zu härten. Ein VPC schränkt IAM überhaupt nicht ein. Eine einzelne Deny-Regel ist Whac-A-Mole und lässt alles andere erlaubt. Ein Load Balancer ist für den Schadensradius der Anmeldedaten irrelevant.

Folgen Sie der Reihenfolge der Flüchtigkeit. RAM, aktive Netzwerkverbindungen und die Prozesstabelle verschwinden beim Herunterfahren; erfassen Sie sie zuerst, dann erstellen Sie ein forensisches Disk-Image und dokumentieren Hashes sowie eine lückenlose Chain of Custody. Ein sauberes Herunterfahren zerstört speicherresidente Beweise — einschließlich dateiloser Malware und Schlüssel, die nur im RAM existieren. Kopieren-dann-Löschen manipuliert den Tatort und bricht die Integrität. Das Firmen-Antivirus auszuführen verändert das System und kann genau das Artefakt in Quarantäne stellen oder löschen, das Sie analysieren müssen.

Eindämmung schlägt verfrühte Wiederherstellung: Stoppen Sie die Ausbreitung, indem Sie betroffene Segmente isolieren und den Verbreitungsweg kappen — das missbrauchte Dienstkonto deaktivieren, SMB zwischen Segmenten blockieren, den Staging-Host vom Netz nehmen — bei gleichzeitiger Beweissicherung, dann eradieren und wiederherstellen. In ein Netz wiederherzustellen, das noch verschlüsselt, verliert die wiederhergestellten Daten erneut. Das Lösegeld zu zahlen stoppt die laufende Verschlüsselung nicht und birgt rechtliches und Sanktionsrisiko. Allen Maschinen den Strom zu kappen zerstört flüchtige Beweise und kann Dateien mitten im Schreiben beschädigen, was eine saubere Wiederherstellung erschwert.

Zu eradieren, bevor man den Umfang versteht, lässt den Angreifer auf nicht gefundenen Systemen persistieren und einfach zurückkehren. Jagen Sie schnell die IOCs und gestohlenen Anmeldedaten im gesamten Bestand, identifizieren Sie jeden betroffenen Host und jeden Persistenzmechanismus, und eradieren Sie dann überall gleichzeitig. Einen einzelnen Host zu löschen ist Whack-a-Mole, das den Angreifer warnt und seine anderen Stützpunkte intakt lässt. Ein einwöchiger vollständiger Internet-Blackout ist unverhältnismäßig und schadet dem Business. Nur die Malware-Datei zu löschen ignoriert Persistenz, Lateral Movement und die bereits gestohlenen Anmeldedaten.

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.

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.

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.

Geschäftskontinuität (BCP) ist die umfassende Strategie, um kritische Geschäftsfunktionen während und nach einer Störung am Laufen zu halten; Notfallwiederherstellung (DRP) ist die IT-fokussierte Teilmenge, die Systeme und Daten wiederherstellt. RTO ist die maximal tolerierbare Zeit zur Wiederherstellung einer Funktion; RPO ist der maximal tolerierbare, in Zeit gemessene Datenverlust.

Die Klassifizierung kennzeichnet Daten nach Sensibilität, damit die Organisation Kontrollen anwendet, die zu Wert und Risiko verhältnismäßig sind, und so sowohl Unterschutz als auch verschwenderischen Überschutz vermeidet. Der Dateneigentümer (eine Geschäftsrolle) legt die Klassifizierung fest und akzeptiert das Risiko, während der Datenverwalter (oft die IT) die Schutzkontrollen umsetzt und pflegt.

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.

Due Diligence ist die fortlaufende Untersuchung und das Verständnis von Risiken (wissen, was getan werden sollte), während Due Care das Ergreifen der angemessenen Maßnahmen ist, die eine umsichtige Person ergreifen würde, um sie anzugehen (es tatsächlich tun). Diligence ist Recherche und Aufsicht; Care ist Umsetzung und Pflege.

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.

Eine Richtlinie ist die übergeordnete verbindliche Absichtserklärung des Managements; ein Standard ist eine verbindliche konkrete Regel, die die Richtlinie durchsetzt (z. B. AES-256); eine Prozedur ist die verbindliche Schritt-für-Schritt-Anleitung; eine Leitlinie ist eine optionale Empfehlung. Richtlinien, Standards und Prozeduren sind verbindlich, während Leitlinien im Ermessen liegen.

Die quantitative Analyse weist konkrete Geldwerte zu, um den erwarteten Verlust zu berechnen; die qualitative Analyse stuft das Risiko auf relativen Skalen (hoch/mittel/niedrig) per Experteneinschätzung ein. Quantitativ verwendet SLE = Vermögenswert x Expositionsfaktor, ARO = erwartete Vorkommen pro Jahr und ALE = SLE x ARO, um den jährlich erwarteten Verlust in Euro auszudrücken.

Sie können mindern (Eintrittswahrscheinlichkeit/Auswirkung mit Kontrollen senken), übertragen (die finanzielle Auswirkung über Versicherung oder Verträge verlagern), vermeiden (die riskante Tätigkeit ganz einstellen) oder akzeptieren (das Restrisiko bewusst hinnehmen). Die Wahl hängt vom Risikoappetit und einem Kosten-Nutzen-Vergleich gegenüber dem erwarteten Verlust des Risikos ab.

Betten Sie Sicherheit in jede SDLC-Phase ein, statt am Ende zu testen: Anforderungen umfassen Sicherheits- und Datenschutzanforderungen, das Design umfasst Bedrohungsmodellierung, die Entwicklung folgt sicheren Codierstandards mit SAST, das Testen ergänzt DAST und Reviews, und das Release erfordert eine Freigabe — alles gesteuert durch Richtlinie, Funktionstrennung und Änderungskontrolle. Fehler früh zu beheben ist drastisch günstiger als nach dem Release.

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.

Die Signierung bindet ein Artefakt kryptografisch an seinen Hersteller, sodass Konsumenten überprüfen können, dass es nicht manipuliert oder ausgetauscht wurde. Die Provenienz sind signierte Metadaten, die beschreiben, wie, wo und aus welcher Quelle das Artefakt gebaut wurde. Zusammen — über Tools wie Sigstore für schlüssellose Signierung und das SLSA-Framework für Provenienzstufen — ermöglichen sie es einem Deployer zu überprüfen, dass ein Image aus der erwarteten Pipeline und Quelle stammt, und vereiteln so Manipulation und Angriffe durch Abhängigkeitssubstitution.

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.

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.

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.

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.

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.

Kontrollen werden auf zwei Arten klassifiziert. Nach Typ: administrativ (Richtlinien, Schulungen, Verfahren), technisch/logisch (Firewalls, MFA, Verschlüsselung) und physisch (Schlösser, Ausweise, Kameras). Nach Funktion: präventiv (ein Ereignis verhindern — MFA, Zugriffskontrolle), detektiv (ein Ereignis aufdecken — SIEM, IDS, Audit-Logs), korrektiv (danach beheben — Wiederherstellung aus Backup, Patch), abschreckend (entmutigen — Warnhinweise) und kompensierend (eine Alternative, wenn die Hauptkontrolle nicht machbar ist). Die Defense in Depth schichtet diese, sodass kein einzelner Kontrollausfall zu einer Kompromittierung führt.

Das NIST Cybersecurity Framework ordnet Cybersicherheitsergebnisse in Kernfunktionen. Im CSF 2.0 gibt es sechs: Govern (die neue übergreifende Funktion für Strategie, Rollen, Risikoentscheidungen und Aufsicht), Identify (Werte und Risiken verstehen), Protect (Schutzmaßnahmen zur Begrenzung der Auswirkungen), Detect (Ereignisse aufdecken), Respond (auf Vorfälle reagieren) und Recover (Fähigkeiten wiederherstellen). Sie verlaufen nicht streng sequenziell — sie laufen kontinuierlich und beschreiben zusammen einen vollständigen Lebenszyklus des Managements von Cyberrisiken.

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.

Eine Risikobewertung identifiziert Assets und ihren Wert, die Bedrohungen und Schwachstellen, die sie betreffen könnten, und schätzt das Risiko dann als Funktion von Eintrittswahrscheinlichkeit und Auswirkung. Sie können es qualitativ durchführen (hoch/mittel/niedrig, schnell und subjektiv) oder quantitativ (SLE × ARO = ALE, datengetrieben, aber schwieriger). Rahmenwerke wie NIST RMF und ISO 27005 geben Struktur, und das Ergebnis speist die Risikobehandlung: mindern, übertragen, vermeiden oder akzeptieren.

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.

Threat Modeling beantwortet vier Fragen: Was bauen wir, was kann schiefgehen, was tun wir dagegen und haben wir gute Arbeit geleistet. Sie diagrammieren das System (oft ein Datenflussdiagramm mit Vertrauensgrenzen), zählen Bedrohungen mit einem Framework wie STRIDE auf, priorisieren nach Risiko und weisen Gegenmaßnahmen zu. PASTA fügt eine risiko- und angreiferzentrierte Note hinzu; Angriffsbäume zerlegen ein einzelnes Ziel. Es zur Designzeit zu tun ist weit billiger, als Produktion zu patchen.

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.

Ein guter Bericht bedient zwei Zielgruppen: eine Executive Summary, die das Geschäftsrisiko für die Führung einordnet, und detaillierte, reproduzierbare Funde mit Beweisen, präzisen Risikobewertungen und priorisierter Behebung für das technische Team. Der Bericht — nicht der Exploit — ist das Liefergut.

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.

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.

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.

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.

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.