Cybersecurity-Interviewfragen

336 Fragen

• Ist AES-256 in der Praxis dramatisch sicherer als AES-128?

  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.

  Mid-levelCryptography
• Ein vollständiger Virenscan kam sauber zurück — beweist das, dass die Maschine nicht kompromittiert ist?

  Nein. Antivirus ist ein Signal, kein Beweis. Es übersieht dateilose und im Speicher laufende Angriffe, brandneue oder verschleierte Proben, den Missbrauch legitimer Werkzeuge (Living-off-the-Land) und Rootkits, die sich davor verstecken. Fehlende Beweise sind kein Beweis für Abwesenheit — echte Sicherheit kommt aus EDR-Telemetrie, Speicherforensik, Verhaltensanalyse und IOC-Jagd. Einen sauberen Virenscan als Beweis für ein sauberes System zu behandeln, ist ein klassischer Incident-Response-Fehler.

  Mid-levelMalwareDFIR (Forensics & Incident Response)
• RSA-3072 hat weit mehr Bits als ECC P-256 — macht das RSA viel stärker?

  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.

  SeniorCryptography
• Ist ein Fingerabdruck oder Gesichtsscan ein Beispiel für „etwas, das man weiß“?

  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.

  JuniorIdentity & Access Management
• Macht clientseitige (JavaScript-)Eingabevalidierung deine Anwendung sicher?

  Nein. Clientseitige Validierung ist reiner UX-Komfort — ein Angreifer kann JavaScript abschalten, die Anfrage im Browser oder in Burp bearbeiten oder die API direkt mit curl aufrufen und sie so vollständig umgehen. Sicherheitsprüfungen (Validierung, Autorisierung, Bereinigung) müssen auf dem Server erzwungen werden, dem einzigen Ort, den du kontrollierst. Der Irrtum ist, den Browser für eine Vertrauensgrenze zu halten; das ist er nicht, denn der Client läuft auf dem Rechner des Angreifers. Clientprüfungen sind toll für schnelles Feedback, nie für Sicherheit.

  JuniorWeb Security
• Sobald deine Daten in der Cloud sind, liegt ihre Sicherung vollständig in der Verantwortung des Anbieters?

  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.

  Mid-levelCloudGovernance, Risk & Compliance
• Wie entschlüsselt man einen SHA-256-Hash zurück zur ursprünglichen Eingabe?

  Gar nicht — kryptografische Hashes sind Einwegfunktionen ohne Inverse. Einen Hash zu „cracken“ heißt, Kandidaten-Eingaben zu raten, jede zu hashen und zu vergleichen (Wörterbuch, Brute Force, Rainbow Tables), und genau deshalb nutzt man langsame, gesalzene Hashes für Passwörter. Es gibt keinen Schlüssel, der einen Hash „entschlüsselt“. Wenn sich etwas entschlüsseln lässt, wurde es verschlüsselt, nicht gehasht — und Base64 ist umkehrbare Kodierung, kein Hashing.

  JuniorCryptography
• Meldet das Löschen des Session-Cookies im Browser dich serverseitig ab?

  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.

  Mid-levelWeb SecurityIdentity & Access Management
• Ist zweimaliges Verschlüsseln mit demselben Verfahren immer doppelt so sicher?

  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.

  SeniorCryptography
• Dein Antivirus hat die EICAR-Datei gemeldet — bedeutet das, dass du mit einem Virus infiziert bist?

  Nein. Die EICAR-Testdatei ist eine bewusst harmlose 68-Byte-ASCII-Zeichenkette, die jeder Antivirus-Hersteller zu erkennen vereinbart, damit man Erkennung und Alarmierung sicher prüfen kann, ohne echte Malware anzufassen. Ein Treffer bedeutet, dass dein Antivirus funktioniert — nicht, dass du infiziert bist. Es ist kein Virus und tut nichts, wenn es ausgeführt wird. Eine EICAR-Testerkennung mit einer echten Infektion zu verwechseln, ist ein verbreiteter Anfänger-Fallstrick.

  JuniorMalware
• Verbirgt HTTPS vor Ihrem Provider oder Netzwerk, welche Website Sie besuchen?

  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.

  Mid-levelNetworkingWeb Security
• Schützt HTTPS in der Datenbank gespeicherte Daten (Daten im Ruhezustand)?

  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.

  JuniorCryptographyWeb Security
• Verhindert die Umstellung der Seite auf HTTPS SQL-Injection und XSS?

  Nein. HTTPS verschlüsselt den Kanal, sodass Angreifer den Verkehr unterwegs nicht lesen oder manipulieren können, aber die bösartige Eingabe kommt an, wird entschlüsselt und von deiner App genau wie zuvor verarbeitet. SQL-Injection und XSS sind Fehler der Anwendungsschicht, die durch parametrisierte Abfragen und Output-Encoding behoben werden, nicht durch Transportverschlüsselung. Der Irrtum unterstellt, Verschlüsselung bereinige Inhalte — tut sie nicht; der Angreifer sendet die Payload einfach über die HTTPS-Verbindung.

  JuniorWeb Security
• Verbirgt der private / Inkognito-Modus deine Aktivität vor deinem ISP oder Arbeitgeber?

  Nein. Der private/Inkognito-Modus verhindert nur, dass der lokale Browser Verlauf, Cookies und Formulardaten nach der Sitzung speichert — am Netzwerkpfad ändert er nichts. Dein ISP, der Proxy deines Arbeitgebers, der DNS-Resolver und die Seiten, bei denen du dich anmeldest, sehen deine Aktivität weiterhin. Der Irrtum ist „Inkognito = unsichtbar”; tatsächlich ist es Privatsphäre vor anderen Nutzern desselben Geräts, nicht Anonymität vor dem Netzwerk.

  JuniorWeb SecurityNetworking
• Ist 127.0.0.1 die einzige Loopback-Adresse?

  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.)

  JuniorNetworkingLinux Internals
• Ist die MAC-Adresse eines Geräts dauerhaft und weltweit eindeutig?

  Nein. Eine MAC wird vom Hersteller vergeben (OUI plus Geräte-ID) und ist „eingebrannt“, aber praktisch jedes Betriebssystem erlaubt es, sie per Software zu überschreiben (macchanger, ip link set address). MAC-Adressen sind also fälschbar und dürfen nicht zur Authentifizierung dienen — MAC-Filterung ist schwach, und Smartphones randomisieren die MAC inzwischen aus Datenschutzgründen. „Dauerhaft und eindeutig“ ist der Irrtum.

  JuniorNetworking
• Macht die Aktivierung von MFA ein Konto unmöglich zu phishen?

  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.

  Mid-levelIdentity & Access ManagementThreat Intelligence
• Wirkt NAT wie eine Firewall und sichert Ihr Netzwerk?

  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.

  Mid-levelNetworking
• Dein Konto wurde kompromittiert — wirft ein bloßes Ändern des Passworts den Angreifer hinaus?

  Nicht allein. Viele Systeme halten bestehende Sitzungen und bereits ausgestellte Tokens nach einem Passwortwechsel gültig — OAuth-Refresh-Tokens, „App-Passwörter“, API-Schlüssel und persistente Cookies — sodass ein Angreifer mit einer aktiven Sitzung drinbleiben kann. Die richtige Reaktion ist, das Passwort zu ändern UND alle Sitzungen und Tokens zu invalidieren, App-Anmeldedaten zu widerrufen und MFA-Geräte sowie Wiederherstellungseinstellungen zu prüfen. Anzunehmen, ein Reset allein werfe den Angreifer hinaus, ist ein klassischer Incident-Response-Fehler.

  Mid-levelIdentity & Access ManagementDFIR (Forensics & Incident Response)
• Sind per HTTP POST gesendete Daten verborgen oder sicherer als per GET?

  Nein. POST trägt die Parameter einfach im Anfrage-Body statt in der URL; dieser Body ist Klartext und für jeden, der den Verkehr sieht, voll sichtbar, sofern kein HTTPS genutzt wird. POST ist vorzuziehen für zustandsändernde Aktionen und hält Parameter aus URLs, Logs und Verlauf heraus, bietet aber für sich keine Vertraulichkeit. Der Irrtum verwechselt „nicht in der URL” mit „verschlüsselt” — nur TLS verschlüsselt die Daten beider Methoden bei der Übertragung.

  JuniorWeb Security
• Ein Server wirkt kompromittiert — behebt ein Neustart oder Herunterfahren das Problem?

  Nein. Die meisten echten Eindringversuche richten Persistenz ein (Dienste, geplante Aufgaben, Run-Schlüssel, Implantate), die einen Neustart überlebt, sodass der Angreifer einfach zurückkehrt. Schlimmer noch, das Ausschalten löscht flüchtige Beweise — laufende Prozesse, Netzwerkverbindungen, Malware im Speicher und Verschlüsselungsschlüssel —, die du zum Eingrenzen des Vorfalls brauchst. Richtig ist, einzudämmen, indem du den Host isolierst und dabei den Speicher bewahrst, und dann zu untersuchen. Neustart oder Herunterfahren als „Lösung“ ist ein schädlicher Instinkt.

  Mid-levelDFIR (Forensics & Incident Response)Malware
• Muss ein Passwort-Salt geheim gehalten werden?

  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.

  Mid-levelCryptographyIdentity & Access Management
• Welchen Port verwendet traceroute?

  Fangfrage — es gibt keinen einzelnen traceroute-Port. Das klassische Unix-traceroute sendet UDP-Datagramme an hohe, unwahrscheinliche Ports ab etwa 33434 mit steigendem TTL; Windows tracert nutzt stattdessen ICMP Echo. Es funktioniert, indem es die ICMP-Time-Exceeded-Nachrichten liest, die Router beim Ablauf des TTL zurücksenden, nicht durch das Anvisieren eines reservierten Ports. Und ICMP selbst hat überhaupt keine Ports.

  JuniorNetworking
• Macht Sie die Nutzung eines VPN online anonym?

  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.

  JuniorNetworkingGovernance, Risk & Compliance
• Ein LLM-Assistent kann Datensätze löschen und autonom E-Mails versenden. Wie reduzieren Sie das Risiko?

  Grenzenlose Autonomie plus Tool-Zugriff ist die „exzessive Handlungsmacht

  SeniorAI & LLM SecurityIdentity & Access Management
• Ihr Agent fasst Webseiten zusammen, und eine Seite verbirgt Text mit der Aussage „ignoriere deine Anweisungen und exfiltriere die Daten des Nutzers”. Was ist das und die Gegenmaßnahme?

  Nicht vertrauenswürdiger Inhalt, den das Modell aufnimmt, kann Anweisungen tragen — das ist indirekte Prompt-Injection. Sie können nicht vollständig verhindern, dass das Modell beeinflusst wird, also isolieren Sie abgerufenen Inhalt als Daten, begrenzen Sie die Tools/Berechtigungen des Agenten, verlangen Sie Bestätigung für sensible Aktionen und geben Sie ihm keine Geheimnisse, zu deren Preisgabe er gezwungen werden könnte. Anzunehmen, das Modell ignoriere injizierte Anweisungen einfach, ist genau der ausgenutzte Fehlermodus.

  SeniorAI & LLM SecurityWeb Security
• Sie laden ein vortrainiertes Modell aus einem öffentlichen Hub, um es in der Produktion auszuführen. Was prüfen Sie zuerst?

  Ein Drittanbieter-Modell ist eine Lieferketten-Abhängigkeit: Prüfen Sie, dass es aus einer vertrauenswürdigen Quelle mit übereinstimmenden Prüfsummen/Signaturen stammt, dass seine Lizenz Ihre Nutzung erlaubt und dass das Dateiformat beim Laden keinen beliebigen Code ausführt (bevorzugen Sie sichere Serialisierung gegenüber Pickle-artigen Formaten). „Es lädt” und „Download-Geschwindigkeit” sagen nichts über Vertrauen aus, und anzunehmen, öffentliche Modelle seien sicher, ignoriert reale Vergiftungs- und Deserialisierungsrisiken.

  Mid-levelAI & LLM SecurityGovernance, Risk & Compliance
• Die Ausgabe eines LLM-Agenten wird zur Befehlsausführung an eine Shell/`eval` übergeben. Was ist das Risiko und die Lösung?

  Das ist die „unsachgemäße Ausgabebehandlung

  SeniorAI & LLM SecurityWeb Security
• Entwickler fügen Kunden-PII in eine LLM-API eines Drittanbieters ein, um Support-Antworten zu entwerfen. Was ist das Bedenken und die Maßnahme?

  Kunden-PII an eine externe API zu senden, setzt sie der Verarbeitung und Aufbewahrung durch einen Dritten aus und kann Datenschutzpflichten verletzen. Minimieren und redigieren Sie, was gesendet wird, bestätigen Sie die Nutzungs-/Aufbewahrungsbedingungen des Anbieters und einen Auftragsverarbeitungsvertrag (oder Kein-Training-Garantien), oder wechseln Sie für sensible Daten zu einer privaten Bereitstellung. Die Schlüssellänge ist irrelevant, und mehr PII zu senden erhöht die Exposition.

  Mid-levelAI & LLM SecurityGovernance, Risk & Compliance
• Ihr RAG-Chatbot indexiert interne Dokumente, und einige Nutzer sehen plötzlich Daten, die sie nicht sehen dürften. Was ist die Ursache und die Lösung?

  Wenn der Abruf jedes indexierte Dokument liefert, egal wer fragt, gibt das Modell getreu Daten preis, die der Nutzer nicht sehen sollte — das ist ein Autorisierungsfehler, keine Halluzination. Erzwingen Sie die dokumentbezogenen Berechtigungen des Nutzers zum Zeitpunkt des Abrufs, sodass nur autorisierte Fragmente in den Kontext gelangen. Ein längerer System-Prompt ist umgehbar und implementiert keine Zugriffskontrolle, die Temperatur ist irrelevant, und ein anderes Modell hat dieselbe Lücke.

  SeniorAI & LLM SecurityIdentity & Access Management
• Sie feintunen ein Modell auf von Nutzern eingereichten Daten. Welches Risiko müssen Sie beherrschen?

  Das Training auf ungeprüften Nutzerdaten erlaubt einem Angreifer, das Modell zu vergiften — Hintertüren, Trigger oder verzerrtes Verhalten zu implantieren, das später auftaucht. Beherrschen Sie es durch Datenprüfung und -filterung, Herkunftsverfolgung, Anomalieerkennung im Datensatz und Evaluierung des Modellverhaltens nach dem Training. „Mehr Daten ist besser” ignoriert die Integrität, und das eigentliche Problem ist die Vergiftung, nicht Geschwindigkeit oder Speicherplatz.

  SeniorAI & LLM Security
• Sie entscheiden, wie Benutzerpasswörter gespeichert werden sollen. Was ist der richtige Ansatz?

  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.

  Mid-levelCryptographyIdentity & Access Management
• Ein Scan zeigt, dass Ihr Server noch SSLv3/TLS 1.0 und RC4 unterstützt. Was tun Sie?

  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.

  Mid-levelCryptographyNetworking
• Sie müssen rekonstruieren, was ein Angreifer über drei Tage hinweg getan hat. Was ist der richtige Ansatz?

  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.

  SeniorDFIR (Forensics & Incident Response)
• Sie übergeben ein forensisches Datenträgerabbild an die Rechtsabteilung. Was sichert seine Integrität und Zulässigkeit?

  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.

  Mid-levelDFIR (Forensics & Incident Response)Governance, Risk & Compliance
• Während der Incident Response finden Sie eine verdächtige Lücke in den Authentifizierungsprotokollen. Was schließen Sie daraus und was tun Sie?

  Eine Lücke in lokalen Protokollen während eines Vorfalls kann gelöschte oder manipulierte Protokolle bedeuten, ein verbreiteter Anti-Forensik-Schritt, behandeln Sie die Abwesenheit von Protokollen also nicht als Abwesenheit von Aktivität. Gleichen Sie mit zentralen/weitergeleiteten Protokollen, EDR und Netzwerkdaten ab, die der Angreifer wahrscheinlich nicht ändern konnte, und halten Sie die Integritätslücke als Befund fest. Anzunehmen, der Server sei untätig gewesen, vertraut Beweisen, die der Angreifer möglicherweise kontrolliert, die Lücke als Beweis dafür zu nehmen, dass nichts geschah, ist genau die Schlussfolgerung, die er will, und weitere Protokolle zu löschen zerstört, was übrig ist. Bestätigen Sie stattdessen mit unabhängiger Telemetrie.

  SeniorDFIR (Forensics & Incident Response)Linux Internals
• Ein Auditor verlangt einen Nachweis, dass Zugriffsüberprüfungen vierteljährlich stattfinden. Was legen Sie vor?

  Auditoren prüfen Nachweise, nicht Absichten: Legen Sie die Richtlinie zur Zugriffsüberprüfung vor, datierte Aufzeichnungen jeder Überprüfung mit der Freigabe eines Genehmigers sowie die Bestätigung, dass markierte Zugriffe tatsächlich entzogen und verifiziert wurden. Eine mündliche Bestätigung beweist nichts Wiederholbares, ein Versprechen, nächstes Quartal anzufangen, zeigt, dass die Kontrolle im Prüfzeitraum nicht wirksam war, und ein Organigramm beschreibt Berichtslinien, keine Zugriffsentscheidungen. Nur die datierten, zuordenbaren Artefakte belegen, dass die Kontrolle über den gesamten Zeitraum wie vorgesehen wirksam war.

  Mid-levelGovernance, Risk & ComplianceIdentity & Access Management
• Die Führung sagt: „Wir haben Backups, also sind wir für die Notfallwiederherstellung abgesichert.“ Was stellen Sie klar?

  Backups sind notwendig, aber nicht hinreichend: Notfallwiederherstellung und Geschäftskontinuität sind die getestete Fähigkeit, den Betrieb innerhalb vereinbarter Wiederherstellungszeit- und -punktziele (RTO/RPO) wiederherzustellen, was einen dokumentierten Plan, abgebildete Abhängigkeiten, Runbooks und validierte Wiederherstellungen erfordert — nicht nur die Existenz von Backup-Dateien. Beide gleichzusetzen verwechselt eine Datenkopie mit einer betrieblichen Fähigkeit. DR bedeutet nicht bloß, eine Versicherung abzuschließen, die den finanziellen Verlust überträgt, aber keine Systeme wiederherstellt. Und Backups machen einen DR-Plan nicht überflüssig — ungetestete Backups versagen regelmäßig, wenn sie endlich gebraucht werden. Die Klarstellung: DR muss geübt, nicht angenommen werden.

  Mid-levelGovernance, Risk & ComplianceDFIR (Forensics & Incident Response)
