Proaktive Sicherheit durch Threat Modeling

1,360 views
1,172 views

Published on

Eine Einführung ins Threat Modeling

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,360
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • OK
  • Proaktive Sicherheit durch Threat Modeling

    1. 1. Proaktive Sicherheit durch Threat Modeling TÜV Rheinland Secure iT GmbH Philippe A. R. Schaeffer Chief Security Analyst
    2. 2. Wegbegleiter TÜV Rheinland Secure iT Tochtergesellschaft der TÜV Rheinland Group <ul><ul><li>TÜV Rheinland Group: in 68 Ländern an 350 Standorten präsent, 12.500 Mitarbeiter und 1 Mrd. Umsatz in 2007 </li></ul></ul><ul><ul><li>Der unabhängige, neutrale Partner für IT-Security , IT-Prozesse und IT-Qualität im deutschen Markt </li></ul></ul><ul><ul><li>An 6 Standorten deutschlandweit mit ca. 100 IT-Experten </li></ul></ul><ul><ul><li>Wir versetzen unsere Kunden in die Lage, die Chancen der IT optimal zu nutzen und dabei Risiken in Bezug auf Sicherheit und Qualität zu identifizieren und zu vermeiden. </li></ul></ul><ul><ul><li>Durch neutrale Analysen, Tests und Konzepte unterstützen wir Unternehmen, ihre informationstechno- logische Infrastruktur, Prozesse und Produkte zu optimieren. </li></ul></ul><ul><ul><li>Dabei nutzen und entwickeln wir Standards . </li></ul></ul>Hamburg Hannover Berlin Köln Saarbrücken Stuttgart Standorte TÜV Secure iT GmbH Standorte TÜV Rheinland Group
    3. 3. Das Technik-Team. <ul><li>10 hauptberufliche Hacker aus verschiedenen Bereichen </li></ul><ul><ul><ul><li>ISO 27001 Auditoren </li></ul></ul></ul><ul><ul><ul><li>ITIL Foundation Manager </li></ul></ul></ul><ul><ul><li>Sicherheitsanalysen von Anlagen, Systemen, Netzwerken und Software </li></ul></ul><ul><ul><li>Erstellung und Prüfung von IT-Security-Strategien und Konzepten. </li></ul></ul><ul><ul><li>Externe und Interne Penetrationstests. </li></ul></ul><ul><ul><li>Gutachten im Bereich Netzwerke, Hochverfügbarkeit, IT-Security. </li></ul></ul><ul><ul><li>Beratung und Schulung im IT-Security-Umfeld. </li></ul></ul><ul><ul><li>Quelltextanalysen (Code Review) </li></ul></ul><ul><ul><li>Binäranalysen (Reverse Engineering) </li></ul></ul><ul><ul><li>Proof-of-Concept-Erstellung </li></ul></ul><ul><ul><li>etc … </li></ul></ul>
    4. 4. Wozu IT-Sicherheit? <ul><li>Informationen sind Unternehmenswerte </li></ul><ul><li>Zunehmende Komplexität </li></ul><ul><li>Immer stärkere Vernetzung und Interaktion </li></ul><ul><ul><li>Stetig wachsende Abhängigkeit von der IT </li></ul></ul><ul><li>Gesetzliche Anforderungen (PCI DSS, Geheimschutz, ...) </li></ul><ul><ul><li>IT-Sicherheit schafft Arbeitsplätze </li></ul></ul><ul><ul><li>bzw. erhält meinen </li></ul></ul>
    5. 5. Traditioneller Ansatz Sicherheit Schaffen <ul><li>Sicherheit ist ein Netzwerkthema => „Border Security“ </li></ul><ul><ul><ul><li>Firewall </li></ul></ul></ul><ul><ul><ul><li>Web Application Firewall </li></ul></ul></ul><ul><ul><ul><li>Intrusion Detection/Prevention System </li></ul></ul></ul><ul><li>Schutz gegen Protokoll-Anomalien </li></ul><ul><li>Nutzlos gegen Sicherheitslücken auf Architekturebene </li></ul>
    6. 6. Traditioneller Ansatz Sicherheit Prüfen <ul><li>Penetrationstest & Code Review </li></ul><ul><ul><ul><ul><li>Findet nach der Implementierung statt - reaktiv </li></ul></ul></ul></ul><ul><ul><ul><li>Zeitintensiv </li></ul></ul></ul><ul><ul><ul><li>Betrachtet Designfehler nur bedingt </li></ul></ul></ul><ul><ul><ul><ul><li>Vernachlässigt die Interaktion von Applikationen </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Geltungsbereich für Code Review schwierig zu spezifizieren </li></ul></ul></ul></ul>
    7. 7. Traditioneller Ansatz - Beispiel Firewall IDS DMZ IPS Markthalle $$$$
    8. 8. Philosophie <ul><li>Wenn du den Feind und dich selbst kennst, brauchst du den Ausgang von hundert Schlachten nicht zu fürchten … </li></ul><ul><li>Wenn du weder den Feind noch dich selbst kennst, wirst du in jeder Schlacht unterliegen. </li></ul><ul><li>Sun Tzu, ca. 500 v.Chr. </li></ul>
    9. 9. Traditioneller Application Life Cycle
    10. 10. Proaktive Sicherheit durch Threat Modeling Secure Software Development Lifecycle (SSDL) <ul><ul><li>Methodischer Ansatz zum Erkennen von Sicherheitslücken </li></ul></ul><ul><ul><li>In den Entwicklungsprozess eingebettet </li></ul></ul><ul><ul><li>Risiken werden vor der Implementierung erkannt </li></ul></ul><ul><ul><li>Analyse komplexer Architekturen möglich </li></ul></ul><ul><ul><li>Grundlage für reaktive Untersuchungen </li></ul></ul>
    11. 11. Beteiligung am Threat Modeling <ul><li>Management oder Marketing </li></ul><ul><ul><ul><li>Management-Awareness </li></ul></ul></ul><ul><ul><li>Leitende(r) Entwickler/Architekt </li></ul></ul><ul><ul><ul><li>Entscheidungskompetenz und -befugnis </li></ul></ul></ul><ul><ul><li>QA-Abteilung </li></ul></ul><ul><ul><ul><li>Sicherheitslücken sind Fehler mit besonderer Wirkung </li></ul></ul></ul><ul><ul><li>Security-Experte </li></ul></ul><ul><ul><ul><li>Sicht des Angreifers </li></ul></ul></ul><ul><ul><ul><li>Vermeiden von Betriebsblindheit </li></ul></ul></ul>
    12. 12. Vorgehensweise <ul><li>Analyse von Software und IT-Infrastruktur </li></ul><ul><li>Identifikation möglicher Angriffsziele </li></ul><ul><li>Bewertung und Priorisierung der Schwachstellen </li></ul><ul><li>Ableitung von Maßnahmen </li></ul>
    13. 13. Analyse von Software und IT-Infrastruktur Datenfluss – Ebene 1
    14. 14. Analyse von Software und IT-Infrastruktur Datenfluss – Ebene 2
    15. 15. Identifikation möglicher Angriffsziele Entry Points <ul><li>CMS-Administrator </li></ul><ul><li>Redakteur </li></ul><ul><li>Dateitransfer </li></ul><ul><li>anonymer Benutzer </li></ul><ul><li>CMS-Administrator </li></ul><ul><li>Redakteur </li></ul><ul><li>Stored Procedure XY </li></ul><ul><li>anonymer Benutzer </li></ul><ul><li>Suchmaske </li></ul><ul><li>Redakteur </li></ul><ul><li>CMS-Administrator </li></ul><ul><li>Login-Seite </li></ul><ul><li>anonymer Benutzer </li></ul><ul><li>Redakteur </li></ul><ul><li>Portalseite </li></ul>
    16. 16. Identifikation möglicher Angriffsziele STRIDE <ul><li>S poofing Identity </li></ul><ul><li>T ampering with data </li></ul><ul><li>R epudiation </li></ul><ul><li>I nformation disclosure </li></ul><ul><li>D enial of service </li></ul><ul><li>E levation of privilege </li></ul>= Vortäuschen einer falschen Identität = Manipulation von Daten = Abstreitbarkeit = Preisgabe von Daten = Störung der Verfügbarkeit = Ausweiten von Berechtigungen
    17. 17. Identifikation möglicher Angriffsziele Exemplarische Bedrohungen <ul><li>SQL-Injection </li></ul><ul><li>Brute-Force auf Login-Seite </li></ul><ul><li>XSS </li></ul><ul><li>Fehlermeldungen </li></ul><ul><li>Privilege escalation </li></ul><ul><li>etc. </li></ul>
    18. 18. Angriffsbaum
    19. 19. Bewertung und Priorisierung der Schwachstellen Bedrohungen priorisieren mit DREAD <ul><li>D amage Potential </li></ul><ul><li>R eproducibility </li></ul><ul><li>E xploitability </li></ul><ul><li>A ffected Users </li></ul><ul><li>D iscoverability </li></ul>. . . . . . etc. 30 2 9 8 3 8 Privilege escalation 20 8 1 5 5 1 Fehlermeldungen 35 8 5 4 10 8 Sniffen FTP 50 10 10 10 10 10 SQL-Injection Summe D A E R D Bedrohung
    20. 20. Ableitung von Maßnahmen
    21. 21. Beispiel einer Bedrohungsanalyse nach Threat Modeling Ansatz
    22. 22. Vorteile <ul><li>Tiefes Verständnis der Applikation / des Systems </li></ul><ul><li>Erkennen von (Design)-Fehlern </li></ul><ul><li>Erkennen von Fehlern vor der Implementierung (Kostenfaktor) </li></ul><ul><li>Strukturierte und priorisierte Liste von Bedrohungen </li></ul><ul><li>Grundlage für reaktive Tests (Pentest, Code Review) </li></ul><ul><li>Sicherheit wird Bestandteil des Entwicklungsprozesses (SSDL) </li></ul>
    23. 23. Wie können wir Sie unterstützen? <ul><li>Fundierte Kenntnisse und Erfahrungen im Bereich IT-Security </li></ul><ul><li>Prozess-/Service-orientierte Sicht der Angreifers </li></ul><ul><li>Moderation </li></ul><ul><li>Programmier-Workshops </li></ul><ul><li>Secure Software Development Lifecycle (SSDL) </li></ul><ul><li>Compliance (PCI DSS, Geheimschutz, …) </li></ul>
    24. 24. Philippe A. R. Schaeffer TÜV Rheinland Secure iT GmbH Chief Security Analyst Tel. +49 221 806 2485 Email [email_address] Vielen Dank für Ihre Aufmerksamkeit! Haben Sie Fragen?

    ×