Der Spickzettel zum Seminar Security by Design in der Softwareentwicklung — für den Entwurfstermin, das Review oder das Threat-Modeling-Meeting, in dem man kurz nachsieht, wie STRIDE noch mal ging. Zum Lernen der Methode taugt er nicht; dafür ist das Seminar da. Jeder Abschnitt verweist auf das Modul, aus dem er stammt.
Die drei Ebenen
Security by Design ist weder Secure Coding noch Security-Testing. Die Ebenen beantworten verschiedene Fragen zu verschiedenen Zeitpunkten.
| Ebene | Frage | Zeitpunkt |
|---|---|---|
| Security by Design | Ist es sicher gebaut? | Entwurf |
| Secure Coding | Ist es sicher umgesetzt? | Implementierung |
| Security-Tests | Ist es sicher geblieben? | Test & Betrieb |
Keine Ebene ersetzt eine andere — sie greifen ineinander.
Kosten einer Lücke nach Phase
| Gefunden in Phase | Relativer Korrekturaufwand |
|---|---|
| Anforderung / Entwurf | niedrig — Entscheidung ändern |
| Implementierung | mittel — Code anpassen |
| Test / Abnahme | hoch — Rückbau nötig |
| Produktion / Vorfall | sehr hoch — plus Schaden |
Modul: Security by Design verstehen
Schutzziele und Angreifer
CIA — Schutzbedarf je Asset
Schutzbedarf wird je Asset getrennt nach C, I und A eingeschätzt, nicht pauschal.
| Schutzziel | Bedeutung | Beispiel-Verlust |
|---|---|---|
| Vertraulichkeit | Nur Befugte sehen Daten | Kundendaten geleakt |
| Integrität | Daten sind unverfälscht | Rechnung manipuliert |
| Verfügbarkeit | System ist erreichbar | Shop fällt aus |
Typische Angreifer
Die Angreiferstärke bestimmt die nötige Tiefe der Verteidigung.
| Typ | Motiv | Typische Fähigkeit |
|---|---|---|
| Gelegenheitstäter | Neugier, Zufall | Bekannte Exploits |
| Organisiert / Kriminell | Geld | Gezielte Kampagnen |
| Innentäter | Rache, Vorteil | Legitime Zugänge |
Use Case gegen Abuse Case
Jeder Abuse Case erzeugt eine konkrete Gegenmaßnahme.
| Use Case | Abuse Case |
|---|---|
| Nutzer meldet sich an | Angreifer probiert Passwörter durch |
| Nutzer lädt Datei hoch | Angreifer lädt Schadcode hoch |
| Nutzer setzt Passwort zurück | Angreifer übernimmt fremdes Konto |
Modul: Sicherheitsverantwortung im Entwicklungsprozess
Threat Modeling
STRIDE-Kategorien
Je Element und Datenfluss alle sechs Kategorien durchgehen.
| Kategorie | Bedrohung | Schutzziel |
|---|---|---|
| Spoofing | Identität fälschen | Authentizität |
| Tampering | Daten verändern | Integrität |
| Repudiation | Aktion leugnen | Nachweisbarkeit |
| Information Disclosure | Daten abgreifen | Vertraulichkeit |
| Denial of Service | Dienst lahmlegen | Verfügbarkeit |
| Elevation of Privilege | Rechte ausweiten | Autorisierung |
Elemente der Angriffsfläche
Was nicht existiert, kann nicht angegriffen werden.
| Element | Frage zur Reduktion |
|---|---|
| Öffentliche Endpunkte | Wird jeder wirklich gebraucht? |
| Eingabefelder / Uploads | Alles serverseitig validiert? |
| Offene Ports / Dienste | Nach außen wirklich nötig? |
| Abhängigkeiten | Aktuell und minimal gehalten? |
Risiko einordnen
Kritische Risiken zuerst; bewusst akzeptierte Restrisiken dokumentieren.
| Auswirkung ╲ Wahrscheinlichkeit | gering | hoch |
|---|---|---|
| gering | niedrig | mittel |
| hoch | mittel | kritisch |
Modul: Threat Modeling als praktische Methode
Die sieben Prinzipien
Kein Prinzip steht für sich — sie verstärken einander.
| Prinzip | Kerngedanke |
|---|---|
| Least Privilege | Nur so viele Rechte wie nötig |
| Defense in Depth | Mehrere Schutzschichten staffeln |
| Secure Defaults | Sicher im Auslieferungszustand |
| Fail Secure | Im Fehlerfall verweigern |
| Separation of Duties | Kritisches auf mehrere verteilen |
| Angriffsfläche minimieren | Weniger Angriffspunkte bieten |
| Sichere Vertrauensgrenzen | Vertrauen bewusst und explizit |
Modul: Prinzipien sicherer Softwarearchitektur
Security-Aktivitäten je SDLC-Phase
Kein Übergang ohne bewusste Sicherheitsaktivität.
| Phase | Security-Aktivität |
|---|---|
| Anforderung | Schutzbedarf, Security Requirements |
| Entwurf | Threat Modeling, Prinzipien anwenden |
| Implementierung | Secure Coding, Code Reviews |
| Test | SAST/DAST, Pentest |
| Release | Härtung, Secrets, SBOM |
| Betrieb | Monitoring, Patchen, Incident Response |
Modul: Security im Software Development Lifecycle
Bedrohung und Gegenmaßnahme nach Anwendungstyp
| Kontext | Bedrohung | Gegenmaßnahme |
|---|---|---|
| Desktop | Manipulierte Update-Dateien | Signierte Updates prüfen |
| Desktop | Lokale Daten im Klartext | Verschlüsselt speichern |
| Desktop | Library-/DLL-Hijacking | Feste Pfade, Signaturen prüfen |
| Desktop | Secrets im Client eingebettet | Keine Geheimnisse im Client |
| Web / API | Injection (SQL, Command) | Parametrisieren, validieren |
| Web / API | Broken Auth / Session | Starke Auth, sichere Tokens |
| Web / API | Fehlende Zugriffskontrolle | Serverseitig autorisieren |
| Web / API | Übermäßige Datenpreisgabe | Antworten gezielt minimieren |
| Backend | Ungeprüfte Service-Aufrufe | mTLS, Service-Identität |
| Backend | Secrets in Config oder Code | Secret-Management, Rotation |
| Backend | Kompromittierte Dritt-API | Empfangene Daten misstrauen |
| Backend | Fehlende Ratenbegrenzung | Rate Limiting, Timeouts |
Drei Faustregeln dazu: Vertrauenswürdige Entscheidungen gehören auf den Server. Nie dem Client vertrauen — jede Prüfung serverseitig wiederholen. Und: „Internes Netz” ist keine Vertrauensgrenze.