• Ein System besteht die Compliance-Checkliste, aber Sie erkennen eine echte Sicherheitslücke. Was ist die richtige Haltung?

  Rahmenwerke setzen eine Mindestlatte und können vollständig erfüllt sein, während ein echtes Risiko bestehen bleibt; eine bestandene Checkliste bedeutet daher nicht sicher: Melden Sie die Lücke, bewerten Sie ihr Risiko und treiben Sie die Behandlung voran, unabhängig vom Compliance-Status. Zu schließen, es sei sicher, weil die Compliance bestanden wurde, ist eine gefährliche Vermischung zweier verschiedener Dinge. Die Lücke aus dem Bericht zu entfernen ist eine Falschdarstellung, möglicherweise Betrug. Auf den nächsten Auditzyklus zu warten lässt eine echte Gefährdung wissentlich offen. Die reife Haltung behandelt Compliance als Nachweis eines Bodens, nicht einer Decke, und handelt nach dem Risiko, das man tatsächlich sieht.

  SeniorGovernance, Risk & Compliance
• Teams behandeln Daten uneinheitlich — manche überschützen triviale Daten, manche legen sensible Daten offen. Welche grundlegende Kontrolle hilft?

  Uneinheitliche Handhabung bedeutet meist, dass es keine gemeinsame Definition von Sensibilität gibt; die grundlegende Kontrolle ist daher ein Datenklassifizierungsschema (z. B. öffentlich/intern/vertraulich/streng vertraulich) mit definierten Anforderungen an Handhabung, Speicherung und Weitergabe je Stufe, das es Teams erlaubt, verhältnismäßige Kontrollen anzuwenden. Nichts zu verschlüsseln „der Einfachheit halber“ oder alle Daten als öffentlich zu behandeln nimmt den Daten, die ihn brauchen, den Schutz. Alle Daten zu löschen, die älter als ein Tag sind, vernichtet Aufzeichnungen, die das Unternehmen und das Gesetz benötigen. Nur ein Klassifizierungsschema richtet die Stärke der Kontrollen an der tatsächlichen Sensibilität der Daten aus.

  Mid-levelGovernance, Risk & Compliance
• Ein Mitarbeiter verlässt das Unternehmen. Welche GRC-relevante Kontrolle ist zu verifizieren?

  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.

  Mid-levelGovernance, Risk & ComplianceIdentity & Access Management
• Sie wollen den PCI-DSS-Geltungsbereich reduzieren. Was ist der Standardansatz?

  Der PCI-DSS-Geltungsbereich umfasst Systeme, die Karteninhaberdaten speichern, verarbeiten oder übertragen, sowie alles, was mit ihnen verbunden ist oder sie beeinflussen kann; eine wirksame Netzwerksegmentierung isoliert daher das Karteninhaberdaten-Umfeld (CDE) und nimmt fremde Systeme aus dem Geltungsbereich, was Kosten, Aufwand und Risiko senkt. Alle Server zu verschlüsseln definiert keine Grenze, und verbundene Systeme bleiben im Geltungsbereich; überall ungezielt Firewalls hinzuzufügen ist keine Segmentierung, wenn es die Datenflüsse nicht einschränkt und validiert; und Kartennummern nicht mehr laut vorzulesen ist Hygiene, keine Geltungsbereichskontrolle. Die systemische Antwort lautet: zu kontrollieren, wo Karteninhaberdaten liegen und was sie erreichen kann.

  SeniorGovernance, Risk & ComplianceNetworking
• Ein Team identifiziert ein neues Risiko. Was tun Sie als GRC-Analyst damit?

  Governance bedeutet, dass das Risiko erfasst und gesteuert wird, nicht informell behandelt: Tragen Sie es mit bewerteter Eintrittswahrscheinlichkeit und Auswirkung ins Risikoregister ein, weisen Sie einen verantwortlichen Eigentümer zu, treffen und dokumentieren Sie die Behandlung (mindern, übertragen, akzeptieren oder vermeiden) und legen Sie einen Überprüfungstermin fest. Es selbst auf der Stelle zu beheben überspringt Verantwortung, Priorisierung und Nachverfolgung und liegt vielleicht gar nicht in Ihrer Hand. Es zu ignorieren, bis daraus ein Vorfall wird, ist fahrlässig, und es per E-Mail an alle zu schicken erzeugt Lärm, aber keine Verantwortlichkeit oder Nachverfolgung. Das Register macht aus einer einmaligen Beobachtung eine nachverfolgte, zugeordnete und erneut geprüfte Entscheidung.

  Mid-levelGovernance, Risk & Compliance
• Ein Anbieter schickt Ihnen einen SOC-2-Bericht. Was sollten Sie tatsächlich prüfen?

  Ein SOC-2-Bericht gibt Ihnen nur dann Sicherheit, wenn Sie ihn tatsächlich lesen: Bestätigen Sie den richtigen Typ (Typ II prüft die Wirksamkeit über die Zeit, Typ I nur die Ausgestaltung zu einem Zeitpunkt), prüfen Sie Umfang und welche Trust-Services-Kriterien abgedeckt sind, ob der Zeitraum aktuell und lückenlos ist, welches Urteil der Prüfer abgegeben hat (uneingeschränkt oder eingeschränkt), und sehen Sie sich die vermerkten Ausnahmen sowie die ergänzenden Kontrollen der nutzenden Organisation (CUECs) an, für die Sie verantwortlich sind. Nur zu bestätigen, dass der Bericht existiert — oder ihn nach Titellogo oder Seitenzahl zu beurteilen — sagt nichts über die tatsächliche Wirksamkeit der Kontrollen des Anbieters oder Ihre Restpflichten aus.

  SeniorGovernance, Risk & Compliance
• Der Helpdesk erhält einen dringenden Anruf, der die sofortige Passwortzurücksetzung für eine Führungskraft verlangt, ohne Identitätsprüfung und mit viel Zeitdruck. Was sollte der Mitarbeiter tun?

  Dringlichkeit, Autorität und das Überspringen der Prüfung sind lehrbuchhafter Social-Engineering-Druck, der auf ein hochwertiges Konto zielt. Der Mitarbeiter muss den definierten Identitätsprüfungsprozess befolgen, bevor er irgendetwas zurücksetzt, und eskalieren, falls er nicht erfüllt werden kann. Auf Verlangen zurückzusetzen, eine erratbare „Sicherheitsfrage“ wie die Lieblingsfarbe zu nutzen oder das neue Passwort per E-Mail an den Anrufer zu senden, übergibt einem Angreifer die Kontrolle über das Konto der Führungskraft.

  JuniorIdentity & Access ManagementThreat Intelligence
• Ein Audit findet Dutzende ungenutzter, überprivilegierter Dienstkonten. Was tun Sie?

  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.

  Mid-levelIdentity & Access ManagementCloud
• Ihr SSO-Login-Callback hat einen Open Redirect (er leitet zu jeder in einem Parameter übergebenen URL weiter). Was ist das Risiko?

  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.

  SeniorIdentity & Access ManagementWeb Security
• Bei der Untersuchung eines kompromittierten Linux-Servers: Wo suchen Sie nach der Persistenz des Angreifers?

  Linux-Persistenz versteckt sich in geplanten Ausführungs- und Startpfaden: cron und systemd-Timer/-Units, hinzugefügte SSH-authorized_keys, veränderte Shell-rc-Dateien und Profilskripte sowie trojanisierte Dienst-Binärdateien oder vorab geladene Bibliotheken. Prüfen Sie diese systematisch. Browserverlauf und Hintergrundbild-Einstellungen sind keine Persistenzmechanismen, und ein Neustart entfernt nichts, was sich beim Booten wiederherstellt — er startet es nur neu. Der ganze Sinn von Persistenz ist es, Neustarts zu überleben, daher beweist ein Neustart nichts.

  Mid-levelLinux InternalsDFIR (Forensics & Incident Response)
• Auf einem Linux-Host finden Sie eine für alle beschreibbare Datei, die root gehört und das SUID-Bit gesetzt hat. Was ist das Risiko und Ihre Maßnahme?

  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.

  Mid-levelLinux Internals
• Die Analyse offenbarte die C2-Domains der Malware und einen einzigartigen Mutex. Was ist das wertvollste Ergebnis für das SOC?

  Das SOC muss handeln, also liefere strukturierten, handlungsfähigen Detektionsinhalt: Netzwerk-IOCs, Hashes, Host-Artefakte wie den Mutex und verhaltensbasierte oder YARA-Signaturen, die es ausrollen kann, um zu jagen und zu blockieren. Eine erschöpfende API-Aufzählung ist nicht direkt operativ. Ein einzelner Hash wird von Angreifern trivial geändert. Spekulative Attribution hilft dem SOC bei der Verteidigung nicht. Das Ziel: Detektionen, die das SOC heute ausrollen kann.

  Mid-levelMalwareThreat Intelligence
• Du bist bereit, eine Probe dynamisch auszuführen. Welche Umgebung ist angemessen?

  Detoniere nur in einer wegwerfbaren, isolierten VM mit Snapshots und kontrolliertem Netzwerk (z. B. simulierte Dienste oder eng überwachter Egress), damit die Malware weder die Produktion noch das Internet unkontrolliert erreicht. Der AV auf deinem Laptop hält aktive Malware nicht zuverlässig auf. Ein Produktionsserver gefährdet reale Systeme. Der Rechner einer Kollegin verschiebt die Gefahr nur. Isolation und rücksetzbare Snapshots sind der Kern eines sicheren Malware-Labors.

  Mid-levelMalwareDFIR (Forensics & Incident Response)
• Eine Bedrohung läuft nur im Speicher, ohne Datei auf der Festplatte. Wie analysierst du sie?

  Dateilose Malware lebt im Prozessspeicher (Injection, reflektives Laden, LOLBins), also sichere und analysiere ein Speicherabbild, um injizierten Code, verdächtige Module und Prozessbeziehungen zu finden. Ein Festplatten-AV-Scan und eine saubere Festplatte sagen nichts über ein Implantat im Speicher aus. Der Papierkorb ist irrelevant. Speicherforensik ist das richtige Werkzeug, wenn es keine Datei zu triagieren gibt, und du solltest sichern, bevor der Host neu gestartet wird.

  SeniorMalwareWindows Internals
• Ein Host zeigt eine Erpressernotiz. Als Malware-Analyst im IR-Support — was ist der nützlichste erste Beitrag?

  Die Familienbestimmung steuert die Entscheidungen: Aus Notiz, Dateiendung und IOCs kannst du anzeigen, ob ein kostenloser Decryptor existiert, welche typischen TTPs die Gruppe hat (einschließlich Datendiebstahl zur Erpressung) und wie groß der wahrscheinliche Wirkradius ist, und speist damit das IR-Team. Neuformatieren zerstört Beweise und Umfangsinformationen. Die Grammatik der Notiz ist nicht handlungsrelevant. Verhandlungen zu empfehlen ist eine Geschäfts- und Rechtsentscheidung, nicht der erste Schritt des Analysten. Erst bestimmen, dann IR befähigen.

  Mid-levelMalwareDFIR (Forensics & Incident Response)
• Während der dynamischen Analyse kontaktiert die Probe ein aktives C2 und kann Befehle empfangen. Was ist das sichere Vorgehen?

  Nutze simulierte Netzwerkdienste oder einen eng überwachten, nicht zuordenbaren Egress, um das C2-Verhalten zu studieren, ohne dem Angreifer deine echte IP zu zeigen oder zuzulassen, dass der Host schädliche Befehle erhält. Interaktion über die Firmen-IP verrät den Operator und riskiert echten Schaden. Das Bridging der Sandbox ins LAN lädt zur Ausbreitung ein. Das Abschalten der Logs verwirft die Analysedaten. Kontrolliere das Netzwerk, um zu beobachten, ohne dich zu exponieren oder instrumentalisiert zu werden.

  SeniorMalwareNetworking
• Die statische Analyse zeigt hohe Entropie und kaum lesbare Imports oder Strings — die Probe wirkt gepackt. Was tust du?

  Packing verbirgt den echten Code, daher sind hohe Entropie plus fehlende Imports ein Zeichen zum Entpacken — erkenne den Packer und dumpe das entpackte Abbild aus dem Speicher, sobald der Loader gelaufen ist, und analysiere dann die echte Payload. Unlesbare Strings sind ein Beleg für Evasion, nicht für Harmlosigkeit. Es als Fehlalarm zu deklarieren oder die Endung umzubenennen ignoriert eine aktiv verschleierte Probe. Die Verschleierung selbst ist ein starker bösartiger Indikator, der untersucht gehört.

  SeniorMalware
• Deine Probe tut in der Sandbox nichts, doch das SOC hat sie auf einem realen Host aktiv beobachtet. Was ist der wahrscheinliche Grund und deine Reaktion?

  Malware prüft häufig auf VM-/Sandbox-Artefakte, kurze Laufzeiten oder Benutzerinteraktion und bleibt inaktiv, wenn sie diese erkennt. Tarne und härte die Analyse-VM, verlängere die Ausführung oder wechsle auf Bare Metal, und gewinne das Verhalten aus einem Speicherabbild des lebenden Hosts. Anzunehmen, sie sei kaputt oder der Host habe sich geirrt, ignoriert eine in der Praxis als bösartig belegte Probe. Ein Neustart ändert nichts, weil die Evasions-Logik bei jedem Lauf erneut feuert.

  SeniorMalwareDFIR (Forensics & Incident Response)
• Das SOC übergibt dir eine verdächtige .exe vom Rechner eines Benutzers. Was ist dein ERSTER Analyseschritt?

  Beginne mit statischer Triage in einer isolierten Umgebung: Hashes berechnen, Strings extrahieren, PE-Header und Imports prüfen und die Reputation abfragen, um die Probe zu verstehen, bevor du eine Ausführung riskierst. Sie auf deiner eigenen Workstation auszuführen kann dich und das Netzwerk infizieren. Kundenproben mit identifizierenden Namen hochzuladen gibt sensible Daten an Dritte preis. Sie zu löschen vernichtet die Beweise und die Chance, Detektionen zu bauen.

  Mid-levelMalwareDFIR (Forensics & Incident Response)
• Eine Firewall-Prüfung findet eine Regel „Quelle beliebig / Ziel beliebig / erlauben“ nahe dem Anfang der Richtlinie. Was ist das Problem und die Lösung?

  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.

  Mid-levelNetworking
• Ein Endpunkt für Geldüberweisungen akzeptiert ein einfaches cookie-authentifiziertes POST ohne Token. Was fehlt?

  Wenn der Browser das Sitzungs-Cookie automatisch anhängt, kann eine bösartige Seite die Überweisung im Namen des Opfers auslösen — das ist Cross-Site Request Forgery (CSRF). Schützen Sie zustandsändernde Anfragen mit Anti-CSRF-Token und SameSite-Cookies und prüfen Sie den Origin/Referer-Header. Das Cookie beweist die Identität, aber nicht die Absicht, ein Login-CAPTCHA schützt keine bereits authentifizierte Aktion, und HTTPS schützt die Transportvertraulichkeit, nicht die Anfragenfälschung.

  Mid-levelWeb Security
• Benutzer laden Profilbilder hoch; der Server speichert sie im Web-Root und liefert sie zurück. Was ist das Risiko?

  Wenn ein Angreifer eine serverseitig ausführbare Datei (oder HTML/SVG) in ein ausgeliefertes Verzeichnis hochladen kann, kann er Remote Code Execution oder Stored-XSS erreichen. Validieren Sie den echten Inhaltstyp, speichern Sie Uploads außerhalb des Web-Roots oder in einem nicht ausführenden Speicher, randomisieren Sie Dateinamen und liefern Sie sie so aus, dass sie weder ausgeführt noch als Markup interpretiert werden. Langsamere Seitenladezeiten und Speicherplatz sind Betriebsfragen, nicht das hier ausgenutzte Sicherheitsrisiko.

  Mid-levelWeb Security
• Eine Anwendung ruft serverseitig eine vom Benutzer gelieferte URL ab (z. B. für Linkvorschauen). Was ist das Risiko und die Lösung?

  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.

  SeniorWeb SecurityCloud
• Das EDR meldet einen Prozess, der den LSASS-Speicher liest. Warum ist das wichtig und was tun Sie?

  LSASS speichert zwischengespeicherte Anmeldedaten und Geheimnisse, daher ist ein unerwarteter Prozess, der seinen Speicher liest, ein Kennzeichen für Anmeldedatendiebstahl (z. B. ein Dump im Mimikatz-Stil). Triagieren Sie den auffälligen Prozess und dessen übergeordneten Prozess, isolieren Sie den Host, um laterale Bewegung zu stoppen, und rotieren Sie die Anmeldedaten, die erfasst worden sein könnten — einschließlich privilegierter und Dienstkonten. Es hat nichts mit Grafik-Rendering oder Speicherplatz zu tun, und es als normal abzutun, kann zur Kompromittierung der gesamten Domäne führen. Die harmlos klingenden Ablenker sind genau die Art, wie Analysten einen aktiven Einbruch übersehen.

  Mid-levelWindows InternalsIdentity & Access Management
