Dieser Abschnitt ist einer der umfangreichsten in der vierten Domain. Hier werden wir eine ganze Reihe von Frameworks, Methoden und Akronymen kennenlernen, die von der Bedrohungsmodellierung bis zu sicheren Programmierpraktiken reichen.
Cloud-spezifische Risiken
Cloud-spezifische Risiken umfassen eine breite Palette möglicher Bedrohungen, darunter technologische, regulatorische und rechtliche. Vieles davon wurde bereits in den Abschnitten 1.3 und 3.3 ausführlich behandelt. Aus CCSP-Sicht ist die CSA Egregious 11 nach wie vor die wichtigste Referenz, obwohl sie aus dem Jahr 2019 stammt und seitdem nicht aktualisiert wurde. Ihre Grundsätze sind weiterhin gültig, da sich die beschriebenen Bedrohungen seither nicht grundlegend verändert haben.
Nach der Registrierung kann das Originaldokument „Top Threats to Cloud Computing: The Egregious 11” heruntergeladen werden: Top Threats und Deep-Dive dazu.
CSA Egregious 11 – Top-Bedrohungen in Cloud-Umgebungen
Die Egregious 11 ist ein guter Beweis dafür, dass die meisten Cloud-Sicherheitsprobleme nicht in der Cloud selbst entstehen, sondern in ihren Fehlkonfigurationen, schlechter Planung oder unklaren Verantwortlichkeiten.
1. Data Breaches (Datenleck) – unbefugter Zugriff auf sensible Daten, verursacht durch Fehlkonfigurationen, schwache Verschlüsselung oder gezielte Angriffe.
2. Misconfiguration and Inadequate Change Control (Fehlkonfiguration) – falsch konfigurierte Cloud-Ressourcen sind die häufigste Ursache von Datenpannen. Dies liegt meist an fehlenden Zugriffskontrollen oder unveränderten Standardeinstellungen.
3. Lack of Cloud Security Architecture and Strategy (fehlende Sicherheitsarchitektur) – viele Organisationen migrieren in die Cloud ohne angepasste Sicherheitsstrategie, was zu erheblichen Angriffsflächen führen kann.
4. Insufficient Identity, Credential, Access and Key Management (unzureichendes IAM) – schwache Passwörter, fehlende Multi-Faktor-Authentifizierung (MFA) oder hardcodierte Credentials ermöglichen unbefugten Zugriff auf Cloud-Ressourcen.
5. Account Hijacking (Kontoübernahme) – Angreifer übernehmen privilegierte Cloud-Konten durch Phishing, Credential Stuffing oder gestohlene Zugangsdaten.
6. Insider Threat (Insider-Bedrohung) – Mitarbeitende oder externe Auftragnehmer (Interne Akteure) mit legitimem Zugriff verursachen absichtlich oder fahrlässig Sicherheitsvorfälle.
7. Insecure Interfaces and APIs (unsichere APIs) – schlecht gesicherte Schnittstellen sind als einzige öffentlich erreichbare Komponenten eines Systems ein bevorzugtes Angriffsziel.
8. Weak Control Plane (schwache Verwaltungsebene) – unzureichende Kontrolle über die Management Plane führt dazu, dass Administratoren keinen vollständigen Überblick über Konfigurationen und Datenflüsse haben.
9. Metastructure and Applistructure Failures (Infrastruktur-Schwachstellen) – Sicherheitslücken an der Grenze zwischen CSP und Kunde, z. B. durch fehlerhafte API-Implementierungen oder unsichere Cloud-Anwendungsarchitekturen.
10. Limited Cloud Usage Visibility (eingeschränkte Sichtbarkeit) – fehlende Transparenz über genutzte Cloud-Dienste ermöglicht Shadow IT. Solche Systeme werden weder überwacht noch gepatcht.
11. Abuse and Nefarious Use of Cloud Services (Missbrauch von Cloud-Diensten) – Angreifer nutzen Cloud-Ressourcen für DDoS-Angriffe, Cryptocurrency-Mining oder die Verbreitung von Malware.
Bedrohungsmodellierung (Threat Modeling)
Die Bedrohungsmodellierung in unserem Kontext, sind die vier bereits existierenden Modelle, die helfen können, potenzielle Bedrohungen zu identifizieren, zu bewerten und zu priorisieren und auf Basis der gewonnenen Informationen die geeigneten Gegenmaßnahmen zu entwickeln.
STRIDE
STRIDE ist das erste Akronym in unserer Reihe. Das von Microsoft entwickelte Modell verteilt Bedrohungen in sechs Kategorien – auf deren Basis konkrete Gegenmaßnahmen definiert werden können.
S – Spoofing (Identitätsfälschung) – illegaler Zugriff auf fremde Infrastruktur mithilfe gestohlener Identitäten oder Anmeldedaten. Gegenmaßnahmen: MFA, Zertifikate, Tokens.
T – Tampering (Manipulation) – böswillige Veränderung von Daten, Konfigurationen oder Software, sowohl bei der Übertragung als auch bei der Speicherung. Gegenmaßnahmen: Signaturen, Hash-Überprüfung, Integritätsüberwachung.
R – Repudiation (Abstreitbarkeit) – ein Benutzer bestreitet, eine bestimmte Aktion durchgeführt zu haben. Gegenmaßnahmen: Audit-Logs, Non-Repudiation-Mechanismen.
I – Information Disclosure (Datenoffenlegung) – vertrauliche Informationen werden unautorisiert offengelegt. Gegenmaßnahmen: Verschlüsselung, Zugriffskontrollen, Datenmaskierung, DLP-Systeme.
D – Denial of Service (DoS) – durch Überlastung werden Systeme beschädigt oder unzugänglich gemacht. Gegenmaßnahmen: Rate Limiting, Redundanz, DDoS-Schutz, Auto-Scaling.
E – Elevation of Privilege (Rechteerweiterung) – ein unprivilegierter Benutzer verschafft sich Rechte, die für ihn nicht vorgesehen sind. Gegenmaßnahmen: Least Privilege, RBAC, regelmäßige Zugriffsüberprüfungen.
DREAD
DREAD ist das zweite Bewertungsmodell in unserer Reihe und wurde ebenfalls von Microsoft entwickelt. Im Gegensatz zu STRIDE, das Bedrohungen kategorisiert, dient DREAD der Bewertung und Priorisierung dieser Bedrohungen anhand von fünf Kriterien. Typischerweise auf einer Skala von 1 bis 10. Der Gesamtwert ergibt sich aus dem Durchschnitt aller fünf Werte. DREAD ist zwar als Begriff noch für die CCSP-Prüfung (auch für CompTIA CySA+) relevant, hat im realen Leben keine Bedeutung mehr.
D – Damage (Schadensausmaß) – wie groß ist der potenzielle Schaden bei einem erfolgreichen Angriff?
R – Reproducibility (Reproduzierbarkeit) – wie einfach lässt sich der Angriff wiederholen?
E – Exploitability (Ausnutzbarkeit) – wie einfach (Aufwand + Fachwissen) wäre die Schwachstelle auszunutzen?
A – Affected Users (Betroffene Benutzer) – wie viele und welche Benutzer sind betroffen?
D – Discoverability (Auffindbarkeit) – wie leicht lässt sich die Schwachstelle entdecken?
ATASM
Das letzte Akronym in der unteren Reihe wird Brook Schoenfield zugeschrieben und sollte in seinem Buch „Securing Systems“ (2015) vorgestellt sein. Im Gegensatz zu STRIDE und DREAD ist ATASM ein vollständiger Threat-Modeling-Prozess, welcher von der Architekturanalyse bis zur konkreten Maßnahmendefinition reicht.
A – Architecture (Architektur) – zunächst muss die Systemarchitektur vollständig verstanden werden, u. a. Komponenten, Datenflüsse, Vertrauensgrenzen, schützenswerte Assets, bestehende Abhängigkeiten und Sicherheitskontrollen.
T – Threats (Bedrohungen) – auf Basis der Architektur werden relevante Bedrohungsakteure und deren typische Angriffsmethoden identifiziert.
A – Attack Surfaces (Angriffsflächen) – an diesem Schritt wird die Architektur in ihre Einzelteile zerlegt, um alle potenziellen Einstiegspunkte und Ausgangspunkte des Angreifers zu identifizieren.
M – Mitigations (Gegenmaßnahmen) – für jede unzureichend geschützte Angriffsfläche werden konkrete Sicherheitsmaßnahmen definiert, die anschließend zu implementieren sind. Und die implementierte Mitigation- Maßnahme haben eine direkte Auswirkung auf die Architektur.
PASTA
Analog zu ATASM wurde PASTA ebenfalls in dem Buch „Risk Centric Threat Modeling” (2015) von Tony UcedaVelez und Marco Morana vorgestellt.
Während STRIDE und DREAD Bedrohungen auf technischer Ebene kategorisieren und bewerten, und ATASM einen strukturierten Analyseprozess beschreibt, geht PASTA noch einen Schritt weiter. PASTA bewertet bei Bedrohungen sowohl technische Risiken als auch geschäftliche Auswirkungen. Dies erfolgt in einem iterativen, siebenstufigen Prozess.
Die sieben Phasen:
1. Define Objectives (Definition der Ziele) – Hier wird die Frage beantwortet, welche Geschäftsprozesse und Daten besonders schützenswert sind.
2. Define Technical Scope (Definition des technischen Umfangs) – In dieser Phase wird festgelegt, welche technischen Komponenten, Systeme und Abhängigkeiten geschützt werden müssen.
3. Application Decomposition & Analysis (Anwendung zerlegen) – Die Anwendung wird in ihre logischen Einzelteile zerlegt, z. B. Datenflüsse, Vertrauensgrenzen (Trust Boundaries), Assets oder Einstiegspunkte. Man muss genau wissen, welche Daten durch das System fließen und welche Stellen vertrauenswürdig sind und welche nicht.
4. Threat Analysis (Bedrohungsanalyse) – Hier findet die Identifikation relevanter Bedrohungsakteure und ihrer Angriffsvektoren statt.
5. Weakness & Vulnerability Analysis (Schwachstellenanalyse) – Es werden gezielt Schwachstellen bzw. Sicherheitslücken in der Architektur (und im Code) gesucht, die von den zuvor identifizierten Bedrohungsakteuren ausgenutzt werden könnten.
6. Attack Modeling & Simulation (Angriffssimulation) – Die möglichen Angriffsszenarien werden simuliert, um theoretisch oder praktisch zu prüfen, ob die gefundenen Lücken tatsächlich ausnutzbar sind.
7. Risk & Impact Analysis – Am Ende werden auf Basis der Angriffssimulation die Risiken bewertet und konkrete Maßnahmen zur Risikominderung definiert, die auch die Kosten berücksichtigen.
Secure Coding
Es ist für mich wirklich schwierig, über praktische Programmierung zu schreiben, wenn man selbst kein Entwickler ist. Aber alle folgenden Punkte sind Bestandteile einer Defense-in-Depth-Strategie.
Der erste Schritt ist immer Training und Sensibilisierung der Entwickler. Wer die häufigsten Schwachstellen und sicheren Programmierpraktiken kennt, wird sie hoffentlich auch in der täglichen Arbeit berücksichtigen.
Der nächste Schritt ist die Etablierung eines SSDLC, um Sicherheit in jede Phase der Softwareentwicklung zu integrieren. Das haben wir bereits in Abschnitt 4.2 ausführlich behandelt.
Erwähnenswert ist in diesem Kontext auch Test-Driven Development (TDD): Normalerweise schreiben Entwickler zunächst den Code und testen anschließend, ob er funktioniert. Bei TDD wird der Spieß umgedreht – der Test wird geschrieben, bevor die eigentliche Funktion existiert. Das zwingt Entwickler, von Anfang an klare und testbare Anforderungen zu definieren.
Folgende Frameworks liefern praxisorientierte Empfehlungen für sicheres Programmieren:
OWASP ASVS (Application Security Verification Standard) – ein detaillierter Katalog von Sicherheitsanforderungen für Webanwendungen, unterteilt in drei Verifikationsstufen je nach Schutzbedarf. Er dient sowohl als Entwicklungsleitfaden als auch als Grundlage für Sicherheitstests.
SAFECode (Software Assurance Forum for Excellence in Code) – ein industriegetriebenes Framework mit konkreten Empfehlungen für sichere Softwareentwicklungspraktiken, von der Anforderungserhebung bis zum Deployment.
OWASP Top 10 / CWE Top 25 – die wichtigsten Referenzlisten für häufige Schwachstellen, die Entwickler kennen und aktiv vermeiden sollten.
Grundprinzipien des sicheren Programmierens
Eingabenvalidierung – alle Eingaben sollten als potenziell gefährlich betrachtet und vor der Verarbeitung geprüft werden.
Keine Hardcoded Credentials – Passwörter, API-Keys oder Zertifikate gehören nicht in den Quellcode.
Begrenzung der Rechte – Code und Anwendungen sollten nur mit den minimal notwendigen Berechtigungen ausgeführt werden (Least Privilege).
Sichere Fehlerbehandlung – Es dürfen keine internen Systeminformationen in Fehlermeldungen preisgegeben werden.
Schutz sensibler Daten – kryptografische Verfahren müssen standardisiert und korrekt angewendet werden.
Regelmäßige Code-Reviews und Security-Scans – manuelle und automatisierte Überprüfung des Codes auf Schwachstellen.
Automatisierte Sicherheitstests – Dependency Scanning, Secret Detection und SAST/DAST sollten in den Entwicklungsprozess integriert werden.
Sicherheit in CI/CD-Pipelines – Sicherheitsprüfungen laufen bei jedem Code-Commit automatisiert.
Softwarekonfiguration und Versionsverwaltung
Wenn vom Software Configuration Management (SCM) inklusive Versionsverwaltung die Rede ist, werden gleichzeitig zwei Ebenen behandelt: die Methodologie (das „Wie“) und die technischen Hilfsmittel (das „Womit“).
Das SCM kümmert sich im Kern um folgende Punkte:
Code-Integrität – alle Änderungen werden nachvollziehbar protokolliert (Change Tracking). Bei Bedarf findet das Vier-Augen-Prinzip Anwendung, z. B. bei Änderungen an der Main Branch.
Auditing und Compliance bieten die Möglichkeit, Änderungen bis auf Zeilenebene im Code zurückzuverfolgen: Wer hat wann was geändert?
Baseline-Management bedeutet, einen stabilen und sicheren Zustand des Codes zu definieren. Zukünftige Änderungen werden gegen diese Baseline gemessen und im Fehlerfall kann auf sie zurückgegriffen werden.
Die folgenden Punkte sind zwar ebenfalls Teil des SCM-Konzepts, werden aber primär durch Tools umgesetzt:
Teamkoordination – mehrere Entwickler können gleichzeitig am gleichen Projekt arbeiten, ohne sich gegenseitig zu stören.
Versionskontrolle – mehrerer Codeversionen können gleichzeitig, voneinander unabhängig arbeiten, die Änderungen zusammenführen und falls es zum Problemen kommt, auch einen Rollback durchführen.
Bekannte SCM-Tools sind z. B. Git, GitHub, GitLab oder Bitbucket, wobei Git heute de facto der Standard ist.