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.
Modul: Transfer in typische Anwendungsszenarien
Dieses Thema als Schulung für Ihr Team
Dieser Beitrag erklärt das Thema. Damit Ihr Team es danach auch anwendet, gibt es Security by Design in der Softwareentwicklung - Sicherheitsprinzipien, Threat Modeling und sichere Architekturentscheidungen als Schulung — an Ihrem eigenen Code, mit den Fragen, die ein Text nicht beantwortet. Sie wählen die Module, wir bauen daraus ein Programm.
3 Tage·ab 900 EUR netto pro Tag (bis 3 Teilnehmende) ·Termin nach Vereinbarung
Als Team-Schulung anfragenZum Seminar Security by Design in der Softwareentwicklung - Sicherheitsprinzipien, Threat Modeling und sichere Architekturentscheidungen →