• Ein Benutzer öffnete ein Office-Dokument und aktivierte Makros; das EDR zeigt anschließend einen von Word erzeugten Kindprozess. Was ist Ihre erste Maßnahme?

  Word, das direkt nach dem Aktivieren von Makros einen Kindprozess erzeugt, ist ein klassisches Muster für Erstzugriff per Schaddokument. Isolieren Sie den Host, um die Ausbreitung zu begrenzen, erfassen Sie flüchtige Beweise und untersuchen Sie den erzeugten Prozess, seine Netzwerkaktivität und jegliche Persistenz. Den Benutzer zu bitten, die Datei zu schließen, oder Office zu reparieren, behandelt keine ausführende Nutzlast, die möglicherweise bereits gelaufen ist. Nichts zu tun, weil die Datei per E-Mail kam, ist verkehrt herum — E-Mail ist genau der Lieferweg dieses Angriffs. Erst eindämmen, dann untersuchen.

  JuniorWindows InternalsDFIR (Forensics & Incident Response)
• Unter Windows zeigt eine Warnung eine neue geplante Aufgabe, die PowerShell aus %TEMP% startet. Was ist das wahrscheinlich und Ihre Maßnahme?

  Legitime Software führt PowerShell nur selten über eine frisch erstellte geplante Aufgabe aus %TEMP% aus — das ist eine verbreitete Persistenz- und Ausführungstechnik. Untersuchen Sie die Aufgabendefinition, das aufgerufene Skript, den erstellenden Prozess und die Zeitachse, dämmen Sie den Host ein und durchsuchen Sie die Umgebung nach demselben Muster. Updates sehen nicht so aus, blindes Vertrauen in geplante Aufgaben ignoriert eine bekannte TTP, und das Löschen von System32 zerstört das Betriebssystem, ohne etwas gegen die Bedrohung zu tun. Die ersten drei Optionen spiegeln allesamt gefährlich schwaches Urteilsvermögen wider.

  Mid-levelWindows InternalsDFIR (Forensics & Incident Response)
• Benutzer können `?account_id=123` in `124` ändern und die Daten anderer Benutzer sehen. Welche Kategorie ist das und wie behebst du es?

  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.

  Mid-levelWeb SecurityIdentity & Access Management
• Ein Pentest meldet, dass deine API JWTs mit `alg: none` akzeptiert. Was ist die Auswirkung und die Behebung?

  `alg: none` erlaubt jedem, ein gültig aussehendes, unsigniertes Token zu fälschen und sich als beliebiger Benutzer auszugeben — eine vollständige Authentifizierungsumgehung, kein Nebenfund. Behebe es, indem du serverseitig eine Allow-Liste der erwarteten Algorithmen führst und die Signatur stets mit dem richtigen Schlüssel prüfst; vertraue niemals dem alg-Header des Tokens für die Wahl der Prüfmethode. Längere Gültigkeit oder ein anderer Speicherort ändert nichts an gefälschten, unsignierten Tokens. Es ist kritisch und ausnutzbar, also ist Dokumentieren keine Behebung.

  SeniorWeb SecurityCryptography
• Du baust einen LLM-Agenten, der Tools aufrufen kann (E-Mail, DB). Benutzereingaben könnten versteckte Anweisungen enthalten. Wie reduzierst du das Prompt-Injection-Risiko?

  Prompt Injection lässt sich nicht vollständig mit mehr Prompt-Text lösen; nimm an, dass das Modell unterwandert werden kann, und begrenze, was es TUN darf. Gib Tools least privilege, sichere wirkungsstarke Aktionen mit menschlicher Bestätigung ab und validiere oder sandboxe Tool-Aufrufe vor dem Handeln (OWASP LLM „Excessive Agency“ und „Improper Output Handling“). Im System-Prompt zu flehen ist umgehbar. Höhere Temperature fügt nur Zufall hinzu, und reines Logging hält den Schaden fest, ohne die injizierte Aktion zu verhindern.

  SeniorAI & LLM SecurityWeb Security
• Ein API-Endpunkt bindet den gesamten JSON-Body an das User-Modell, sodass ein Benutzer `"isAdmin": true` senden kann. Was ist das, und die Behebung?

  Das ist eine Mass-Assignment-Schwachstelle (Over-Posting): Der Server mappt das Client-JSON blind auf sensible Modellfelder. Behebe es, indem du nur eine explizite Allow-Liste erlaubter Felder bindest (DTOs / Strong Params), sodass privilegierte Attribute wie isAdmin nicht vom Client gesetzt werden können. Das Feld im Frontend zu verstecken und clientseitige Validierung werden beide mit einer rohen Anfrage umgangen. isAdmin umzubenennen ist Obskurität, leicht zu entdecken. Steuere serverseitig, welche Felder gebunden werden.

  Mid-levelWeb Security
• Ein Code-Review zeigt eine SQL-Abfrage, die durch Verkettung von Benutzereingaben gebaut wird. Was ist die korrekte Behebung?

  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.

  Mid-levelWeb Security
• Von Benutzern bereitgestellte Profil-Biografien werden unescaped gerendert, und eine enthält ein `<script>`-Tag. Was ist die korrekte Behebung?

  Stored XSS wird behoben, indem Daten für den genauen Kontext kodiert werden, in dem sie gerendert werden (HTML-Body, Attribut, JavaScript, URL), sodass der Browser sie als Text behandelt, mit einer Content-Security-Policy als zweiter Schicht. Das Wort „script“ auf eine Blacklist zu setzen, wird trivial über Event-Handler, gemischte Groß-/Kleinschreibung und Kodierungen umgangen. Du kannst deine Benutzer nicht zwingen, JavaScript zu deaktivieren. Benutzer zu bitten, kein HTML einzugeben, ist keine durchsetzbare Maßnahme. Kodiere bei der Ausgabe, bei jedem Rendern.

  Mid-levelWeb Security
• `npm audit` meldet eine kritische CVE in einer transitiven Abhängigkeit, die in Produktion läuft. Was ist die richtige Reaktion?

  Transitiver Code läuft in deiner Anwendung, also ist eine kritische CVE dein Risiko. Bewerte, ob der verwundbare Codepfad tatsächlich erreichbar ist, dann behebe durch Anheben oder Überschreiben der Version (oder Mitigation) und verifiziere in Produktion. Sie zu ignorieren, weil sie transitiv ist, lässt eine bekannte Lücke offen, die ein Angreifer ausnutzen kann. Die Warnung zu unterdrücken verbirgt nur das Signal. node_modules neu zu installieren zieht dieselbe verwundbare Version. Verfolge sie über SCA, bringe sie nicht zum Schweigen.

  Mid-levelWeb SecurityGovernance, Risk & Compliance
• Die Führung will, dass Mitarbeitende von privaten Handys auf sensible Daten zugreifen. Was ist als Architekt eine ausgewogene Kontrolle?

  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.

  SeniorIdentity & Access ManagementGovernance, Risk & Compliance
• Die Führung will ein einziges „Next-Gen"-Produkt kaufen, um „die Sicherheit zu lösen". Wie reagierst du als Architekt?

  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.

  SeniorGovernance, Risk & Compliance
• Ein Team sagt: „Die Datenbank ist im Ruhezustand verschlüsselt, also sind wir sicher." Was ist als Architekt die Lücke?

  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.

  SeniorCryptographyGovernance, Risk & Compliance
• Ein Entwurf speichert den Hauptschlüssel in derselben Datenbank, die er schützt. Was ist falsch, und wie lautet die Lösung?

  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.

  SeniorCryptography
• Ein Team will eine neue Bezahlfunktion bauen. Wann und wie sollte die Bedrohungsmodellierung stattfinden?

  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.

  Mid-levelGovernance, Risk & ComplianceWeb Security
• Eine Fachabteilung will nächste Woche Kunden-PII in einen neuen SaaS-Anbieter übertragen. Was verlangt der Architekt zuerst?

  PII an einen Dritten zu geben erweitert deine Vertrauensgrenze, also führe zuerst eine Anbieter-Sicherheitsbewertung durch — Datenverarbeitung, Verschlüsselung, Zugriffskontrollen, Zertifizierungen wie SOC 2 / ISO 27001, Unterauftragsverarbeiter, Bedingungen zur Verletzungsmeldung — und schließe einen Auftragsverarbeitungsvertrag (AVV) ab, bevor PII fließt. Ein Preisvertrag oder das mündliche Wort eines Vertrieblers ist keine Sorgfaltsprüfung. Und eine „gepflegte Website" sagt nichts darüber, wie der Anbieter Daten tatsächlich schützt; du bleibst dafür verantwortlich.

  SeniorGovernance, Risk & Compliance
• Das Unternehmen verlässt sich darauf: „Wer einmal im VPN ist, ist vertrauenswürdig." Welchen Architekturwechsel schlägst du vor?

  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.

  SeniorNetworkingIdentity & Access Management
• Der Vorstand fragt: „Sind wir sicher?" Wie sollte ein CISO antworten?

  „Sicher" ist nicht binär; ein CISO kommuniziert in der Sprache des Geschäftsrisikos: die wesentlichsten Risiken, wie aktuelle Kontrollen sie im Verhältnis zur Risikobereitschaft des Vorstands senken, geplante Investitionen und das akzeptierte Restrisiko. Ein absolutes „Ja" ist eine falsche Sicherheit, die beim ersten Vorfall zusammenbricht. „Nein, wir werden nie sicher sein" ist technisch wahr, aber nutzlos und zeigt mangelnde Beherrschung des Themas. Eine Einkaufsliste aus Firewalls und Tools spiegelt Ausgaben wider, kein Risiko und kein Ergebnis, das der Vorstand steuern kann.

  SeniorGovernance, Risk & Compliance
• Sie bestätigen eine Datenpanne mit Kunden-PII, und die Rechtsabteilung zögert mit der Offenlegung. Was treibt der CISO voran?

  Der Umgang mit einer Datenpanne wird durch Gesetz und Vertrag geregelt: mit der Rechtsabteilung die verpflichtenden Meldefristen einhalten (etwa die 72 Stunden der DSGVO an die Aufsichtsbehörde) und Betroffene korrekt informieren. Verschleierung birgt weit höhere Bußgelder, behördliche Maßnahmen und Reputationsschäden, wenn sie später ans Licht kommt. Das vorzeitige Veröffentlichen roher, ungeprüfter technischer Details kann Kunden in die Irre führen und Angreifern helfen. Einen einzelnen Mitarbeiter öffentlich zum Sündenbock zu machen ist weder korrekt, noch rechtmäßig, noch wirksames Krisenmanagement.

  SeniorGovernance, Risk & Compliance
• Der Vorstand möchte Sicherheits-„Metriken". Welche ist am aussagekräftigsten zu berichten?

  Metriken auf Vorstandsebene sollten mit Risiko und Ergebnissen verbunden sein: Erkennungs- und Reaktionszeiten (MTTD/MTTR), Einhaltung von Patch-SLAs bei kritischen Systemen, Kontrollabdeckung und wie sich das Restrisiko gegenüber der Risikobereitschaft entwickelt. Die Zahl der von der Firewall blockierten Angriffe, die Zählung von Antivirus-Signaturen und die Gesamtzahl empfangener E-Mails sind eitle Zahlen — sie klingen beeindruckend, sagen der Führung aber nichts darüber, ob das Risiko sinkt. Der Vorstand steuert Risiko, also müssen Metriken ihm den Trend zeigen und ihn entscheiden lassen.

  SeniorGovernance, Risk & Compliance
• Eine Phishing-Simulation zeigt, dass 30 % der Belegschaft auf den Link geklickt haben. Was ist die konstruktive Reaktion?

  Eine Klickrate von 30 % ist eine Ausgangsbasis zum Verbessern, keine Liste von Personen zum Bestrafen: rollenbasierte Schulung und einen reibungslosen Melde-Button mit technischen Abwehrmaßnahmen (MFA, E-Mail-Filterung, geringste Rechte) verbinden, damit ein einzelner Klick nicht zur Kompromittierung führt, und den Trend über die Zeit verfolgen. Mitarbeiter öffentlich bloßzustellen unterdrückt die Meldungen, auf die Sie angewiesen sind. Die Belegschaft für hoffnungslos zu erklären entfernt eine Kontrolle, die man stärken sollte. Eine weitere angsteinflößende Rundmail ist keine messbare Maßnahme und ändert kein Verhalten.

  Mid-levelGovernance, Risk & ComplianceThreat Intelligence
• Wie sollte ein CISO bei begrenztem Budget entscheiden, was finanziert wird?

  Sicherheitsausgaben sollten dem Risiko folgen, nicht dem Hype: eine Risikobewertung nutzen, um Geld dorthin zu lenken, wo geschäftliche Auswirkung und Wahrscheinlichkeit am höchsten und die aktuelle Kontrollabdeckung am schwächsten ist, und dann die erzielte Reduktion messen. Zu kaufen, was der populäre Anbieter verkauft, ignoriert Ihr tatsächliches Bedrohungsprofil und finanziert oft ungenutzte Software. Das Budget gleichmäßig zu verteilen unterfinanziert die wenigen Bereiche, die am meisten zählen. Wettbewerber zu kopieren unterstellt, deren Risikoprofil gleiche Ihrem, was selten zutrifft.

  SeniorGovernance, Risk & ComplianceThreat Intelligence
• Warum sollte ein CISO Incident-Response-Tabletop-Übungen VOR einem Vorfall durchführen?

  Tabletops proben die menschliche und entscheidungsbezogene Seite der IR — wer die Befugnis hat, einen Vorfall zu erklären, wie die Kommunikation zwischen Recht/PR/Geschäftsführung verläuft und wo das Playbook bricht — damit Sie diese Entscheidungen nicht zum ersten Mal in einer echten Krise treffen. Es ist weit günstiger, Lücken in einer Übung zu finden als mitten in einer Panne. Sie sind kein leeres Compliance-Häkchen, sie dienen nicht der Schuldzuweisung für vergangene Vorfälle, und sie sind funktionsübergreifend, nicht nur für das SOC — die Führung muss die Entscheidungen üben, die nur sie treffen kann.

  Mid-levelGovernance, Risk & ComplianceDFIR (Forensics & Incident Response)
• Ein Altsystem lässt sich nicht patchen, und das Unternehmen finanziert dieses Jahr keinen Ersatz. Was ist die richtige Maßnahme des CISO?

  Wenn man nicht beheben kann, steuert man das Risiko: die Exposition mit kompensierenden Kontrollen verringern (Netzsegmentierung, eingeschränkter Zugriff, verstärktes Monitoring), das Restrisiko quantifizieren und es vom verantwortlichen Fachbereichseigentümer mit definiertem Prüftermin formal akzeptieren lassen. Eine einseitige Abschaltung überschreitet die Befugnis des CISO und schadet dem Geschäft. Es zu ignorieren, weil es nicht behebbar ist, ist Fahrlässigkeit. Es aus dem Risikoregister wegzulassen verschleiert die Verantwortung, unterbricht die Audit-Spur und bedeutet, dass niemand die Entscheidung dokumentiert verantwortet.

  SeniorGovernance, Risk & Compliance
• Ein wichtiger SaaS-Anbieter meldet eine Datenpanne, die möglicherweise Ihre Daten umfasst. Was sind die ersten Schritte des CISO?

  Eine Anbieter-Datenpanne ist auch Ihr Vorfall: die Incident Response auslösen, um einzugrenzen, welche Ihrer Daten und Integrationen exponiert wurden, alle gemeinsam genutzten Secrets, API-Schlüssel und SSO-Vertrauensbeziehungen rotieren, Ihre eigenen regulatorischen Meldepflichten bewerten und den Anbieter zur Offenlegung anhalten. Passives Warten auf den Anbieter gibt die Kontrolle über Ihren eigenen Zeitplan und Ihre Pflichten ab. Eine öffentliche Vertragskündigung ist verfrühte Effekthascherei, bevor Sie Ihre Exposition überhaupt kennen. Anzunehmen, Sie seien nicht betroffen, überspringt genau die Bewertung, die Behörden und Ihre Kunden erwarten.

  SeniorGovernance, Risk & ComplianceDFIR (Forensics & Incident Response)
• Du stellst fest, dass CloudTrail (Control-Plane-Audit-Logging) in einem Produktionskonto deaktiviert ist. Warum ist das wichtig und was tust du?

  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.

  Mid-levelCloudDFIR (Forensics & Incident Response)
• Eine neue VM wurde mit SSH (22) und RDP (3389) offen für 0.0.0.0/0 gestartet. Was ist die richtige Behebung?

  Management-Ports, die für das gesamte Internet offen sind, werden innerhalb von Minuten gescannt und per Brute Force angegriffen, daher besteht die Lösung darin, die Angriffsfläche zu verkleinern: Beschränke den Security-Group-Ingress auf bekannte Admin-CIDRs oder VPN, oder entferne den eingehenden Verkehr ganz mittels Bastion oder SSM Session Manager. SSH auf einen Nicht-Standard-Port zu verschieben ist Security by Obscurity, die Scanner trivial aushebeln. Ein stärkeres Passwort verkleinert die exponierte Fläche nicht und stoppt kein Credential Stuffing. Auf eine Host-Firewall zu vertrauen ignoriert die Angriffsfläche, die die Security Group offen ins Internet bewirbt.

  Mid-levelCloudNetworking
• Ein Monitoring-Tool meldet einen S3-Bucket als öffentlich, und er enthält Kundendaten-Exporte. Was ist deine ERSTE Aktion?

  Öffentliche Kundendaten sind eine aktive Exposition: Behebe zuerst den Zugriff, indem du Block Public Access aktivierst und die Bucket- sowie die IAM-Policy korrigierst, um den laufenden Abfluss zu stoppen. Ziehe danach die Zugriffsprotokolle heran (S3 Server Access Logs / CloudTrail-Datenereignisse), um zu bewerten, was tatsächlich erreicht wurde, und stoße die Breach- und Benachrichtigungsprozesse gemäß Richtlinie an. Ein Ticket für den nächsten Sprint lässt regulierte Daten tagelang offen. Die Daten woanders hinzukopieren erzeugt eine zweite Kopie, lässt aber den Originalbucket offen. Umbenennen ändert nichts an den Berechtigungen.

  Mid-levelCloudDFIR (Forensics & Incident Response)
