Dieses Glossar erfasst zentrale Begriffe rund um den SSDLC. Füge neue Definitionen nach Bedarf hinzu.

Sicherheitsartefakte #

Sicherheitsartefakte sind dokumentierte Nachweise, die belegen, dass definierte Sicherheitsanforderungen erfüllt werden. Sie entstehen in jeder SSDLC-Phase und dienen Auditoren, Teams und Stakeholdern als Prüfbasis.

• Typische Beispiele: Bedrohungsmodelle, Code-Review-Protokolle, Scan-Reports, Freigabe-Checklisten.
• Ablage: Versionskontrollsystem (docs/<projekt>/...) oder revisionssichere Confluence-Seite.
• Qualitätskriterien: vollständig, nachvollziehbar, mit Datum, Owner und Referenz zum betreffenden Kontrollziel.

Bewahrt Sicherheitsartefakte mindestens bis zum Abschluss des nächsten Audits auf.

Bedrohungsmodell (Threat Model) #

Ein Bedrohungsmodell beschreibt systematisch, welche Assets, Komponenten und Schnittstellen bedroht sein können. Es analysiert mögliche Angreiferwege, bewertet Risiken und leitet Schutzmaßnahmen für das Design ab.

• Typische Schritte: Systemgrenzen festlegen, Datenflüsse visualisieren, Bedrohungen bewerten, Gegenmaßnahmen priorisieren.
• Methoden: STRIDE, Attack Trees, PASTA oder OWASP Threat Dragon für kollaborative Modellierung.
• Sicherheitsartefakt: Diagramm oder Tabelle mit Asset, Bedrohung, Auswirkung, Schutzmaßnahme, Owner und Prüftermin.
• Aktualisierung: Nach jeder Architekturänderung oder mindestens halbjährlich prüfen und freigeben.

STRIDE #

STRIDE ist eine Microsoft-Methode, die Bedrohungen nach sechs Kategorien (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) klassifiziert. Jede Kategorie hilft, Angriffsszenarien systematisch zu identifizieren und Gegenmaßnahmen abzuleiten. Siehe auch Bedrohungsmodell.

Attack Trees #

Attack Trees beschreiben Angriffe als Baumstruktur mit einem Ziel an der Wurzel und möglichen Angriffspfaden als Äste. Die Methode unterstützt Priorisierung nach Aufwand, Wahrscheinlichkeit oder Impact und erlaubt automatisches Scoring. Dieser Ansatz ergänzt Bedrohungsmodelle und kann mit STRIDE kombiniert werden.

PASTA (Process for Attack Simulation and Threat Analysis) #

PASTA ist ein siebenstufiges Threat-Modeling-Framework, das Geschäftsziele, technische Komponenten und Risikomodelle verknüpft. Es legt besonderen Fokus auf Angriffssimulationen und Business-Impact, um Sicherheitsanforderungen abzuleiten. PASTA erweitert klassische Bedrohungsmodelle um Risiko- und Compliance-Perspektiven.

OWASP Threat Dragon #

OWASP Threat Dragon ist ein Open-Source-Tool für kollaboratives Threat Modeling. Es bietet Drag-and-Drop-Diagramme, STRIDE-basierte Bedrohungskataloge und Exportfunktionen für Berichte. Das Tool unterstützt Teams bei der Pflege ihrer Bedrohungsmodelle in der CI/CD-Pipeline.

SAST (Static Application Security Testing) #

SAST bezeichnet quellcode- oder buildzeitbasierte Sicherheitsanalysen, die Schwachstellen früh im Entwicklungsprozess finden. Die Werkzeuge untersuchen Code ohne ihn auszuführen und liefern konkrete Fundstellen zur Nachbesserung.

• Zweck: Frühzeitige Erkennung struktureller Schwachstellen wie Injection, unsichere Konfiguration oder fehlende Validierung.
• Typische Tools: semgrep, SonarQube, CodeQL, abhängig von Sprache und Build-Pipeline.
• Sicherheitsartefakt: Scan-Report mit Datum, Branch, Commit-Hash und Maßnahmenplan für offene Findings.

DAST (Dynamic Application Security Testing) #

DAST prüft laufende Anwendungen oder Staging-Umgebungen auf Sicherheitslücken, indem es echte Angriffe simuliert. Die Tests beobachten das Laufzeitverhalten und decken Schwächen auf, die erst während der Ausführung sichtbar werden.

• Zweck: Auffinden von Problemen wie unsichere Session-Handling, XSS oder fehlerhafte Zugriffskontrollen.
• Typische Tools: OWASP ZAP, Burp Suite, CI-Integrationen in Container- oder API-Scannern.
• Sicherheitsartefakt: Testbericht mit Ziel-URL, Testzeitraum, Schweregrad-Einstufung und Freigabe durch das Security-Team.

Verantwortlichkeitsmatrix (RACI) #

Eine Verantwortlichkeitsmatrix ordnet Aufgaben den Rollen Responsible, Accountable, Consulted und Informed zu. Sie schafft Klarheit, wer eine Aktivität ausführt, wer die Freigabe trägt und welche Stakeholder eingebunden werden.

