IT-Sicherheits-Texte sind voll von Drei-Buchstaben-Akronymen und Begriffen, die für Eingeweihte selbstverständlich sind und alle anderen aussperren. Dieses Glossar erklärt die häufigsten — knapp, mit konkretem Beispiel, mit Verweis auf das vertiefende Kapitel. Es ersetzt keine Lehrbuch-Definitionen, aber es bringt dich durch jeden Security-Bulletin und jede CVE-Beschreibung.
Die drei Grundbegriffe: Vulnerability, Threat, Risk
Diese drei werden oft synonym verwendet — sie bedeuten unterschiedliche Dinge.
- Vulnerability (Schwachstelle) — eine Eigenschaft eines Systems, die ausnutzbar ist. Beispiel: eine SQL-Injection-Lücke in einer Login-Maske, ein veraltetes Plugin mit bekannter RCE.
- Threat (Bedrohung) — eine potenzielle Quelle von Schaden. Beispiel: eine Ransomware-Bande, ein neugieriger Insider, ein opportunistischer Bot.
- Exploit — der konkrete technische Mechanismus, der eine Schwachstelle ausnutzt. Beispiel: ein Python-Skript, das per HTTP-POST den SQLi-Vektor schickt.
- Risk (Risiko) — die Kombination aus Wahrscheinlichkeit (Threat trifft Vulnerability) und Schaden. Wird in Risiko und Defense-in-Depth vertieft.
Merksatz: Eine Schwachstelle wird durch einen Exploit unter Beweis gestellt; eine Bedrohung tut das absichtlich; das Risiko ist die Frage, ob es passiert und was es kostet.
CVE — Common Vulnerabilities and Exposures
CVE ist ein eindeutiger Identifier für eine konkrete Schwachstelle in einem konkreten Produkt. Das Programm wird von MITRE im Auftrag der US-Regierung betrieben, die Daten sind frei.
Format: CVE-JAHR-NUMMER, z. B. CVE-2024-3094 (der XZ-Backdoor-Versuch) oder CVE-2021-44228 (Log4Shell).
CVE-Einträge enthalten typischerweise:
- Eine Beschreibung der Schwachstelle.
- Betroffene Versionen.
- Verweise auf Advisories, Patches und ggf. PoCs.
- Eine CVSS-Bewertung (siehe nächster Abschnitt).
- Eine Verknüpfung zu einer oder mehreren CWE-Klassen.
Wer Schwachstellen-Reports liest oder Patch-Notes verfolgt, sieht ständig CVE-IDs. Die wichtigsten Quellen:
- cve.org — offizielles Verzeichnis.
- nvd.nist.gov — National Vulnerability Database (NIST) mit CVSS-Anreicherung.
- Vendor-Bulletins (Microsoft MSRC, Red Hat Security, Mozilla Foundation Security Advisories etc.).
CVSS — Common Vulnerability Scoring System
CVSS ist die standardisierte Schwere-Bewertung einer Schwachstelle auf einer 0–10-Skala. Aktuelle Version ist CVSS v4.0 (2023 veröffentlicht); v3.1 ist weit verbreitet und wird parallel weiter genutzt.
| Score | Stufe | Praxis-Bedeutung |
|---|---|---|
| 0.0 | None | Informativ, keine Schwachstelle |
| 0.1 – 3.9 | Low | Niedrig — meistens kein Sofort-Patchen |
| 4.0 – 6.9 | Medium | Mittel — geplant einspielen |
| 7.0 – 8.9 | High | Hoch — innerhalb weniger Tage patchen |
| 9.0 – 10.0 | Critical | Kritisch — sofort, oft Out-of-Band-Patch |
CVSS berechnet sich aus mehreren Metrik-Gruppen: Base (Eigenschaften der Schwachstelle selbst), Threat (aktuelle Exploitation-Aktivität, neu in v4), Environmental (eigener Kontext). Üblicherweise wird der Base-Score zitiert, mit dem Vektor-String dahinter (z. B. CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/...). Der Vektor sagt, wie der Score zustande kommt.
Wichtig: CVSS ist eine technische Schwere-Bewertung, kein Geschäftsrisiko-Score. Eine 9.8-CVE in einer Software, die du nicht einsetzt, ist für dich irrelevant. Eine 5.0-CVE in deinem Kern-System kann dich treffen. Priorisierung erfordert immer Kontext.
Ergänzendes Tool: EPSS (Exploit Prediction Scoring System) gibt die geschätzte Wahrscheinlichkeit an, dass eine CVE in den nächsten 30 Tagen aktiv ausgenutzt wird — hilft beim „Was patchen wir zuerst?".
CWE — Common Weakness Enumeration
CWE ist eine Klassifikation von Schwachstellen-Typen — die abstrakte Kategorie hinter konkreten CVEs. Geführt von MITRE, ebenfalls frei verfügbar.
Beispiele:
- CWE-79 — Improper Neutralization of Input During Web Page Generation (= XSS).
- CWE-89 — Improper Neutralization of Special Elements used in an SQL Command (= SQL Injection).
- CWE-352 — Cross-Site Request Forgery (CSRF).
- CWE-22 — Path Traversal.
- CWE-287 — Improper Authentication.
- CWE-798 — Use of Hard-coded Credentials.
Jährlich erscheint die CWE Top 25 — die häufigsten Schwachstellen-Typen, oft als Querverweis zur OWASP Top 10. Die beiden Listen überlappen, sind aber nicht identisch: OWASP Top 10 ist Web-zentriert und Risiko-orientiert, CWE Top 25 ist breiter (auch Embedded, IoT, Kernel) und Häufigkeits-orientiert.
IOC und TTPs
Zwei Begriffe aus dem Threat Intelligence- und Detection Engineering-Umfeld:
- IOC — Indicator of Compromise. Ein technischer Hinweis darauf, dass ein System kompromittiert wurde oder ein Angriff stattfindet. Beispiele: eine bekannte Malware-Hash, eine C2-IP-Adresse, eine bestimmte Datei-Pfad-Signatur, ein verdächtiger Registry-Key.
- TTP — Tactics, Techniques and Procedures. Die Verhaltensmuster eines Angreifers — auf welcher Taktik-Ebene (siehe ATT&CK in angriffsketten-und-kill-chain), mit welcher Technik, in welcher konkreten Variante.
Der Unterschied ist operativ wichtig: IOCs sind schnell zu integrieren (in Firewall, EDR, SIEM), aber kurzlebig — ein Angreifer ändert IP und Hash mit wenigen Klicks. TTPs sind schwer zu ändern — wer ein bestimmtes Verhalten gewohnt ist, ändert das nicht im laufenden Betrieb. Detection auf TTP-Ebene ist daher haltbarer, aber aufwendiger zu bauen.
Genau das zeigt David Biancos Pyramid of Pain: je weiter oben in der Hierarchie (Hash → IP → Domain → Tool → TTP), desto mehr Schmerz verursacht eine Detection beim Angreifer.
0-Day, n-Day, PoC
- 0-Day (Zero-Day) — eine Schwachstelle, die dem Hersteller noch nicht bekannt ist und für die folglich kein Patch existiert. Sie ist die wertvollste Klasse von Schwachstellen, weil sie zum Zeitpunkt der Entdeckung durch Angreifer keine Verteidigung gegen sich hat. „0-Day-Markt" beschreibt den Handel mit solchen Lücken — von Bug-Bounty-Programmen (legal) bis zu Exploit-Brokern (Grauzone bis illegal).
- n-Day — eine Schwachstelle, die seit n Tagen bekannt ist (manchmal auch: für die seit n Tagen ein Patch existiert). Ab Veröffentlichung beginnt das Patch-Rennen: Angreifer reverse-engineeren den Patch, bauen Exploits, scannen das Internet nach ungepatched Systemen.
- PoC — Proof of Concept. Ein Code-Schnipsel oder eine technische Demonstration, dass eine Schwachstelle ausnutzbar ist. PoCs werden in CVE-Bulletins, Security-Blogs und auf github.com/topics/poc veröffentlicht. Wichtig: ein PoC ist kein fertiger Exploit-Code für Live-Systeme — er beweist nur die Existenz der Schwachstelle. Die ethischen Standards in der Security-Community verlangen, PoCs erst nach koordinierter Offenlegung zu veröffentlichen.
Eng verwandt: Responsible Disclosure (oder Coordinated Vulnerability Disclosure) — der Prozess, in dem Forscher:innen eine Schwachstelle zuerst dem Hersteller melden, eine angemessene Zeit zum Patchen geben und erst danach veröffentlichen. Google Project Zero hat den Standard von 90 Tagen geprägt.
Weitere Vokabeln, die immer wieder auftauchen
| Begriff | Bedeutung | Im Detail bei |
|---|---|---|
| APT | Advanced Persistent Threat — staatlicher/staatsnaher Angreifer mit langem Atem | Angreifer-Typen |
| C2 / C&C | Command & Control — Steuerungs-Kanal zwischen Angreifer und kompromittiertem System | Kill Chain |
| RCE | Remote Code Execution — Angreifer kann beliebigen Code ausführen | (Kap 13 Injection) |
| LFI / RFI | Local / Remote File Inclusion — ungeprüftes include/require | (Kap 13 Injection) |
| SSRF | Server-Side Request Forgery — Server macht im Namen des Angreifers Anfragen | (Kap 18 API-Sicherheit) |
| MITM | Man-in-the-Middle — Angreifer sitzt zwischen zwei Kommunikations-Endpunkten | (Kap 19 TLS) |
| IDS / IPS | Intrusion Detection / Prevention System — erkennt bzw. blockt Angriffsmuster | (Kap 20 Server-Härtung) |
| WAF | Web Application Firewall — Filter speziell für HTTP-Verkehr | (Kap 20 Server-Härtung) |
| SIEM | Security Information and Event Management — zentrale Log-Korrelation | (Kap 20 Server-Härtung) |
| EDR / XDR | Endpoint / Extended Detection & Response — Verhaltens-Analyse auf Endgeräten | (Kap 20 Server-Härtung) |
| SOC | Security Operations Center — Team, das Monitoring & IR betreibt | (Kap 20 Server-Härtung) |
| MFA / 2FA | Multi-/Two-Factor Authentication — mehrere Faktoren beim Login | (Kap 2 + Kap 14) |
| SSO | Single Sign-On — eine Anmeldung deckt mehrere Dienste ab | (Kap 14 Auth-Entwickler) |
| OIDC | OpenID Connect — Identity-Layer auf OAuth 2 | (Kap 14 Auth-Entwickler) |
| JWT | JSON Web Token — signiertes Token-Format | (Kap 14 Auth-Entwickler) |
| PII | Personally Identifiable Information — personenbezogene Daten | (allgemein) |
| DPA / DPIA | Data Protection Agreement / Impact Assessment (DSGVO-Begriffe) | (allgemein) |
| SBOM | Software Bill of Materials — Liste aller Komponenten einer Software | (Kap 10 OWASP A06) |
| CIA-Triade | Confidentiality, Integrity, Availability | Was ist Web-Sicherheit? |
| STRIDE | Spoofing, Tampering, Repudiation, Information Disclosure, DoS, Elevation | Bedrohungsmodelle |
Interessantes
CVE-Nummern werden nicht in Reihenfolge vergeben
Eine CVE-ID wird einer Schwachstelle zugewiesen, sobald eine sogenannte CNA (CVE Numbering Authority) sie reserviert — Hersteller wie Microsoft, Red Hat, Mozilla, GitHub sind eigene CNAs. Manche Nummern werden Monate vor Veröffentlichung reserviert; aus der ID lassen sich daher keine Rückschlüsse auf das Veröffentlichungs-Datum ziehen.
Die NVD hat seit 2024 einen Bearbeitungs-Rückstau
Die National Vulnerability Database des NIST hat Anfang 2024 die Anreicherung neu eingehender CVEs drastisch reduziert. Viele CVE-Einträge haben seitdem keine CVSS-Werte und keine CWE-Verknüpfung mehr. Alternative Quellen wie GitHub Security Advisories, OSV und Vendor-Bulletins werden dadurch wichtiger.
OWASP Top 10 ist keine CWE-Liste
Sie ist eine kuratierte Risiko-Liste basierend auf Vorfall-Daten und Survey-Antworten der OWASP-Community. Jede Top-10-Kategorie verlinkt auf passende CWEs, aber die Aggregation ist Risiko-orientiert. Daher überschneiden sich beide Listen, sind aber nicht austauschbar.
Bug Bounty vs. 0-Day-Markt
Bug-Bounty-Programme (HackerOne, Bugcrowd, Intigriti) zahlen Forscher:innen für gemeldete Schwachstellen — das Geld geht an die Finder:innen, der Patch entsteht koordiniert. Auf dem grauen 0-Day-Markt zahlen Broker (Zerodium und andere) für funktionierende Exploits — die Lücke wird nicht gepatched, sondern an Käufer (oft Geheimdienste) weitergegeben. Die Preise dort übersteigen Bug-Bounty-Zahlungen oft um Größenordnungen.
Manche "Zero-Days" sind keine
Marketing-Texte rufen oft "Zero-Day" für n-Day-Lücken aus, die schon einen Patch haben — weil "Zero-Day" mehr Aufmerksamkeit erzeugt. Wenn ein Patch existiert, ist es per Definition kein 0-Day mehr. Achtsam lesen.
Sigma-Regeln als TTP-Detection-Format
Sigma ist ein offenes Format, um Detection-Regeln in einer SIEM-unabhängigen YAML-Syntax zu beschreiben. Übersetzer wandeln Sigma in Splunk-SPL, Elastic-EQL, KQL um. Praktisch, weil Threat-Intel-Teams Detection-Logik teilen können, ohne sich auf ein SIEM-Produkt zu committen.
Weiterführende Ressourcen
Externe Quellen
- CVE.org – offizielles Verzeichnis
- NIST National Vulnerability Database (NVD)
- FIRST CVSS v4.0 Specification
- FIRST EPSS – Exploit Prediction Scoring System
- MITRE CWE – Common Weakness Enumeration
- MITRE CWE Top 25 (jährlich)
- OSV – Open Source Vulnerability Database
- GitHub Security Advisories
- BSI – Glossar Cybersicherheit