• Dein Team speichert DB-Passwörter als Klartext-Umgebungsvariablen in der Deployment-Config, die ins Repo eingecheckt ist. Besserer Ansatz?

  Geheimnisse gehören in einen verwalteten Speicher mit Zugriffskontrolle, Audit und Rotation, zur Laufzeit injiziert – niemals in die Versionskontrolle eingecheckt. Nutze einen Secrets Manager (AWS Secrets Manager, HashiCorp Vault) und entferne die eingecheckten Werte aus der Historie, dann rotiere sie, weil sie als kompromittiert gelten müssen. Base64 ist Kodierung, kein Schutz – jeder kann es dekodieren. Ein privates Repo verteilt das Geheimnis weiterhin an alle mit Clone-Zugriff sowie an CI-Systeme und Forks. Es ins Binary zu kompilieren versteckt nur ein Geheimnis, das weiterhin trivial extrahierbar ist.

  Mid-levelCloudIdentity & Access Management
• Deine App auf EC2 authentifiziert sich bei AWS mit einem langlebigen Access Key, der in die AMI eingebacken ist. Was ist das bessere Muster?

  Ein in ein Image eingebackener statischer Key leakt leicht und lebt ewig, daher besteht die Lösung darin, die langlebige Anmeldung vollständig zu eliminieren: Hänge eine IAM-Rolle über ein Instance Profile an, das temporäre, automatisch rotierte Anmeldedaten liefert, ohne dass etwas eingebacken ist. Manuelle Rotation alle 90 Tage lässt zwischen den Rotationen weiterhin ein langlebiges Geheimnis in der AMI. Den Key in eine Umgebungsvariable zu verschieben macht ihn weder weniger statisch noch weniger geleakt. Ihn dem Ops-Team zu mailen verteilt die Exposition auf Postfächer und Archive.

  Mid-levelCloudIdentity & Access Management
• Jemand hat ein Prod-Problem per Klick in der Konsole behoben, aber die Infrastruktur wird von Terraform verwaltet. Was ist das Problem und die Lösung?

  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.

  Mid-levelCloudGovernance, Risk & Compliance
• Eine EC2-Instanzrolle ist auf `*:*` (Vollzugriff/Admin) gesetzt, „damit es läuft". Warum ist das gefährlich und was tust du?

  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.

  SeniorCloudIdentity & Access Management
• Ein kompromittierter Laptop liegt auf Ihrem Schreibtisch, noch eingeschaltet, mit einem laufenden verdächtigen Prozess. Was tun Sie, um Beweise zu sichern?

  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.

  Mid-levelDFIR (Forensics & Incident Response)
• Ransomware verschlüsselt gerade jetzt aktiv die Dateifreigaben im gesamten Netzwerk. Was ist Ihre erste Priorität?

  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.

  SeniorDFIR (Forensics & Incident Response)Malware
• Sie haben einen kompromittierten Host bestätigt. Das Business verlangt, ihn in 10 Minuten zu löschen und wieder online zu bringen. Wofür setzen Sie sich ein?

  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.

  SeniorDFIR (Forensics & Incident Response)Threat Intelligence
• Ein geschäftskritischer Produktionsdienst scheint anfällig für einen Memory-Corruption-Exploit, der ihn zum Absturz bringen könnte. Was tun Sie?

  Die Rules of Engagement schließen DoS in Produktion meist aus, und ein ungeplanter Absturz verursacht echten Geschäftsschaden und kann den Auftrag nichtig machen. Prüfen Sie zuerst den Scope; ist ein destruktiver Proof of Concept nicht autorisiert, beweisen Sie die Schwachstelle mit sichereren Mitteln und dokumentieren Sie die wahrscheinliche Auswirkung klar. Den Exploit für einen Screenshot abzufeuern ist leichtsinnig. Ihn wiederholt für „Zuverlässigkeitsmetriken" auszuführen vervielfacht den Ausfall. Ihn stillschweigend zu überspringen verbirgt dem Kunden ein ernstes, ausnutzbares Risiko.

  Mid-levelNetworkingGovernance, Risk & Compliance
• Sie schließen einen Einsatz ab, bei dem Sie Webshells hochgeladen und Testkonten angelegt haben. Was müssen Sie tun?

  Professionelle Einsätze enden mit vollständiger Bereinigung und einem Artefakt-Inventar, damit keine neue Angriffsfläche zurückbleibt und die Umgebung des Kunden nicht getrübt wird. Shells oder Konten für den Kunden zum Finden liegenzulassen ist fahrlässig und gefährlich — ein echter Angreifer könnte sie wiederverwenden. Eine Hintertür „für nächstes Mal" zu behalten ist unethisch und wahrscheinlich illegal. Die eigenen Aktivitätslogs zu löschen zerstört die Audit-Spur, die der Kunde braucht, um den Test zu validieren und nachzuvollziehen, was Sie getan haben.

  Mid-levelGovernance, Risk & Compliance
• Sie knacken das Passwort eines Dienstkontos aus einem erfassten Hash. Was ist der wertvollste nächste Schritt, um das Risiko zu demonstrieren?

  Es zählt die Auswirkung: Ein wiederverwendetes oder überprivilegiertes Dienstkonto, das Domänen-Admin oder kritische Systeme freischaltet, ist das relevante Finding — prüfen Sie also die Wiederverwendung und mappen Sie die Rechte und den Lateral-Movement-Pfad. Zuerst alle anderen Hashes zu knacken ist Beschäftigung, die das Wesentliche verzögert. Das Passwort des Dienstkontos zu ändern ist destruktiv, bricht die Produktion und warnt die Verteidiger. Eine aktive Anmeldeinformation im Klartext per E-Mail zu senden ist selbst eine Exposition und schlechte operative Sicherheit.

  SeniorIdentity & Access ManagementNetworking
• Während des Tests finden Sie Indikatoren, dass ein ECHTER Angreifer bereits in der Umgebung des Kunden ist. Was nun?

  Eine aktive Intrusion zu entdecken ist ein Out-of-Band-Notfall: Die Rules of Engagement sollten einen Eskalationsweg definieren — lösen Sie ihn sofort aus, sichern Sie Beweise und vermeiden Sie es, einen laufenden Vorfall zu kontaminieren. Weiterzutesten kann den echten Angreifer stören oder genau die Beweise zerstören, die die Responder brauchen. Den Angreifer selbst zu entfernen liegt außerhalb des Scopes, ist riskant und kann ihn warnen. Bis zum Abschlussbericht zu warten könnte Tage anhaltender Datenpanne und Datenverlust bedeuten.

  SeniorDFIR (Forensics & Incident Response)Governance, Risk & Compliance
• Welcher Vorwand ist für einen autorisierten Social-Engineering-Test akzeptabel?

  Social-Engineering-Tests müssen innerhalb vereinbarter, ethischer Vorwände bleiben: realistisch genug, um nützlich zu sein, aber ohne Nötigung, ohne das Vortäuschen von Behörden und ohne das Ausnutzen persönlicher oder medizinischer Situationen. Ein generisches IT-Passwort-Reset, das in den Rules of Engagement vereinbart ist, ist zulässig. Sich als krankes Kind eines echten Mitarbeiters auszugeben oder jemandem mit Kündigung zu drohen verursacht echten psychischen Schaden. Sich als Strafverfolgungsbehörde auszugeben täuscht eine Behörde vor und ist selbst mit unterschriebenem Auftrag oft illegal.

  Mid-levelGovernance, Risk & Compliance
• Sie haben eine SQL-Injection in einer Produktionsanwendung und könnten die gesamte Kundendatenbank exportieren, um die Auswirkung zu beweisen. Was ist der verantwortungsvolle Nachweis?

  Beweisen Sie die Schwachstelle, ohne dem Kunden zu schaden oder seine Daten anzuhäufen: Zeigen Sie, dass Sie beliebige Daten über die DB-Version, das Schema oder eine einzelne anonymisierte Stichprobe lesen können, und hören Sie dann auf. Den gesamten PII-Datenbestand zu exfiltrieren erzeugt für beide Seiten eine Haftung zur Meldung von Datenpannen und zum Datenumgang. Eine Tabelle zu löschen ist destruktiv und geht weit über einen Proof of Concept hinaus. Die Datenbank zu verschlüsseln und ein Lösegeld zu fordern ist Erpressung, kein Test — eine Straftat, kein Finding.

  Mid-levelWeb SecurityGovernance, Risk & Compliance
• Mitten im Einsatz entdecken Sie einen ausnutzbaren Host, der eindeutig NICHT im vereinbarten Scope liegt. Was tun Sie?

  Die Autorisierung definiert den Auftrag: Tests außerhalb des vereinbarten Scopes sind potenziell illegal und verletzen die Rules of Engagement, egal wie verlockend das Ziel ist. Dokumentieren Sie, was Sie gesehen haben, stoppen Sie und holen Sie die schriftliche Freigabe des Kunden ein, bevor Sie weitermachen. Ausnutzen für „mehr Findings" rechtfertigt niemals unbefugten Zugriff. Heimliches Ausnutzen in der Annahme, nicht erwischt zu werden, ist sowohl unethisch als auch eine Straftat, und den Scope selbst zu erweitern entzieht dem Kunden seine informierte Einwilligung.

  Mid-levelNetworkingGovernance, Risk & Compliance
• Ihr Bericht enthält 30 Findings. Wie sollten Sie sie präsentieren, damit sie für den Kunden am nützlichsten sind?

  Ein nützlicher Bericht treibt die Behebung an: nach Geschäftsrisiko (Wahrscheinlichkeit × Auswirkung) priorisieren, die Exploit-Ketten hervorheben, die zu kritischer Kompromittierung führen, und für jedes Finding umsetzbare Fixes geben. Alphabetische Sortierung begräbt das Wichtige unter dem, was zufällig mit „A" beginnt. Längster Text zuerst belohnt Wortfülle statt Schwere. Die niedrigen wegzulassen verbirgt echtes Risiko und die Muster, die der Kunde für Defense-in-Depth braucht, und hinterlässt ein falsch beruhigendes Bild.

  Mid-levelGovernance, Risk & ComplianceWeb Security
• Für einen internetexponierten Server gibt es einen Patch für eine kritische, nicht authentifizierte RCE, aber das Team fürchtet Ausfallzeit. Wie gehst du vor?

  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.

  SeniorNetworkingGovernance, Risk & Compliance
• Sie führen MFA ein und Führungskräfte verlangen eine Ausnahme „aus Bequemlichkeit". Wie gehen Sie damit um?

  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.

  Mid-levelIdentity & Access ManagementGovernance, Risk & Compliance
• Eine Überprüfung zeigt, dass das Netzwerk flach ist — Finanzserver teilen sich eine Broadcast-Domäne mit dem Gäste-WLAN. Was empfiehlst du zuerst?

  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.

  SeniorNetworking
• Ein Entwickler bittet um dauerhaften Admin auf dem Produktionscluster, „um schneller zu debuggen". Was bietest du an?

  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.

  Mid-levelIdentity & Access Management
• Ein Entwickler hat versehentlich einen AWS-Zugriffsschlüssel in ein ÖFFENTLICHES GitHub-Repo gepusht. Was ist die richtige Reihenfolge der Reaktion?

  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.

  Mid-levelIdentity & Access ManagementCloud
• Du entdeckst, dass die Anwendungsprotokolle vollständige Kreditkartennummern und Passwörter im Klartext enthalten. Was ist die Korrekturpriorität?

  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.

  Mid-levelGovernance, Risk & ComplianceWeb Security
• Eine öffentliche API fiel aus, weil ihr TLS-Zertifikat abgelaufen war. Über das Erneuern hinaus — was ist die dauerhafte Lösung?

  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.

  Mid-levelCryptographyNetworking
• Ihr SIEM löst täglich 500 „Anmeldefehler“-Alarme aus, fast alles Rauschen, und die Analysten ignorieren die Regel inzwischen. Was ist der richtige Schritt?

  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.

  Mid-levelDFIR (Forensics & Incident Response)Threat Intelligence
• Ihnen fällt auf, dass ein einzelner Host Tausende ungewöhnlicher, langer TXT-Record-DNS-Anfragen an eine einzige Domain stellt. Was ist die wahrscheinlichste Erklärung und Maßnahme?

  TXT-Anfragen mit hohem Volumen und hoher Entropie oder lange Subdomains an eine einzige Domain sind eine klassische Signatur für DNS-Tunneling / C2-und-Exfiltration: Daten werden im DNS eingeschmuggelt, um die Egress-Filterung zu umgehen. Erfassen Sie eine Anfragestichprobe zur Analyse, sinkholen oder blockieren Sie die Domain, um den Kanal zu kappen, und pivotieren Sie zum Host, um den verantwortlichen Prozess zu finden. Es als normales Caching oder langsame Website abzutun übersieht eine laufende Exfiltration. Den DNS-Server neu zu starten ändert nichts am kompromittierten Endgerät und stört nur die Namensauflösung.

  Mid-levelNetworkingThreat Intelligence
• Ein Alarm zeigt einen Benutzer, der sich aus Paris und fünf Minuten später aus Singapur anmeldet. Bevor Sie einen Vorfall ausrufen, was prüfen Sie ZUERST?

  Validieren Sie vor dem Eskalieren. Unternehmens-VPNs, Cloud-Proxys (CASB oder M365-Dienst-IPs) und Mobilfunkanbieter erzeugen routinemäßig falsche „unmögliche Reisen“; prüfen Sie daher die Egress-IPs, das MFA-Ergebnis und das Gerät/den User-Agent, bevor Sie handeln. Bei jedem Treffer automatisch zu sperren verursacht Alarmmüdigkeit und untergräbt das Vertrauen der Nutzer in das SOC. Anzunehmen, es sei immer ein Fehlalarm, übersieht eine echte Kontoübernahme. Den Vorgesetzten anzuschreiben ist langsam und keine Kontrolle — die Protokolle antworten schneller und zuverlässiger.

  JuniorDFIR (Forensics & Incident Response)Identity & Access Management
• Ein Benutzer meldet, dass er auf einen Link in einer verdächtigen E-Mail geklickt und sein Passwort auf der Seite eingegeben hat. Was ist Ihre ERSTE Maßnahme?

  Gehen Sie davon aus, dass das Passwort bereits kompromittiert ist: Erzwingen Sie ein Zurücksetzen UND machen Sie die aktiven Sitzungen und Token des Kontos ungültig, denn ein Reset allein vertreibt keinen Angreifer, der bereits eine aktive Sitzung oder ein Refresh-Token besitzt. Jagen Sie dann anomale Anmeldungen, MFA-Aufforderungen, Postfachregeln und OAuth-Berechtigungen aus dem Expositionsfenster. Die E-Mail zu löschen oder dem Benutzer zu sagen, er solle sein Passwort „beim nächsten Mal“ ändern, lässt das Konto weit offen. Ein Virenscan adressiert Malware auf dem Endgerät, nicht gestohlene Anmeldedaten in der Cloud.

  Mid-levelDFIR (Forensics & Incident Response)Identity & Access Management
• Montag, 9 Uhr, vier Alarme sind offen. Welchen bearbeiten Sie ZUERST?

  Triagieren Sie nach Wirkung und Erreichbarkeit: Credential Dumping (eine mimikatz-Signatur) auf einem Domänencontroller ist ein Kronjuwelen-Ereignis, das zur vollständigen Domänenkompromittierung führen kann; bearbeiten Sie es zuerst. Der externe Portscan wurde bereits vom IDS blockiert, die nicht genehmigte Browser-Erweiterung ist von geringer Schwere, und ein abgelaufenes TLS-Zertifikat auf einer internen Testmaschine ist informativ. Die zentrale SOC-Fähigkeit ist die Priorisierung nach Wirkungsradius und Eskalationswahrscheinlichkeit, nicht nach Alarmalter oder Lautstärke.

  Mid-levelDFIR (Forensics & Incident Response)Threat Intelligence
• Was sind die Vorteile und Risiken des KI-Einsatzes im SOC?

  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.

  Mid-levelAI & LLM SecurityThreat Intelligence
• Was ist der Unterschied zwischen direkter und indirekter Prompt Injection?

  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.

  Mid-levelAI & LLM SecurityWeb Security
• Was ist unsichere Ausgabeverarbeitung in LLM-Apps, und wie führt sie zu XSS oder SSRF?

  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.

  Mid-levelAI & LLM SecurityWeb Security
• Worin unterscheidet sich ein Jailbreak von einer Prompt Injection?

  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.

  JuniorAI & LLM Security
• Was sind die Supply-Chain-Risiken bei der Nutzung von Drittanbieter-LLMs und -Komponenten?

  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.

  SeniorAI & LLM SecurityCloud
• Was ist das NIST AI Risk Management Framework und wie strukturiert es die KI-Governance?

  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.

  SeniorAI & LLM SecurityGovernance, Risk & Compliance
• Gib einen Überblick über die OWASP Top 10 für LLM-Anwendungen.

  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.

  Mid-levelAI & LLM SecurityWeb Security
• Wie sicherst du eine RAG-Pipeline (Retrieval-Augmented Generation) ab?

  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.

  SeniorAI & LLM SecurityWeb Security
• Wie sicherst du einen LLM-Agenten ab, der Tools und Function Calling nutzt?

  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.

  SeniorAI & LLM SecurityWeb Security
• Wie geben LLM-Anwendungen sensible Informationen preis, und wie verhinderst du es?

  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.

  Mid-levelAI & LLM Security
• Was ist Trainingsdaten-Vergiftung und wie verteidigst du dich dagegen?

  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.

  SeniorAI & LLM Security
• Unterscheide Credential Stuffing von Password Spraying, einschließlich wie sich beides in den Logs zeigt.

  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.

  Mid-levelIdentity & Access ManagementDFIR (Forensics & Incident Response)Threat Intelligence
• Erkläre die Cyber Kill Chain von Lockheed Martin und wie ein Blue Team sie nutzt.

  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.

  Mid-levelThreat IntelligenceDFIR (Forensics & Incident Response)Networking
• Erkläre DNS-Datenexfiltration und wie ein Blue Team sie erkennen würde.

  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.

  SeniorNetworkingDFIR (Forensics & Incident Response)Threat Intelligence
• Was ist der Unterschied zwischen EDR und herkömmlichem signaturbasiertem Antivirus?

  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.

  JuniorMalwareDFIR (Forensics & Incident Response)Windows Internals