• Nutzen: verhindert Doppelarbeit, reduziert Audit-Nachfragen und dokumentiert Governance-Strukturen.
• Erstellung: Liste der Kernaufgaben mit R/A/C/I-Spalten, gepflegt im Projekt-Wiki oder Ticket-System.
• Sicherheitsartefakt: exportierte Matrix (z. B. docs/<projekt>/raci.xlsx) mit Datum, Owner und Genehmigung.

Logging nach OWASP-Empfehlung #

Bezieht sich auf die OWASP Logging Cheat Sheet. Sie fordert strukturierte Logs mit sicherheitsrelevanten Ereignissen, aber ohne Geheimnisse oder sensible Daten. Sie fordert strukturierte Logs mit sicherheitsrelevanten Ereignissen ohne Geheimnisse oder sensible Daten.

• Mindestinhalte: Zeitstempel, Benutzer-/Session-ID, Anfragequelle, Aktion, Ergebnis, Korrelation-ID.
• Datenschutz: Keine Klartext-Passwörter, Secrets oder personenbezogene Daten; Maskierungspflichten definieren.
• Schutzmaßnahmen: Write-once Storage, Zugriffskontrolle, Monitoring durch SIEM.
• Sicherheitsartefakt: Logging-Konzept (docs/<projekt>/logging-konzept.md) plus Nachweis, dass die Umsetzung im Review geprüft wurde.

AuthN (Authentication) #

Steht für Authentifizierung, also den Nachweis der Identität eines Benutzers oder Systems. Typische Verfahren sind Passwort + MFA, Zertifikate oder OAuth/OIDC Flows. Dokumentiere AuthN-Mechanismen in den Architektur-ADRs und halte Trust-Boundaries fest.

AuthZ (Authorization) #

Steht für Autorisierung, also die Prüfung, ob eine authentifizierte Identität eine Aktion ausführen darf. Stelle sicher, dass Rollen, Rechte und Policies versioniert vorliegen und Geschäftsregeln im Code nachvollziehbar hinterlegt sind.

IaC (Infrastructure as Code) #

Beschreibt die Verwaltung von Infrastrukturressourcen (z. B. Terraform, Ansible, CloudFormation) als versionierten Code. IaC ermöglicht reproduzierbare Deployments, automatisierte Reviews und Sicherheitsprüfungen (Policy-as-Code).

OWASP ASVS Benchmark #

Die OWASP Application Security Verification Standard (ASVS) definiert Sicherheitsanforderungen für Webanwendungen auf verschiedenen Verifizierungsstufen. Nutze ihn als Benchmark, um Implementierungen zu bewerten und Sicherheitslücken systematisch zu schließen.

Risiko-Register #

Dokument, das alle bekannten Risiken mit Bewertung, Owner, Maßnahmen und Status enthält. Für ISO 27001 sollte jedes Akzeptierte oder offene Risiko mit ID, Bewertung, Behandlung (z. B. Mitigation) und Review-Datum geführt werden.

GRC-Freigabe #

Genehmigung im Governance-Risk-Compliance-System (z. B. OneTrust, ServiceNow GRC). Dient als revisionssicherer Nachweis, dass Sicherheits- oder Compliance-Entscheidungen geprüft, freigegeben und versioniert wurden.

Runbook #

Betriebs- oder Wartungshandbuch, das Schritte für Deployments, Rollbacks, Monitoring und Incident Response beschreibt. Runbooks müssen aktuell gehalten und für das Ops-Team verfügbar sein.

Rollback-Drill #

Geplanter Test, bei dem das Team ein Deployment zurückrollt und die Wiederherstellungsmaßnahmen überprüft. Ergebnis ist Protokoll + Lessons Learned, um im Ernstfall schnell reagieren zu können.

Corrective Action Log #

Ein Corrective Action Log dokumentiert Korrekturmaßnahmen für festgestellte Sicherheits- oder Compliance-Verstöße. Es enthält Datum, Befund-ID, Schweregrad, verantwortliche Person, geplante Maßnahme, Zieltermin und Nachverfolgung der Wirksamkeit. Für ISO 27001 dient das Log als Nachweis, dass Risiken behandelt und Korrekturen nachhaltig umgesetzt werden. Nutze es, wenn kritische Findings nicht im aktuellen Sprint behoben werden oder Auditoren explizit Nachweise fordern.

MobSF (Mobile Security Framework) #

MobSF ist ein Open-Source-Tool, das mobile Apps (Android, iOS) statisch und dynamisch analysiert. Es erkennt Schwachstellen wie unsichere Berechtigungen, Plaintext-Kommunikation oder hartkodierte Secrets. Das Tool eignet sich, den DAST-Prozess für Mobile Apps zu ergänzen, indem es APK/IPA-Dateien scannt und Reports für Audits bereitstellt.

Eskalationsmatrix #

Definiert, welche Rollen bei Sicherheitsvorfällen oder offenen Risiken informiert werden und in welcher Reihenfolge (Hersteller, Security Champion, CISO, Kundenkontakt). Dokumentiert Kommunikationswege, Zeitfenster und Ersatzrollen, um schnelle Entscheidungen zu gewährleisten.