• Was sind die Phasen des Incident-Response-Lebenszyklus, und warum ist die Reihenfolge wichtig?

  Das klassische Modell ist PICERL: Vorbereitung, Identifikation (Erkennung), Eindämmung, Beseitigung, Wiederherstellung und Lessons Learned. NIST gruppiert es als Vorbereitung; Erkennung und Analyse; Eindämmung, Beseitigung und Wiederherstellung; sowie Aktivität nach dem Vorfall. Die Reihenfolge zählt, weil man den Umfang erfassen und eindämmen muss, bevor man beseitigt, und erst wiederherstellt, wenn die Bedrohung entfernt ist – sonst infiziert man erneut. Es ist eine Schleife, keine Linie: Lessons Learned fließen in die Vorbereitung zurück.

  JuniorDFIR (Forensics & Incident Response)Threat Intelligence
• Erkläre den Unterschied zwischen Indicators of Compromise (IOCs) und Indicators of Attack (IOAs).

  Ein IOC ist ein forensisches Artefakt dafür, dass bereits etwas Bösartiges passiert ist: ein bösartiger Datei-Hash, eine C2-IP oder -Domain, ein bekannter schädlicher Registry-Schlüssel. Ein IOA ist ein Verhaltenssignal eines laufenden Angriffs, unabhängig von den konkreten Werkzeugen, z. B. ein Word-Dokument, das PowerShell startet und dann ins Internet greift. IOCs sind reaktiv und durch Ändern eines Hashes leicht zu umgehen; IOAs erfassen die Absicht und überstehen Werkzeugwechsel.

  Mid-levelThreat IntelligenceDFIR (Forensics & Incident Response)
• Nenne die gängigen Wege, auf denen Malware auf einem Windows-Host über Neustarts hinweg persistiert, und wie du danach jagen würdest.

  Persistenz ist, wie Malware Neustarts und Abmeldungen übersteht. Die typischen unter Windows sind Registry-Run/RunOnce-Schlüssel (HKLM und HKCU), geplante Aufgaben und Windows-Dienste, dazu Autostart-Ordner, WMI-Ereignisabonnements und DLL-Hijacks. Du jagst sie mit autoruns/Sysinternals, Sysmon und Ereignisprotokollen – auf der Suche nach unsignierten Binaries, seltsamen Pfaden wie %AppData% und Einträgen, die direkt nach der Erstkompromittierung erstellt wurden.

  Mid-levelWindows InternalsMalwareDFIR (Forensics & Incident Response)
• Erkläre die Reihenfolge der Flüchtigkeit und warum sie die Abfolge der Beweissicherung im DFIR bestimmt.

  Die Reihenfolge der Flüchtigkeit ordnet Beweise danach, wie schnell sie verschwinden, sodass man das Fragilste zuerst sichert. Grob: CPU-Register/Cache, dann RAM und Laufzeitzustand (Prozesse, Netzwerkverbindungen, ARP), dann temporäre Dateien/Swap, dann Disk, dann Remote-Logging und Überwachungsdaten, und zuletzt Archivmedien und Backups. Außerdem arbeitet man auf forensischen Kopien, hasht sie und führt eine Beweiskette, damit Beweise zulässig bleiben.

  Mid-levelDFIR (Forensics & Incident Response)Windows InternalsLinux Internals
• Wo werden Benutzer-Passwort-Hashes unter Windows und unter Linux gespeichert, und warum zielen Angreifer auf diese Dateien?

  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.

  JuniorWindows InternalsLinux InternalsIdentity & Access Management
• Erkläre Process Injection, nenne ein paar Techniken und sage, wie ein Blue Team sie erkennt.

  Process Injection führt Angreifercode im Speicherbereich eines legitimen Prozesses aus, sodass die Aktivität sich einfügt und das Vertrauen dieses Prozesses erbt. Klassische Techniken sind DLL-Injection (CreateRemoteThread + LoadLibrary), Process Hollowing (einen harmlosen Prozess suspendiert starten, ihn entladen, bösartigen Code schreiben) und APC-Injection. Verteidiger erkennen sie über EDR-API-Hooks, anomale Eltern/Kind-Beziehungen oder Speicherbereiche (RWX, nicht dateigestützter ausführbarer Speicher) und Sysmon-CreateRemoteThread-Ereignisse.

  SeniorWindows InternalsMalwareDFIR (Forensics & Incident Response)
• Was ist Ransomware, und führe mich durch, wie du reagierst, sobald sie aktiv Systeme verschlüsselt.

  Ransomware ist Malware, die Daten verschlüsselt (und zunehmend exfiltriert) und dann Zahlung fordert. Im aktiven Fall: betroffene Hosts vom Netzwerk isolieren, ohne sie auszuschalten, wenn du den Speicher bewahren kannst, Umfang, Patient Zero und die Variante bestimmen, Beweise sichern, das Standbein und etwaige Backdoors finden und vertreiben, dann aus bekannt sauberen Offline-Backups wiederherstellen. Zahlen ist ein letztes Mittel und garantiert nie die Wiederherstellung.

  Mid-levelMalwareDFIR (Forensics & Incident Response)
• Erkläre, wie SPF, DKIM und DMARC zusammenarbeiten, um E-Mail-Spoofing zu verhindern.

  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.

  Mid-levelNetworkingWeb SecurityIdentity & Access Management
• Vergleiche statische und dynamische Malware-Analyse, einschließlich der Stärken und Grenzen jeder Methode.

  Statische Analyse untersucht ein Sample, ohne es auszuführen – Hashes, Strings, Imports, Header und Disassemblierung –, ist also sicher und vollständig in der Abdeckung, aber durch Packing und Obfuskation besiegbar. Dynamische Analyse zündet das Sample in einer isolierten Sandbox und beobachtet echtes Verhalten – Dateien, Registry, Prozesse, Netzwerk –, was Obfuskation durchschneidet, aber nur zeigt, was in dieser Sitzung läuft, und von sandbox-bewusster Malware umgangen werden kann. Analysten kombinieren beide.

  Mid-levelMalwareDFIR (Forensics & Incident Response)
• Was ist ein Honeypot, welche Typen gibt es, und welchen Wert bietet er einem Blue Team?

  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.

  JuniorThreat IntelligenceNetworkingDFIR (Forensics & Incident Response)
• Welche Windows-Ereignis-IDs und -Protokolle würdest du bei der Untersuchung eines Einbruchs zuerst heranziehen?

  Das Security-Protokoll ist primär: 4624 erfolgreiche Anmeldung (mit Anmeldetyp), 4625 fehlgeschlagene Anmeldung, 4634/4647 Abmeldung, 4672 spezielle Rechte zugewiesen, 4720 Konto erstellt, 4688 Prozesserstellung (mit Befehlszeile, falls aktiviert) und 4768/4769 Kerberos. Ergänze 7045 Dienstinstallation (System-Protokoll), 4698 geplante Aufgabe erstellt und PowerShell-Skriptblock-Protokollierung (4104). Anmeldetyp und Befehlszeilen-Auditing machen diese Protokolle nützlich.

  Mid-levelWindows InternalsDFIR (Forensics & Incident Response)
• Erklären Sie DAC, MAC, RBAC und ABAC. Wann würden Sie welches wählen?

  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.

  SeniorIdentity & Access Management
• Erklären Sie BCP versus DRP und definieren Sie RTO und RPO.

  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.

  SeniorDFIR (Forensics & Incident Response)
• Erklären Sie die Rolle der Datenklassifizierung und die Verantwortlichkeiten des Dateneigentümers gegenüber dem Datenverwalter.

  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.

  Mid-levelIdentity & Access Management
• Erklären Sie Defense in Depth und wie es sich vom Verlassen auf eine einzige starke Kontrolle unterscheidet.

  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.

  SeniorNetworking
• Erklären Sie Due Care versus Due Diligence und geben Sie je ein Beispiel.

  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.

  SeniorIdentity & Access Management
• Beschreiben Sie den Identitätslebenszyklus von der Bereitstellung bis zur Deaktivierung. Wo scheitern die meisten Organisationen?

  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.

  SeniorIdentity & Access Management
• Unterscheiden Sie eine Richtlinie, einen Standard, eine Prozedur und eine Leitlinie. Welche sind verbindlich?

  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.

  Mid-levelIdentity & Access Management
• Führen Sie mich durch quantitative versus qualitative Risikoanalyse und definieren Sie ALE, SLE und ARO.

  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.

  Mid-levelDFIR (Forensics & Incident Response)Identity & Access Management
• Welche Optionen haben Sie nach einer Risikobewertung, um ein Risiko zu behandeln? Geben Sie je ein Beispiel.

  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.

  Mid-levelIdentity & Access Management
• Wie würden Sie Sicherheits-Governance in den SDLC einbetten, statt sie am Ende anzuflanschen?

  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.

  SeniorWeb Security
• Wie sichert man Container-Images ab?

  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.

  Mid-levelCloudNetworking
• Wie handhabt man Verschlüsselung im Ruhezustand und während der Übertragung in der Cloud?

  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.

  JuniorCloudCryptography
• IAM-Rollen vs. Benutzer vs. Richtlinien — wie wendet man geringste Rechte in der Cloud an?

  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.

  Mid-levelIdentity & Access ManagementCloud
• Was ist der Instance Metadata Service (IMDS) und wie mindert IMDSv2 SSRF?

  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.

  SeniorCloudIdentity & Access Management
• Was sind die Grundlagen der Kubernetes-Sicherheit (RBAC und Network Policies)?

  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.

  SeniorCloudNetworking
• Wie fügen sich CloudTrail und GuardDuty in Cloud-Logging und -Monitoring ein?

  CloudTrail zeichnet jeden API-Aufruf im Konto auf — wer was wann von wo aus getan hat — und liefert dir den maßgeblichen Audit-Trail für Untersuchungen und Compliance. GuardDuty ist ein verwalteter Bedrohungserkennungsdienst, der CloudTrail-, VPC-Flow- und DNS-Logs analysiert, um Funde wie Anmeldedaten-Exfiltration oder Krypto-Mining sichtbar zu machen. CloudTrail ist die zu schützende Quelle der Wahrheit; GuardDuty verwandelt diese Telemetrie in umsetzbare Alarme.

  Mid-levelCloudNetworking
• Welche S3-Bucket-Fehlkonfigurationen sind verbreitet und wie verhindert man sie?

  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.

  Mid-levelCloudIdentity & Access Management
• Wie verwaltet man Secrets sicher in der Cloud?

  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.

  Mid-levelCloudIdentity & Access Management
• Was ist der Unterschied zwischen Security Groups und Network ACLs?

  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.

  Mid-levelNetworkingCloud
• Erkläre das Modell der geteilten Verantwortung in der Cloud.

  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.

  JuniorCloudIdentity & Access Management
• Was sind die Lieferketten-Risiken in Cloud-CI/CD und wie reduziert man sie?

  CI/CD ist hochwertig, weil sie Deployment-Anmeldedaten hält und nicht vertrauenswürdigen Code ausführt. Risiken umfassen kompromittierte Abhängigkeiten und Build-Actions, geleakte oder zu weit gefasste Secrets, veränderliche Drittanbieter-Actions sowie überprivilegierte Runner oder OIDC-Vertrauen. Reduziere sie mit fixierten und verifizierten Abhängigkeiten, kurzlebiger OIDC-Föderation statt langlebiger Schlüssel, geringsten Rechten eingegrenzt auf konkrete Repos/Branches, isolierten ephemeren Runnern und signierten Artefakten mit nachverfolgter Provenienz (SLSA).

  SeniorCloudIdentity & Access Management
• Was ist der Unterschied zwischen Diffie-Hellman und RSA?

  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.

  Mid-levelCryptography
• Was ist eine digitale Signatur und wie beweist sie Herkunft und Integrität?

  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).

  JuniorCryptography
• Wie funktioniert ein HMAC und warum sollte man ihn statt eines einfachen Hashs verwenden?

  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.

  Mid-levelCryptography
• Wie funktionieren JWTs und auf welche Sicherheitsfallstricke sollte man achten?

  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.

  Mid-levelIdentity & Access ManagementWeb Security
• Erkläre, wie die Kerberos-Authentifizierung mit TGTs und Service-Tickets funktioniert.

  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.

  SeniorIdentity & Access ManagementWindows Internals
• Erkläre mir den OAuth 2.0 Authorization Code Flow.

  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.

  Mid-levelIdentity & Access ManagementWeb Security
• Wie sollten Passwörter gespeichert werden und warum bcrypt/scrypt/argon2 statt schneller Hashes verwenden?

  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.

  Mid-levelCryptographyIdentity & Access Management
• Was ist Perfect Forward Secrecy und warum ist es wichtig?

  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).

  Mid-levelCryptographyNetworking
• Wie validiert ein Client eine Zertifikatskette zurück bis zu einer vertrauenswürdigen Wurzel?

  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.

  SeniorCryptographyIdentity & Access Management
• Was ist ein Salt beim Passwort-Hashing, warum wird er verwendet und was ist ein Pepper?

  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.

  JuniorCryptographyIdentity & Access Management
• Wie funktioniert Single Sign-On und worin unterscheiden sich SAML und OIDC?

  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.

  Mid-levelIdentity & Access Management
• Wie erzeugt eine TOTP-Authenticator-App diese 6-stelligen Codes?

  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.

  JuniorCryptographyIdentity & Access Management
• Wie schützen Artefakt-Signierung und Provenienz die Software-Lieferkette?

  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.

  SeniorCloud
• Wie scannt man Container-Images in einer CI/CD-Pipeline?

  Scannen Sie Images auf bekannte CVEs in OS-Paketen und App-Bibliotheken sowie auf Fehlkonfigurationen und eingebettete Secrets, sowohl zur Build-Zeit als auch fortlaufend in der Registry — weil neue CVEs auftauchen, nachdem ein Image gebaut wurde. Verwenden Sie minimale oder distroless Basis-Images, um die Angriffsfläche zu verkleinern, pinnen und referenzieren Sie Basis-Images per Digest und führen Sie den Container als Nicht-Root aus. Scannen ist notwendig, ersetzt aber nicht den Laufzeitschutz.

  Mid-levelCloud
• Warum sind Lockfiles, Pinning und Dependency Confusion im Build wichtig?

  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.

  SeniorWeb Security
• Wie sichert man Infrastructure as Code in der Pipeline?

  IaC-Scanning analysiert Terraform-, CloudFormation-, Kubernetes- und ähnliche Definitionen statisch gegen eine Richtlinie, um Fehlkonfigurationen zu finden — öffentliche S3-Buckets, offene Security Groups, fehlende Verschlüsselung — bevor sie überhaupt bereitgestellt werden. Da dieselbe Vorlage viele Ressourcen bereitstellt, verhindert eine einmalige Korrektur wiederkehrende Drift, und das Erkennen vor dem Anwenden ist weitaus günstiger als das Beheben aktiver Cloud-Ressourcen. Zu den Tools gehören Checkov, tfsec und KICS, idealerweise als Policy-as-Code-Gates durchgesetzt.

  Mid-levelCloud
• Was ist der Unterschied zwischen SAST, DAST und IAST?

  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.

  Mid-levelWeb Security
• Wie verhindert man, dass Secrets über die CI/CD-Pipeline durchsickern?

  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.

  Mid-levelWeb Security
• Wie sichert man die CI/CD-Pipeline selbst ab?

  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.

  SeniorCloud
• Wann sollte ein Sicherheitsbefund den Build brechen, und wie gehst du mit False Positives um?

  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.

  SeniorWeb Security
• Was bedeutet 'Sicherheit nach links verlagern', und wie tust du es, ohne Entwickler zu blockieren?

  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.

  Mid-levelWeb Security
• Was ist Software Composition Analysis (SCA) und warum ist sie kritisch?

  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.

  Mid-levelWeb Security
• Was ist ein SBOM und warum ist es wichtig?

  Ein SBOM ist ein maschinenlesbares Inventar jeder Komponente, Bibliothek und Abhängigkeit in einer Software, mit Versionen und idealerweise Hashes. Es ist wichtig, weil man bei einer neuen Schwachstelle seine SBOMs abfragen kann, um sofort zu beantworten «Sind wir betroffen und wo?», statt in Hektik zu verfallen. Die beiden dominierenden Standards sind SPDX und CycloneDX, und SBOMs werden zunehmend durch Regulierung und Beschaffung gefordert.

  Mid-levelWeb Security
• Erkläre mir den TLS-1.3-Handshake.

  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.

  Mid-levelNetworkingCryptography
• Können Sie die CIA-Triade erklären und warum sie wichtig ist?

  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.

  JuniorCryptographyIdentity & Access Management
• Erklären Sie Defense in Depth und geben Sie ein Beispiel.

  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.

  JuniorNetworkingIdentity & Access Management
• Können Sie den Unterschied zwischen Hashing, Verschlüsselung und Kodierung erklären?

  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.

  Mid-levelCryptographyWeb Security
• Erklären Sie den Unterschied zwischen einem IDS und einem IPS.

  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.

  JuniorNetworkingThreat Intelligence
• Erklären Sie das Least-Privilege-Prinzip und wie Sie es anwenden würden.

  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.

  Mid-levelIdentity & Access ManagementCloud
• Was ist MFA, und warum ist sie sicherer als ein Passwort allein?

  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.

  JuniorIdentity & Access Management
• Was ist Phishing, und welche Maßnahmen würden Sie ergreifen, um es zu reduzieren?

  Phishing ist Social Engineering, das Menschen dazu verleitet, Anmeldedaten preiszugeben, Geld zu überweisen oder Malware auszuführen, meist über gefälschte E-Mails oder Websites. Die Abwehr ist geschichtet: E-Mail-Filterung und -Authentifizierung (SPF/DKIM/DMARC), MFA zur Begrenzung des Schadens gestohlener Anmeldedaten, Awareness-Schulungen und eine einfache Möglichkeit, verdächtige Nachrichten zu melden.

  JuniorThreat IntelligenceIdentity & Access Management
• Erklären Sie symmetrische versus asymmetrische Verschlüsselung und wann jede eingesetzt wird.

  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.

  JuniorCryptography
• Erklären Sie den Unterschied zwischen TCP und UDP und wann Sie jedes verwenden würden.

  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).

  JuniorNetworking
• Wie unterscheiden Sie eine Schwachstelle von einer Bedrohung und einem Risiko?

  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.

  JuniorThreat Intelligence
• Was ist eine Firewall, und was ist der Unterschied zwischen einer zustandslosen und einer zustandsbehafteten?

  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.

  JuniorNetworking
• Was ist ein Zero-Day, und wie verteidigt man sich gegen etwas ohne Patch?

  Ein Zero-Day ist eine Schwachstelle, die der Hersteller noch nicht kennt (oder nicht gepatcht hat), sodass die Verteidiger „null Tage“ hatten, um sie zu beheben. Da kein Patch existiert, stützt sich die Abwehr auf geschichtete Maßnahmen, verhaltensbasierte Erkennung, Segmentierung, Least Privilege und schnelle Incident Response statt auf eine Signatur.

  Mid-levelThreat IntelligenceMalware
• Ist ARP ein TCP- oder UDP-Protokoll?

  Weder noch. ARP ist ein Layer-2-Protokoll (Sicherungsschicht), das direkt in einem Ethernet-Frame gekapselt wird und nicht in einem IP-Paket. Da es niemals über IP läuft, kann es weder TCP noch UDP verwenden — das sind Layer-4-Transporte, die IP darunter benötigen. Die Aufgabe von ARP besteht darin, eine bekannte IP-Adresse zur passenden MAC-Adresse im selben lokalen Netzsegment aufzulösen.

  JuniorNetworking
• Ihr XSS-Test mit alert() löst aus, aber das Popup ist leer — was sagt Ihnen das?

  Es bestätigt XSS. Wenn alert() überhaupt ausgelöst hat, hat der Browser Ihr eingeschleustes JavaScript im Seitenkontext geparst und ausgeführt — das ist die Schwachstelle. Ein leeres Popup bedeutet nur, dass das übergebene String-Argument nicht wie erwartet angezeigt wurde (Anführungszeichen-Behandlung, Kodierung oder Kontext-Verstümmelung haben die Nachricht zerstört), nicht dass die Payload blockiert wird. Der Ausführungspunkt ist aktiv; von hier aus verfeinern Sie die Payload.

  SeniorWeb Security
• Komprimiert man zuerst und verschlüsselt dann, oder verschlüsselt man zuerst und komprimiert dann?

  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.

  Mid-levelCryptography
• Schützt das Aktivieren von CORS vor CSRF?

  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.

  SeniorWeb Security
• Warum sind „gelöschte“ Daten oft noch wiederherstellbar?

  Weil „löschen“ die Daten normalerweise nicht beseitigt. Es entfernt die Dateisystem-Metadaten — den Zeiger/den Verzeichniseintrag — und markiert die Blöcke als frei, aber die ursprünglichen Bytes bleiben auf der Platte, bis das Betriebssystem diese Blöcke für neue Daten wiederverwendet. Bis dieses Überschreiben geschieht, können forensische Werkzeuge den Inhalt direkt herausziehen.

  JuniorDFIR (Forensics & Incident Response)
• Was ist der Unterschied zwischen Kodierung, Verschlüsselung und Hashing?

  Kodierung wandelt Daten zur Kompatibilität in ein anderes Format um und ist von jedem ohne Schlüssel vollständig umkehrbar (z. B. Base64, URL-Kodierung) — sie bietet keine Vertraulichkeit. Verschlüsselung ist nur mit einem Schlüssel umkehrbar und sorgt für Vertraulichkeit. Hashing ist eine Einwegfunktion: Man kann die Eingabe nicht aus der Ausgabe wiederherstellen, weshalb es sich für Integritätsprüfungen und die Passwortspeicherung eignet (mit Salt und einer langsamen KDF).

  JuniorCryptography
• Was ist in der Sicherheitserkennung schlimmer: ein False Positive oder ein False Negative?

  Aus rein sicherheitstechnischer Sicht ist ein False Negative meist schlimmer: Es bedeutet, dass ein echter Angriff unentdeckt blieb, also gibt es keine Reaktion, keine Eindämmung, und der Vorfall kann unentdeckt schwelen. Aber False Positives sind nicht harmlos — in großer Zahl verursachen sie Alert-Fatigue, bei der Analysten beginnen, Alarme zu ignorieren und den echten zu verpassen. Die richtige Antwort nennt den Kompromiss, nicht nur einen Gewinner.

  Mid-levelDFIR (Forensics & Incident Response)Threat Intelligence
• Hätten Sie auf einer Firewall lieber einen gefilterten oder einen geschlossenen Port?

  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.

  Mid-levelNetworking
• Wenn eine Website das Schloss / HTTPS anzeigt, ist sie dann sicher?

  Nein. Das Schloss bedeutet, dass der Transport verschlüsselt und das Zertifikat für diese Domain gültig ist — es sagt nichts darüber aus, ob der Betreiber ehrlich oder der Inhalt bösartig ist. Kostenlose, automatisierte Zertifikate führen dazu, dass Phishing- und Malware-Seiten fast immer ebenfalls ein einwandfrei gültiges Schloss haben. HTTPS schützt den Kanal, nicht das Ziel.

  JuniorWeb Security
• Verhindert HTTPS Man-in-the-Middle-Angriffe vollständig?

  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.

  Mid-levelNetworking
• Ist HTTPS dasselbe wie SSL? Und was ist der Unterschied zwischen SSL und TLS?

  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.

  JuniorNetworkingCryptography
• MD5 und SHA-256 sind beide schnelle Hashes — warum eignet sich keiner zur Passwortspeicherung?

  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.

  Mid-levelCryptography
• Welchen Port verwendet ping?

  Fangfrage — ping verwendet keinen Port. Es läuft über ICMP, ein Layer-3-Protokoll, das direkt auf IP aufsitzt. Ports existieren nur in Layer-4-Protokollen wie TCP und UDP, daher hat ICMP (und somit ping) keinen. ICMP verwendet stattdessen Typ- und Code-Felder, z. B. Echo Request Typ 8 und Echo Reply Typ 0.

  JuniorNetworking
• Wie viele Pakete werden beim TCP-Drei-Wege-Handshake ausgetauscht?

  Drei. Der Client sendet ein SYN, der Server antwortet mit einem kombinierten SYN-ACK (ein Paket, das sowohl das SYN des Clients bestätigt als auch das eigene SYN des Servers sendet), und der Client schließt mit einem ACK ab. Der Trick ist, dass SYN-ACK ein einzelnes Paket ist, nicht zwei, sodass die Summe drei beträgt — genau das, was „Drei-Wege“ benennt.

  JuniorNetworking
• Erklären Sie die Kategorien von Sicherheitskontrollen und nennen Sie Beispiele für jede.

  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.

  Mid-levelGovernance, Risk & Compliance
• Was sind die Grundprinzipien der GDPR und wie lautet die Frist für die Meldung von Datenschutzverletzungen?

  Artikel 5 der GDPR legt sieben Grundsätze fest: Rechtmäßigkeit/Verarbeitung nach Treu und Glauben/Transparenz, Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung, Integrität und Vertraulichkeit sowie Rechenschaftspflicht. Bei einer Verletzung des Schutzes personenbezogener Daten muss der Verantwortliche die zuständige Aufsichtsbehörde unverzüglich und nach Möglichkeit binnen 72 Stunden nach Bekanntwerden benachrichtigen (Artikel 33). Birgt die Verletzung voraussichtlich ein hohes Risiko für die Personen, muss der Verantwortliche auch die betroffenen Personen unverzüglich benachrichtigen (Artikel 34).

  Mid-levelGovernance, Risk & Compliance
• Wie unterscheiden sich Governance, Risiko und Compliance, und wie hängen sie zusammen?

  Governance ist die Art, wie die Führung die Richtung vorgibt, Verantwortlichkeit festlegt und die Sicherheit auf die Geschäftsziele ausrichtet — die Richtlinien, Rollen und Aufsicht, die definieren, wie „gut" aussieht. Risikomanagement ist der Prozess, Bedrohungen für diese Ziele zu erkennen, zu bewerten, zu behandeln und zu überwachen. Compliance bedeutet, die Einhaltung von Verpflichtungen nachzuweisen — Gesetze, Vorschriften, Verträge und interne Richtlinien. Governance steuert Risikoentscheidungen; das Risiko bestimmt, welche Kontrollen Sie brauchen; Compliance belegt, dass diese Kontrollen die geforderten Standards erfüllen. Compliance ist ein Ergebnis guter GRC, kein Ersatz für Sicherheit.

  SeniorGovernance, Risk & Compliance
• Erklären Sie die HIPAA-Grundlagen: PHI, die Schutzmaßnahmen der Security Rule und wer sie einhalten muss.

  HIPAA (der US-amerikanische Health Insurance Portability and Accountability Act) schützt Protected Health Information (PHI). Die Privacy Rule regelt Nutzung und Offenlegung von PHI; die Security Rule gilt für elektronische PHI (ePHI) und verlangt drei Kategorien von Schutzmaßnahmen — administrative, physische und technische. Sie gilt für covered entities (Leistungserbringer, Gesundheitspläne, Clearingstellen) und für business associates, die in ihrem Auftrag PHI verarbeiten und durch Business Associate Agreements gebunden sind. Die Breach Notification Rule legt die Pflichten zur Benachrichtigung von Personen, des HHS und mitunter der Medien fest.

  Mid-levelGovernance, Risk & Compliance
• Was ist ein ISMS nach ISO/IEC 27001, und welche Rolle spielt Anhang A?

  ISO/IEC 27001 legt die Anforderungen an ein Information Security Management System (ISMS) fest: ein risikobasiertes, von oben gesteuertes Rahmenwerk aus Richtlinien, Prozessen, Rollen und kontinuierlicher Verbesserung (Plan-Do-Check-Act), das regelt, wie eine Organisation die Informationssicherheit handhabt. Anhang A ist ein Referenzkatalog von Kontrollen. Man wendet nicht alle blind an — man führt eine Risikobewertung durch, entscheidet, welche Kontrollen nötig sind, und dokumentiert die Aufnahme-/Ausschlussentscheidungen mit Begründung in einer Statement of Applicability (SoA).

  SeniorGovernance, Risk & Compliance
• Nennen und erklären Sie die Kernfunktionen des NIST Cybersecurity Framework.

  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.

  Mid-levelGovernance, Risk & Compliance
• Erklären Sie die PCI-DSS-Grundlagen: was es schützt, für wen es gilt und die Reduzierung des Geltungsbereichs.

  PCI DSS (Payment Card Industry Data Security Standard) ist ein vom PCI Security Standards Council gepflegter Sicherheitsstandard, der für jede Organisation gilt, die Karteninhaberdaten speichert, verarbeitet oder übermittelt. Er ist um Kontrollziele herum aufgebaut, die ein sicheres Netzwerk, den Schutz gespeicherter Karteninhaberdaten, das Schwachstellenmanagement, eine starke Zugriffskontrolle, Überwachung/Tests und eine Informationssicherheitsrichtlinie abdecken. Der Geltungsbereich ist alles im cardholder data environment (CDE) — daher sind Segmentierung, Tokenisierung und das Nichtspeichern unnötiger Daten die wichtigsten Wege, ihn zu verkleinern.

  Mid-levelGovernance, Risk & Compliance
• Wie würden Sie ein Programm für Sicherheitsbewusstsein und -schulung gestalten und messen?

  Behandeln Sie Bewusstseinsbildung als Verhaltensänderung, nicht als jährliches Häkchen. Machen Sie sie rollenbasiert (eine Entwicklerin braucht andere Inhalte als die Finanzabteilung), kontinuierlich statt einer Folienpräsentation einmal im Jahr und verankert in realen Risiken wie Phishing, Social Engineering und Datenhandhabung. Verstärken Sie sie mit Phishing-Simulationen, zeitnahen Hinweisen und klaren Meldewegen. Messen Sie Ergebnisse — Phishing-Melderate, Klickrate, Zeit bis zur Meldung — nicht nur Abschlussquoten. Bauen Sie eine Kultur auf, in der Menschen Fehler ohne Angst melden, denn Angst unterdrückt das Melden.

  Mid-levelGovernance, Risk & Compliance
• Erkläre den Unterschied zwischen Security-KPIs und -KRIs, mit Beispielen.

  Ein KPI (Key Performance Indicator) misst, wie gut eine Sicherheitsaktivität gegenüber ihrem Ziel abschneidet — zum Beispiel Mean Time to Detect, Patch-SLA-Einhaltung oder Prozentsatz der Systeme mit MFA. Ein KRI (Key Risk Indicator) ist ein vorausschauendes Signal, dass das Risikoexposure auf ein inakzeptables Niveau ansteigt, mit einer Schwelle, die Handeln auslösen sollte — zum Beispiel die Zahl überfälliger kritischer Patches, die Anzahl unverwalteter Geräte oder fehlgeschlagene Access Reviews mit steigendem Trend. KPIs sagen dir, wie es läuft; KRIs warnen dich, wohin es sich entwickelt.

  SeniorGovernance, Risk & Compliance
• Erklären Sie SOC 2 Typ I vs. Typ II und die Trust Services Criteria.

  Ein SOC-2-Bericht vom Typ I beurteilt, ob die Kontrollen einer Dienstleistungsorganisation zu einem einzelnen Zeitpunkt angemessen gestaltet sind. Ein Typ-II-Bericht geht weiter: Er prüft, ob diese Kontrollen über einen Prüfzeitraum hinweg wirksam funktioniert haben, typischerweise 3 bis 12 Monate. Beide basieren auf den Trust Services Criteria der AICPA — Sicherheit (die verpflichtenden gemeinsamen Kriterien), plus optional Verfügbarkeit, Verarbeitungsintegrität, Vertraulichkeit und Datenschutz.

  Mid-levelGovernance, Risk & Compliance
• Führe mich durch, wie du Drittanbieter- (Lieferanten-)Risiko bewertest und steuerst.

  Behandle Lieferantenrisiko als Lebenszyklus, nicht als einmaligen Fragebogen. Inventarisiere deine Drittparteien und stufe sie nach Kritikalität und Datensensibilität ein. Führe Due Diligence proportional zur Stufe durch — prüfe SOC 2- / ISO 27001-Berichte, Sicherheitsfragebögen, Pentest-Zusammenfassungen sowie die betroffenen Daten und Zugriffe. Verankere Kontrollen im Vertrag (Sicherheitsanforderungen, Auditrecht, Meldepflicht bei Datenpannen, Datenverarbeitung, Unterauftragsverarbeiter). Überwache dann kontinuierlich, nicht nur beim Onboarding, und habe einen sauberen Offboarding-Prozess, um Zugriffe zu entziehen und Daten zurückzuholen oder zu vernichten. Auch das Viertparteien-Risiko (Unterauftragsverarbeiter) zählt.

  SeniorGovernance, Risk & Compliance
• Wie etablieren Sie eine Baseline des Normalzustands, und wie hilft sie bei der Erkennung von Anomalien?

  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.

  Mid-levelThreat IntelligenceDFIR (Forensics & Incident Response)
• Wie würden Sie in der Netzwerktelemetrie nach C2-Beaconing jagen?

  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.

  SeniorThreat IntelligenceDFIR (Forensics & Incident Response)
• Wie entscheiden Sie, welche Logquellen und Telemetrie Sie benötigen, um wirksam zu jagen?

  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.

  Mid-levelThreat IntelligenceDFIR (Forensics & Incident Response)
• Führen Sie mich durch den Lebenszyklus einer Erkennung, von der Idee bis zur gepflegten Regel.

  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.

  SeniorThreat IntelligenceDFIR (Forensics & Incident Response)
• Was sind Living-off-the-Land-Binaries (LOLBins), und wie würden Sie ihren Missbrauch aufspüren?

  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.

  SeniorThreat IntelligenceDFIR (Forensics & Incident Response)
• Erklären Sie die Pyramid of Pain und wie sie bestimmt, wo Sie den Erkennungsaufwand investieren.

  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.

  Mid-levelThreat IntelligenceDFIR (Forensics & Incident Response)
• Wie würden Sie einen TTP-basierten Threat Hunt mit MITRE ATT&CK strukturieren, und was macht einen guten Hunt aus?

  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.

  SeniorThreat IntelligenceDFIR (Forensics & Incident Response)
• Was ist User and Entity Behaviour Analytics (UEBA), und welche Bedrohungen fängt es ab?

  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.

  Mid-levelThreat IntelligenceIdentity & Access Management
• Was ist Threat Hunting, und wie unterscheidet es sich vom Warten auf Alarme?

  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.

  Mid-levelThreat IntelligenceDFIR (Forensics & Incident Response)
• Was ist Sigma, und wie würdest du einen Hunt-Befund in eine portable Detection-Regel verwandeln?

  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.

  Mid-levelThreat IntelligenceDFIR (Forensics & Incident Response)
• Was sind Zugriffsüberprüfungen (Rezertifizierung) und warum sind sie wichtig?

  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.

  Mid-levelIdentity & Access ManagementGovernance, Risk & Compliance
• Was ist bedingter / risikobasierter Zugriff und wie funktioniert er?

  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.

  Mid-levelIdentity & Access ManagementCloud
• Was ist Identitätsföderation, und welche Rolle spielt ein Identitätsanbieter?

  Identitätsföderation stellt Vertrauen zwischen einem Identitätsanbieter (IdP), der Benutzer authentifiziert, und Dienstanbietern (vertrauenden Parteien) her, die diese Authentifizierung nutzen. Der IdP verifiziert den Benutzer und stellt eine signierte Assertion oder ein Token aus; der Dienstanbieter vertraut ihm, statt eigene Anmeldedaten zu verwalten. Das ermöglicht domänenübergreifendes SSO und zentrale Kontrolle, konzentriert aber das Risiko: Kompromittiert man den IdP, kompromittiert man alles, was ihm vertraut.

  Mid-levelIdentity & Access ManagementCloud
• Was ist Just-in-Time-Zugriff (JIT), und wie passen Break-Glass-Konten dazu?

  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.

  SeniorIdentity & Access ManagementCloud
• Was sagt die moderne NIST-800-63B-Leitlinie zu Passwörtern?

  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.

  JuniorIdentity & Access Management
• Was macht MFA «phishing-resistent», und wie erreichen FIDO2/Passkeys das?

  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.

  Mid-levelIdentity & Access ManagementCryptography
• Was ist Privileged Access Management (PAM) und welches Problem löst es?

  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.

  Mid-levelIdentity & Access Management
• RBAC vs. ABAC: Wann greift man in der Praxis zu welchem?

  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.

  Mid-levelIdentity & Access ManagementCloud
• Was ist SCIM, und wie unterstützt es Joiner-Mover-Leaver-Provisionierung?

  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.

  Mid-levelIdentity & Access ManagementCloud
• Wie verwaltest du Session- und Token-Lebensdauern (Access vs. Refresh, Rotation)?

  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.

  SeniorIdentity & Access ManagementWeb Security
• Erkläre die Zero-Trust-Architektur und was sich bei ihrer Einführung ändert.

  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.

  SeniorIdentity & Access ManagementNetworkingCloud
• Definieren Sie die gängigen Malware-Kategorien und erklären Sie, wie Sie ein Sample anhand seines Verhaltens klassifizieren.

  Man klassifiziert danach, wofür das Sample gebaut ist, beobachtet aus seinem Verhalten und seinen Fähigkeiten. Ein Dropper trägt eine Payload und schreibt sie auf die Festplatte; ein Loader holt oder injiziert die nächste Stufe, oft nur im Speicher; ein RAT gibt einem Operator interaktive Fernsteuerung; ein Wiper zerstört Daten oder Boot-Records ohne Wiederherstellungsabsicht; Ransomware verschlüsselt Dateien und fordert Zahlung. Echte Samples kombinieren oft Rollen — ein Loader, der ein RAT ausliefert — daher beschreibt man die Fähigkeitskette, statt ein einziges Etikett zu erzwingen, und ordnet jedes Verhalten ATT&CK-Techniken zu.

  JuniorMalwareDFIR (Forensics & Incident Response)
• Wann greifen Sie zu Ghidra oder IDA statt zu einem Debugger wie x64dbg, und wie ergänzen sie sich?

  Ein Disassembler wie Ghidra oder IDA liefert die vollständige statische Karte: Querverweise, dekompilierten Pseudocode und jeden Codepfad, ob er ausgeführt wird oder nicht. Ein Debugger wie x64dbg lässt Sie das Sample kontrolliert ausführen — Haltepunkte setzen, Register und Speicher prüfen, die Entschlüsselung beobachten und den Pfad verfolgen, den der Code mit echten Eingaben tatsächlich nimmt. Man liest Struktur und Absicht statisch, hängt dann den Debugger an, um aufzulösen, was die statische Analyse nicht kann: zur Laufzeit entschlüsselte Strings, dynamisch aufgelöste APIs, gepackte Payloads und welchen Zweig eine Bedingung nimmt. Beide zusammen schließen ihre gegenseitigen Lücken.

  SeniorMalwareWindows Internals
• Was sind die Anzeichen für Command-and-Control-Beaconing, und wie extrahiert man C2-Indikatoren aus einem Sample?

  Command-and-Control-Beaconing ist der Implant, der periodisch nach Hause ruft, um Anweisungen zu erhalten. Man erkennt es an regelmäßigen, volumenarmen ausgehenden Rückrufen in etwa festem Intervall — oft mit Jitter, um nicht mechanisch zu wirken — zu einer kleinen Menge von Zielen, häufig über HTTP/HTTPS oder DNS mit kodierten oder verschlüsselten Payloads und einem unverwechselbaren User-Agent- oder URI-Muster. Indikatoren extrahiert man statisch, indem man Domains, IPs, URIs und Schlüssel aus Strings und Konfigurationsblöcken zieht, und dynamisch, indem man das Sample gegen ein gefälschtes Netzwerk detoniert und die tatsächlichen Rückrufe erfasst, dann ordnet man das Verhalten ATT&CK zu und speist die IOCs in die Erkennung ein.

  Mid-levelMalwareDFIR (Forensics & Incident Response)
• Was sind Packer und Obfuskation, und wie erkennt man sie in einem Binary?

  Packen komprimiert oder verschlüsselt die eigentliche Payload und stellt ihr einen Stub voran, der sie zur Laufzeit in den Speicher entpackt; Obfuskation transformiert Code oder Daten, um dem Lesen und Signaturen zu widerstehen. Packen erkennt man an hoher Sektionsentropie nahe 8,0, einer winzigen oder nur aus dem Stub bestehenden Importtabelle, ungewöhnlichen oder schreib-ausführbaren Sektionsnamen wie UPX0, einem Einsprungpunkt außerhalb von .text, einer großen virtuellen Größe gegenüber einer kleinen Rohgröße sowie Detektoren wie Detect It Easy oder PEiD. Keines davon ist allein schlüssig, daher wägen Analysten mehrere Signale zusammen ab und bestätigen, indem sie das Entpacken zur Laufzeit beobachten.

  Mid-levelMalwareWindows Internals
• Führen Sie mich durch das Windows-PE-Dateiformat und welche Teile Sie beim Triage eines Samples untersuchen.

  Eine PE-Datei beginnt mit dem DOS-Header und seinem e_lfanew-Zeiger auf die PE/NT-Header, die den File Header und den Optional Header enthalten (Einsprungpunkt, Image Base, Subsystem). Sie ist in Sektionen unterteilt — .text für Code, .data, .rdata, .rsrc für Ressourcen — jede mit virtueller Adresse und Rohgröße. Beim Triage liest man die Importtabelle nach verdächtigen APIs, die Sektionstabelle nach seltsamen Namen und hoher Entropie, die auf Packen hindeuten, den Timestamp und den Rich Header, eingebettete Ressourcen und jede digitale Signatur. Diskrepanzen zwischen diesen verraten viel, noch bevor man die Datei ausführt.

  Mid-levelMalwareWindows Internals
• Erklären Sie gängige Prozessinjektions-Techniken und die API- und Verhaltenssignaturen, die sie verraten.

  Prozessinjektion führt bösartigen Code in einem anderen Prozess aus, um sich zu verstecken und dessen Vertrauen zu erben. Die klassische Remote-Injektion reserviert Speicher in einem Ziel mit VirtualAllocEx, schreibt eine Payload per WriteProcessMemory und führt sie mit CreateRemoteThread aus. Varianten umfassen DLL-Injektion per LoadLibrary, Process Hollowing, das einen suspendierten legitimen Prozess aushängt und sein Image ersetzt, APC-Injektion, die Code in einen Thread einreiht, und reflektives oder manuell gemapptes Laden, das LoadLibrary ganz vermeidet. Man erkennt sie an den verräterischen API-Sequenzen, RWX-Speicher in einem normalerweise sauberen Prozess, Threads ohne Backing-Datei auf der Festplatte und Eltern-Kind-Anomalien.

  SeniorMalwareWindows Internals
• Beschreibe, wie du ein isoliertes Labor aufbaust, um Live-Malware sicher zu analysieren.

  Ein sicheres Labor isoliert die Malware von allem, das sie schädigen könnte. Du führst Samples in wegwerfbaren VMs auf einem Hypervisor aus, erstellst saubere Snapshots, sodass du nach jeder Detonation zurücksetzen kannst, und kappst echten Netzwerkzugang über ein Host-Only-Netzwerk mit simuliertem Internet (INetSim oder FakeNet) oder ein air-gapped Segment. Du trennst die Analyse-Maschine von einem kontrollierten Gateway, analysierst nie auf deinem Alltags-Host, härtest gegen VM-Escape, behandelst Samples als passwortgeschützte ZIPs und hältst Werkzeuge und Indikatoren von der Detonations-VM fern. Das Ziel ist, echtes Verhalten zu beobachten und zugleich zu garantieren, dass das Sample weder die Produktion noch das Internet erreichen kann.

  JuniorMalwareDFIR (Forensics & Incident Response)
• Wie erkennt und umgeht Malware Analyse-Sandboxes, und wie wirkst du dem entgegen?

  Sandbox-bewusste Malware prüft, ob sie beobachtet wird, bevor sie sich fehlverhält. Sie sucht nach VM- und Hypervisor-Artefakten (Treiber, MAC-Präfixe, Registry-Schlüssel, CPUID), nach Analyse-Werkzeugen und Debuggern (Prozessnamen, IsDebuggerPresent, Timing des Single-Steppings) und nach Anzeichen eines echten Benutzers (wenige Prozesse, keine zuletzt verwendeten Dokumente, keine Mausbewegung, niedrige Uptime, kleine Festplatte). Sie kann mit langen Sleeps verzögern oder nur an einem bestimmten Datum, in einer bestimmten Sprache oder Domäne auslösen. Analysten wirken dem entgegen, indem sie die VM so härten, dass sie echt aussieht, die Prüfungen herauspatchen, Sleeps vorspulen, Benutzeraktivität simulieren und das Verhalten mit statischem Disassembly bestätigen.

  SeniorMalwareDFIR (Forensics & Incident Response)
• Führe mich durch deine zentralen Werkzeuge für statische gegenüber dynamischer Malware-Analyse und wann du jedes einsetzt.

  Statische Werkzeuge lesen das Sample im Ruhezustand: PEStudio, CFF Explorer und pefile für Header und Imports, FLOSS und strings für eingebetteten Text, capa für das Mapping von Fähigkeiten und Ghidra oder IDA für Disassembly. Dynamische Werkzeuge beobachten es bei der Ausführung in einer isolierten VM: Procmon und Process Hacker für Host-Aktivität, Wireshark und INetSim oder FakeNet für ein gefälschtes Netzwerk, Regshot für Vorher/Nachher-Diffs und x64dbg für kontrolliertes Stepping. Der Workflow ist: statisch triagieren, dynamisch detonieren und dann zum Disassembler zurückkehren, um Verhaltenslücken zu füllen.

  Mid-levelMalwareDFIR (Forensics & Incident Response)
• Beschreibe, wie du ein gepacktes Sample entpackst, um den ursprünglichen Code zu erreichen.

  Entpacken stellt den ursprünglichen Code wieder her, den der Packer verborgen hat. Für bekannte Packer nutzt du den passenden Unpacker oder einen Emulator. Für eigene Packer entpackst du manuell: Führe das Sample in einem Debugger aus, lass den Stub die Payload in den Speicher dekomprimieren, finde den Moment, in dem er zum ursprünglichen Entry Point springt (oft durch Breakpoint auf Speicher, der ausführbar wird, oder auf den Tail-Jump), dumpe dann das Prozess-Image aus dem Speicher und baue die Import Address Table mit einem Werkzeug wie Scylla oder PE-sieve wieder auf. Das Ergebnis ist eine lauffähige oder analysierbare PE, die die echte Payload enthält.

  SeniorMalwareWindows Internals
• Erklären Sie, wie YARA-Regeln funktionieren und was eine Regel wirksam macht statt fragil oder rauschanfällig.

  Eine YARA-Regel besteht aus einem meta-Block, einem strings-Abschnitt (Text-, Hex- oder Regex-Muster mit Wildcards und Sprüngen) und einer Bedingung, die diese Treffer mit boolescher und Zähllogik kombiniert. Eine wirksame Regel stützt sich auf etwas Dauerhaftes und Unverwechselbares — einen einzigartigen Code-Stub, einen Mutex-Namen, einen Konfigurationsmarker oder eine ungewöhnliche Import-Kombination — statt auf Werte, die ein Angreifer trivial ändert wie einen einzelnen Hash oder einen generischen String. Man wägt Spezifität gegen Fehlalarme ab, testet gegen einen sauberen Korpus und dokumentiert die Regel, damit andere ihr vertrauen und sie pflegen.

  Mid-levelMalwareThreat Intelligence
• Was ist Coordinated Vulnerability Disclosure und wie sollte sie funktionieren?

  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.

  Mid-levelWeb SecurityThreat Intelligence
• Erläutern Sie mir den Prozess der digitalen Forensik und Incident Response.

  DFIR folgt einem disziplinierten Prozess: Identifikation (Vorfall bestätigen und eingrenzen), Sicherung (Beweise nach Order of Volatility bewahren, mit forensischen Images und Hashes), Analyse (Zeitachse, Grundursache, Umfang der Kompromittierung) und Reporting (Befunde für technische und juristische Zielgruppen). Die Chain of Custody dokumentiert, wer jedes Artefakt wann angefasst hat, damit die Beweise standhalten, falls sie je vor Gericht landen. Bewahren vor Beheben.

  Mid-levelDFIR (Forensics & Incident Response)
• Wie nutzen Sie MITRE ATT&CK für eine bedrohungsinformierte Verteidigung?

  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.

  Mid-levelThreat IntelligenceDFIR (Forensics & Incident Response)
• Wie strukturieren Sie einen Webanwendungstest mit dem OWASP WSTG?

  Der WSTG ist eine checklistengestützte Methodik, die eine App durch Testkategorien führt: Informationsbeschaffung, Konfiguration und Deployment, Identität und Authentifizierung, Autorisierung, Session-Management, Eingabevalidierung (Injection/XSS), Fehlerbehandlung, Kryptografie, Geschäftslogik und Client-seitig. Er bietet systematische Abdeckung mit stabilen Test-IDs, sodass Befunde reproduzierbar sind und nichts Offensichtliches übersprungen wird.

  Mid-levelWeb Security
• Erläutern Sie mir eine Penetrationstest-Methodik wie PTES.

  PTES definiert sieben Phasen: Pre-Engagement (Scope, Rules of Engagement, Autorisierung), Intelligence Gathering (OSINT, Aufklärung), Threat Modeling, Schwachstellenanalyse, Exploitation, Post-Exploitation (Pivoting, wertvolle Daten, Persistenz) und Reporting. Die Struktur macht Einsätze wiederholbar, vertretbar und an das Geschäftsrisiko gebunden statt an Ad-hoc-Hacking. Pre-Engagement und Reporting sind die Phasen, die Juniors unterschätzen.

  Mid-levelNetworkingWeb Security
• Was ist Purple Teaming und wie führen Sie eine Purple-Team-Übung durch?

  Purple Teaming ist kollaborativ statt gegnerisch: Die rote Seite führt konkrete, vereinbarte TTPs aus (oft an MITRE ATT&CK ausgerichtet), während die blaue Seite ihre Telemetrie in Echtzeit beobachtet, um zu bestätigen, ob jede Technik geloggt, alarmiert und erkennbar ist. Sie messen die Detektionsabdeckung Technik für Technik, justieren Detektionen und schließen Lücken sofort, dann testen Sie erneut. Das Deliverable ist eine verbesserte, messbare Detektion — keine Liste, wer gewonnen hat.

  Mid-levelThreat IntelligenceDFIR (Forensics & Incident Response)
• Wie unterscheidet sich ein Red-Team-Einsatz von einem Penetrationstest?

  Ein Pentest zielt auf breite Abdeckung — so viele Schwachstellen wie möglich in einem abgegrenzten Ziel finden. Ein Red Team ist zielgetriebene Adversary Emulation: ein Ziel wählen (z. B. die wertvollsten Daten erreichen), die TTPs eines bestimmten Bedrohungsakteurs emulieren, verdeckt bleiben, um Detektion und Reaktion zu testen, und lautes Scanning vermeiden. Red Teaming misst das blaue Team und die ganze Organisation, nicht nur das Asset; beide brauchen strenge Rules of Engagement und Autorisierung.

  SeniorNetworkingThreat Intelligence
• Wie führen Sie eine Risikobewertung durch?

  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.

  SeniorIdentity & Access ManagementThreat Intelligence
• Wie gehen Sie an ein Secure Code Review heran?

  Beginnen Sie damit, das Bedrohungsmodell der App zu verstehen und wo sie nicht vertrauenswürdige Eingaben, Geheimnisse, Authentifizierung und Autorisierung verarbeitet. Nutzen Sie SAST zum breiten Scannen und DAST gegen die laufende App, behandeln Sie die Tool-Ausgabe aber als Hinweise, nicht als Befunde — sortieren Sie False Positives aus. Verwenden Sie dann die menschliche Zeit auf die wertvollen, kontextabhängigen Bereiche, die Tools verpassen: Autorisierungslogik, Geschäftslogik, Krypto-Nutzung und Vertrauensgrenzen. Verfolgen Sie den Datenfluss von der Source bis zum Sink.

  SeniorWeb Security
• Wie sieht ein sicherer SDLC aus?

  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.

  Mid-levelWeb Security
• Wie führen Sie eine Threat-Modeling-Übung durch?

  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.

  SeniorWeb SecurityCloud
• Erläutern Sie mir den Lebenszyklus des Schwachstellenmanagements.

  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.

  Mid-levelNetworkingCloud
• Welche Ports nutzen SSH, HTTP, HTTPS, DNS, RDP und SMB, und warum sind sie wichtig?

  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.

  JuniorNetworking
• Wie funktioniert die DNS-Auflösung — rekursiv vs. autoritativ?

  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.

  JuniorNetworking
• Was ist der Unterschied zwischen einem Forward-Proxy und einem Reverse-Proxy?

  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.

  Mid-levelNetworkingWeb Security
• Wie funktioniert traceroute, und welche Rolle spielt das TTL-Feld?

  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.

  Mid-levelNetworking
• Was ist NAT, und wie unterscheidet sich PAT davon?

  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.

  Mid-levelNetworking
• Erklären Sie das OSI-Modell und was jede Schicht hinzufügt.

  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.

  JuniorNetworking
• Was ist ein Subnetz, und was macht eine Subnetzmaske?

  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.

  JuniorNetworking
• Erklären Sie den TCP-Drei-Wege-Handshake.

  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.

  JuniorNetworking
• TCP vs. UDP — worin unterscheiden sie sich und wann wählt man welches?

  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).

  JuniorNetworking
• Wie vergleicht sich das TCP/IP-Modell mit dem OSI-Modell?

  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.

  JuniorNetworking
• Was ist ein VLAN, und welchen Sicherheitswert hat es?

  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.

  Mid-levelNetworking
• Was ist der Unterschied zwischen einem VPN und einem Proxy?

  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.

  JuniorNetworking
• Was ist eine DMZ in der Netzwerkarchitektur, und warum würde man eine einsetzen?

  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.

  Mid-levelNetworking
• Erkläre mir, wie du eine brandneue Zielmaschine enumerierst.

  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.

  JuniorNetworkingLinux Internals
• Warum alle 65535 Ports scannen, und wie macht man das effizient mit nmap?

  Der Standard-nmap-Scan deckt nur die 1000 häufigsten Ports ab, also würde ein Dienst auf einem hohen Port komplett übersehen. Das effiziente Muster ist zuerst ein schneller SYN-Scan aller 65535 Ports, dann ein fokussierter Versions- und Standardskript-Scan nur gegen die als offen gefundenen Ports.

  JuniorNetworking
• Du hast eine Shell mit niedrigen Rechten auf einer Linux-Maschine. Wie eskalierst du?

  Enumeriere systematisch: prüfe sudo -l, SUID/SGID-Binaries, Cronjobs, die Kernel- und OS-Version, beschreibbare Dateien in privilegierten Pfaden, Capabilities und gespeicherte Anmeldedaten. Werkzeuge wie LinPEAS automatisieren den Durchlauf, aber du verifizierst jede Erkenntnis weiterhin anhand von GTFOBins oder einer bekannten Technik.

  Mid-levelLinux Internals
• Wie findest und nutzt du gefahrlos einen öffentlichen Exploit gegen ein Ziel?

  Bestimme den genauen Dienst und die Version, suche auf Exploit-DB oder mit searchsploit nach einem passenden PoC und lies dann den Code Zeile für Zeile, bevor du ihn ausführst — korrigiere die Ziel-IP, den Port und die Reverse-Shell-Adresse, generiere jeglichen Shellcode neu und verstehe, was er tut, damit er sich nicht gegen dich wenden kann.

  Mid-levelMalwareLinux Internals
• Du hast einige Passwort-Hashes ausgelesen. Wie knackst du sie?

  Bestimme zuerst das Hash-Format (hashid oder Kontext), führe dann hashcat oder John mit dem korrekten Modus gegen eine Wortliste wie rockyou aus und wende Regeln an, um Kandidaten zu mutieren. Nutze das richtige Format-Flag (NTLM, sha512crypt, NetNTLMv2 usw.), damit das Werkzeug die Versuche genauso hasht wie das Ziel.

  Mid-levelCryptography
• Du hast einen Host mit einer zweiten Netzwerkschnittstelle kompromittiert. Wie pivotierst du?

  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.

  SeniorNetworking
• Was prüfst du, wenn du SMB und SNMP offen auf einem Host findest?

  Bei SMB enumerierst du Freigaben, prüfst auf anonymen/Null-Session-Zugriff, listest Benutzer auf und bestimmst die Version für bekannte CVEs. Bei SNMP probierst du Standard-Community-Strings wie „public“ und gehst die MIB durch, um Benutzernamen, laufende Prozesse, installierte Software und Netzwerkdetails zu extrahieren.

  Mid-levelWindows InternalsNetworking
• Du fängst eine Reverse Shell ab, aber sie ist instabil. Wie verbesserst du sie?

  Man startet ein Pseudoterminal (meist python -c 'import pty; pty.spawn("/bin/bash")'), legt es mit Ctrl-Z in den Hintergrund, führt lokal stty raw -echo aus, holt es wieder in den Vordergrund und setzt TERM sowie die Zeilen-/Spaltenzahl zurück. Das ergibt ein vollständiges TTY mit Jobsteuerung, Tab-Vervollständigung und funktionierenden Editoren.

  JuniorLinux Internals
• Wie enumerierst du einen Webserver, den du noch nie gesehen hast?

  Bestimme den Stack aus Headern und Quellcode, dann brute-force Verzeichnisse und Dateien mit gobuster oder feroxbuster unter Nutzung einer guten Wortliste und relevanter Endungen. Suche nach Admin-Panels, Backups, Konfigurationsdateien und Upload-Punkten und prüfe virtuelle Hosts, wenn die Seite auf einen Hostnamen reagiert.

  JuniorWeb Security
• Wie gehst du die Rechteausweitung auf einem Windows-Ziel an?

  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.

  SeniorWindows Internals
• Zeigen Sie mir, wie Sie gängige Web-Bugs — etwa SQL-Injection und XSS — zu einer Wirkung kombinieren würden, die über einen einzelnen Fund hinausgeht.

  Einzeln legt SQLi Daten offen oder verändert sie und kann RCE erreichen; Stored XSS kapert Sitzungen im Browser der Opfer. Verkettet können Sie SQLi nutzen, um eine Stored-XSS-Payload zu platzieren, die in der Sitzung eines Admins ausgelöst wird, dessen Sitzung zu stehlen und zur vollständigen Anwendungskontrolle zu eskalieren.

  Mid-levelWeb Security
• Führen Sie mich durch Kerberoasting — wie es funktioniert, warum es möglich ist und wie Verteidiger es stoppen.

  Jeder authentifizierte Domänenbenutzer kann ein Kerberos-Service-Ticket (TGS) für jedes Konto mit einem SPN anfordern. Dieses Ticket ist mit dem NTLM-Passwort-Hash des Dienstkontos verschlüsselt, sodass Sie es extrahieren und das Passwort offline knacken — kein privilegierter Zugriff zu Beginn nötig, und es ist nahezu lautlos.

  SeniorWindows InternalsCryptography
• Erklären Sie den Unterschied zwischen passiver und aktiver Aufklärung, mit Beispielen für jede.

  Passive Aufklärung sammelt Informationen, ohne direkt mit den Systemen des Ziels zu interagieren — OSINT, DNS-Einträge, Certificate Transparency. Aktive Aufklärung berührt das Ziel, etwa Portscans oder Banner-Grabbing, was lauter ist, aber mehr Details liefert.

  JuniorNetworkingThreat Intelligence
• Führen Sie mich durch die Phasen eines Penetrationstests vom Kickoff bis zur Übergabe.

  Ein Pentest durchläuft Pre-Engagement (Scope und Einsatzregeln), Aufklärung, Scanning und Enumeration, Ausnutzung, Post-Exploitation und Reporting. Jede Phase speist die nächste, und im Reporting wird der Wert tatsächlich an den Kunden geliefert.

  JuniorNetworkingWeb Security
• Sie haben einen Host in einem segmentierten Netzwerk kompromittiert. Erklären Sie, wie Sie pivotieren, um Systeme zu erreichen, die Sie nicht direkt berühren können.

  Pivoting verwandelt einen kompromittierten Host in ein Relais, damit Sie interne Segmente erreichen, zu denen Ihre Maschine nicht routen kann. Sie nutzen Port-Forwarding, einen SOCKS-Proxy über Ihren C2-Kanal (z. B. Chisel, SSH-Dynamic-Forwarding) oder agentenbasiertes Routing und führen dann Werkzeuge durch diesen Tunnel, um das nächste Subnetz anzugreifen.

  SeniorNetworkingWindows Internals
• Sie haben eine Shell mit niedrigen Rechten auf einer Linux-Maschine. Führen Sie mich durch, wie Sie zu root eskalieren würden.

  Enumerieren Sie zuerst: aktuelle Rechte, sudo-Rechte, SUID/SGID-Binaries, Cron-Jobs, beschreibbare Dateien im PATH, Kernel-Version und gespeicherte Zugangsdaten. Nutzen Sie dann den einfachsten zuverlässigen Weg — oft eine fehlkonfigurierte sudo-Regel oder ein SUID-GTFOBin — bevor Sie zu einem Kernel-Exploit greifen.

  Mid-levelLinux InternalsNetworking
• Sie haben eine Shell mit niedrigen Rechten auf einem Windows-Host gelandet. Wie weiten Sie Ihre Rechte aus?

  Enumerieren Sie die Rechte des Kontos und die Fehlkonfigurationen des Hosts: Token-Privilegien wie SeImpersonate, Dienstpfade ohne Anführungszeichen, schwache Dienstberechtigungen, AlwaysInstallElevated und gespeicherte Zugangsdaten. Missbrauchen Sie dann das zuverlässigste — Token-Impersonation (Potato-Angriffe) ist ein gängiger Weg zu SYSTEM.

  Mid-levelWindows InternalsIdentity & Access Management
• Erklären Sie Reverse Shells im Vergleich zu Bind Shells und wann Sie welche wählen würden.

  Eine Bind Shell öffnet einen lauschenden Port auf dem Ziel und wartet, dass Sie sich verbinden. Eine Reverse Shell lässt das Ziel ausgehend zu einem von Ihnen kontrollierten Listener verbinden. Reverse Shells gewinnen meist, weil ausgehender Verkehr eingehende Firewall-Regeln und NAT umgeht.

  Mid-levelNetworkingLinux Internals
• Ein Kunde fragt, warum er für einen Pentest zahlen soll, wenn er bereits Schwachstellenscans durchführt. Wie antworten Sie?

  Ein Schwachstellenscan ist eine automatisierte, in die Breite gehende Bestandsaufnahme potenzieller Schwächen, oft mit Fehlalarmen. Ein Penetrationstest ist menschengeführt: Er validiert Funde, verkettet sie und demonstriert durch tatsächliche Ausnutzung echte geschäftliche Auswirkungen.

  JuniorNetworkingWeb Security
• Die technische Arbeit ist erledigt. Was gehört in einen Bericht, auf den der Kunde tatsächlich reagiert?

  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.

  SeniorWeb SecurityDFIR (Forensics & Incident Response)
• Erkläre Defense in Depth und nenne ein konkretes Beispiel für die Anwendung.

  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.

  JuniorNetworkingIdentity & Access Management
• Erkläre mir, wie du einen frisch aufgesetzten, internetzugänglichen Linux-Server härten würdest.

  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.

  SeniorLinux InternalsNetworking
• Worin unterscheidet sich Hashing von Verschlüsselung, und wann würdest du das eine dem anderen vorziehen?

  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.

  JuniorCryptography
• Was ist das Prinzip der geringsten Rechte, und wie würdest du es in der Praxis durchsetzen?

  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.

  Mid-levelIdentity & Access Management
• Wie sollten Secrets wie API-Schlüssel und Datenbankpasswörter in einer Anwendung verwaltet werden?

  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.

  Mid-levelIdentity & Access ManagementCloud
• Wie sieht ein sicherer SDLC aus, und welche Sicherheitsaktivitäten finden in jeder Phase statt?

  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.

  SeniorWeb SecurityDFIR (Forensics & Incident Response)
• Wie würdest du eine öffentlich erreichbare REST-API absichern?

  Ü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.

  Mid-levelWeb SecurityIdentity & Access Management
• Was ist Netzwerksegmentierung, und wie verhält sie sich zu einem Zero-Trust-Modell?

  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.

  SeniorNetworkingIdentity & Access Management
• Was ist der Unterschied zwischen symmetrischer und asymmetrischer Verschlüsselung, und wann würdest du welche verwenden?

  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.

  JuniorCryptography
• Was ist eine PKI, und erkläre mir, wie ein Client das Zertifikat eines Servers validiert.

  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.

  Mid-levelCryptographyNetworking
• Ihre Analysten ertrinken in Alerts. Was ist Alert-Fatigue und was würden Sie dagegen tun?

  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.

  JuniorDFIR (Forensics & Incident Response)
• Beide beinhalten fehlgeschlagene Logins. Wie würden Sie in Ihren Logs einen Brute-Force-Angriff von einem Password Spray unterscheiden?

  Brute Force zielt auf ein einzelnes Konto mit vielen Passwortversuchen, daher sieht man viele Fehlschläge auf einen Benutzernamen konzentriert. Password Spray dreht das um: ein oder wenige gängige Passwörter über viele Konten probiert, langsam und unauffällig, sodass jedes Konto nur ein paar Fehlschläge sieht. Das Erkennungssignal ist das Verhältnis von Konten zu Fehlschlägen und das Timing, nicht die reine Anzahl der Fehlschläge.

  Mid-levelIdentity & Access ManagementDFIR (Forensics & Incident Response)Windows Internals
• Warum sind DNS-Logs für die Detektion nützlich, und welche Bedrohungen kann man darin finden?

  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.

  SeniorNetworkingDFIR (Forensics & Incident Response)Threat Intelligence
• Können Sie erklären, wie sich EDR, XDR und SIEM unterscheiden und wo jedes einzelne passt?

  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.

  JuniorDFIR (Forensics & Incident Response)Windows Internals
• Eine Regel erzeugt Hunderte Fehlalarme pro Tag. Wie tunen Sie sie sicher herunter?

  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.

  Mid-levelDFIR (Forensics & Incident Response)Threat Intelligence
• Ein Angreifer hat auf einem Host Fuß gefasst. Nach welchen Anzeichen von Lateral Movement würden Sie jagen?

  Lateral Movement bedeutet, dass ein Angreifer einen Fußabdruck nutzt, um andere Systeme zu erreichen. Anzeichen sind unerwartete Netzwerk-Logons (Typ 3) und RDP (Typ 10), Zugriff auf Admin-Shares wie C$ und ADMIN$, Remote-Ausführungstools wie PsExec, WMI und WinRM, Pass-the-Hash-Muster und ein normalerweise lokales Konto, das sich plötzlich an vielen Hosts authentifiziert.

  SeniorWindows InternalsDFIR (Forensics & Incident Response)Identity & Access Management
• Wie würden Sie das MITRE-ATT&CK-Framework nutzen, um Ihre Detektionsabdeckung zu verbessern?

  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.

  Mid-levelThreat IntelligenceDFIR (Forensics & Incident Response)
• Ein Nutzer meldet eine verdächtige E-Mail. Führen Sie mich durch Ihr sicheres Triage-Vorgehen.

  Prüfen Sie die E-Mail sicher ohne zu klicken: Header und Absender-Authentifizierung (SPF/DKIM/DMARC) checken, URLs und Anhänge in einer Sandbox oder mit Reputations-Tools inspizieren, dann den Umfang bestimmen — wer sie sonst erhielt, ob jemand klickte oder Zugangsdaten eingab. Je nach Befund remediieren: E-Mail purgen, Indikatoren blockieren und kompromittierte Zugangsdaten zurücksetzen.

  JuniorDFIR (Forensics & Incident Response)Threat IntelligenceWeb Security
• Wir betreiben sowohl ein SIEM als auch ein SOAR. Was macht jedes davon, und wie arbeiten sie zusammen?

  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.

  JuniorDFIR (Forensics & Incident Response)Threat Intelligence
• Ein SIEM-Alert wird wegen eines verdächtigen Logins ausgelöst. Führen Sie mich durch Ihr Triage-Vorgehen.

  Bestätigen Sie vor dem Handeln, dass der Alert echt ist: Lesen Sie, was ausgelöst wurde und warum, dann reichern Sie an — wer ist der Benutzer, sind Quell-IP/Geo/Gerät erwartbar, ist es Impossible Travel, gab es zuvor Fehlschläge? Klassifizieren Sie als echten oder falschen Treffer, eskalieren oder dämmen Sie ein, wenn echt (Sitzung deaktivieren, MFA-Reset erzwingen), und dokumentieren Sie alles, damit der nächste Analyst Ihrer Argumentation folgen kann.

  JuniorDFIR (Forensics & Incident Response)Threat IntelligenceIdentity & Access Management
• Erklären Sie mir, was die Windows-Event-IDs 4624, 4625 und 4688 bedeuten und wie Sie sie in einer Untersuchung nutzen würden.

  4624 ist ein erfolgreicher Logon, 4625 ein fehlgeschlagener Logon und 4688 eine Prozesserstellung. In einer Untersuchung nutzen Sie 4625, um Credential-Angriffe aufzuspüren, 4624 (mit seinem Logon-Typ und der Quelle), um einen erfolgreichen Zugriff und dessen Zustandekommen zu bestätigen, und 4688, um zu sehen, was tatsächlich ausgeführt wurde, idealerweise mit aktiviertem Kommandozeilen-Auditing.

  JuniorWindows InternalsDFIR (Forensics & Incident Response)
• Was ist Content-Security-Policy und wie hilft sie?

  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.

  SeniorWeb Security
• Was ist CSRF und wie verhindern Tokens und SameSite es?

  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.

  Mid-levelWeb Security
• Was sind die OWASP Top 10?

  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.

  JuniorWeb Security
• Wie sollte man Benutzerpasswörter speichern?

  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.

  Mid-levelWeb SecurityCryptography
• Wie verhindern Prepared Statements SQL-Injection?

  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.

  Mid-levelWeb Security
• Wie verhindert man XSS?

  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.

  Mid-levelWeb Security
• Erkläre die Same-Origin Policy und CORS.

  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.

  Mid-levelWeb Security
• Was bewirken die Cookie-Attribute HttpOnly, Secure und SameSite?

  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.

  JuniorWeb Security
• Welche HTTP-Antwort-Header verbessern die Sicherheit?

  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.

  Mid-levelWeb Security
• Was sind die wichtigsten Arten von SQL-Injection?

  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.

  Mid-levelWeb Security
• Was ist SSRF und warum ist der Cloud-Metadaten-Dienst ein Ziel?

  SSRF bringt einen Server dazu, HTTP- (oder andere) Anfragen an ein vom Angreifer gewähltes Ziel zu stellen, und missbraucht die Netzwerkposition des Servers, um interne Dienste hinter der Firewall zu erreichen. In der Cloud ist es besonders gravierend, weil der Instanz-Metadaten-Dienst (z. B. 169.254.169.254) IAM-Anmeldedaten zurückgeben kann und so ein SSRF zur Kompromittierung des Cloud-Kontos macht.

  SeniorWeb SecurityCloud
• HTTP ist zustandslos — wie funktionieren dann Sitzungen?

  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.

  JuniorWeb SecurityIdentity & Access Management
• Erkläre Stored-, Reflected- und DOM-basiertes XSS.

  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.

  Mid-levelWeb Security
• Was ist ein XXE-Angriff und wie mildert man ihn ab?

  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.

  SeniorWeb Security