Wie viel Softwaresicherheit ist genug?

665 views
522 views

Published on

Wie kann ich Software Security messbar machen

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

No Downloads
Views
Total views
665
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
6
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Wie viel Softwaresicherheit ist genug?

  1. 1. Wie viel Software-Sicherheit ist genug? 27.03.2014
  2. 2. “America has no […] friends or enemies, only interests” (H. Kissinger)
  3. 3. Was macht Software so gefährlich? • Komplex • Man kann sie oft nicht „abdrehen“ • Oft nicht im Fokus – Extra „Schicht“ über der Infrastruktur • Oft organisatorisch getrennt – Entwicklung vs. Betrieb • Fehlende Kontrolle – Outsourcing
  4. 4. Bill Gates’ “berühmtes” Email
  5. 5. Kategorisierungsansatz Automatisierte Bedrohungen Ziele: Zugangspunkte Beispiele: Botnetze Spam Eigenschaften:  Weder gezielt noch persistent Zielgruppen:  Jede Person, kleine, mittlere und große Organisationen Wirtschafts- spionage Ziele: Wirtschaftliche Vorteile Beispiele: Advanced Persistent Threat Eigenschaften:  Gezielt  Persistent Zielgruppen:  Jede Industrie, v.a. die Top Unternehmen jeder Branche Organisierte Kriminalität Ziele: Finanzieller Profit Beispiele: Kreditkartenklau Eigenschaften:  Gezielt  Persistent Zielgruppen:  Organisationen die Zahlungsdaten verarbeiten oder speichern Hacktivismus Ziele: Diffamierung & Publicity Beispiele: Anonymous LulzSec Eigenschaften:  Gezielt Zielgruppen:  Jede Organisation
  6. 6. Blackhole Administration Panel Anzahl infizierter PCs Erfolgsquote Angewandte Exploits
  7. 7. Software Sicherheit: Der traditionelle Ansatz • Periodische Security Tests: – Oft nach dem Deployment – Bug Fixing teuer – Bug Fixing: Auswirkungsminimierung aber keine Ursachenbeseitigung – Architekturänderungen praktisch nicht möglich
  8. 8. Sicherheit in die Entwicklung! • Symptome beheben: Firewalls, IDS, Pentests • Ursachen beheben: Design & Code Audits, Secure Requirements, Coding Guidelines Planung Entwicklung Planung Entwicklung Testen Produktiv Testen Produktiv
  9. 9. Secure Development Life Cycle (SDLC) • Ansatz um Sicherheit in den Entwicklungsprozess zu integrieren. • Mehrere bekannte Modelle – Microsoft Security Development Lifecycle – Software Assurance Maturity Model (SAMM) – Building Security In Maturity Model (BSIMM)
  10. 10. Startpunkt: SDLC GAP Analyse • SOLL-IST Vergleich von Entwicklungsabteilungen • An Standard(s) orientiert • Soll verhindern dass suboptimale Prozesse eingeführt werden. • Ergebnis – Priorisierte Maßnahmenliste – Metrikenvorschlag zur Steuerung
  11. 11. GAP Analyse 1/4 Maturity Level 0 Strategy& Metrics Policy& Compliance Education& Guidance Threat Assessment Security Requirements Secure Architecture DesignReview CodeReview SecurityTesting Vulnerability Management Environment Hardening Software Environment Construction Verification Deployment Maturity Level 3 Maturity Level 2 Maturity Level 1 Governance
  12. 12. GAP Analyse 2/4 • Industrie Benchmarks (BSIMM) Maturity Level 0 Strategy& Metrics Policy& Compliance Education& Guidance Threat Assessment Security Requirements Secure Architecture DesignReview CodeReview Security Testing Vulnerability Management Environment Hardening Software Environment Governance Construction Verification Deployment Maturity Level 1 Maturity Level 2 Maturity Level 3
  13. 13. GAP Analyse 3/4 • Mein IST Stand… Maturity Level 0 Strategy& Metrics Policy& Compliance Education& Guidance Threat Assessment Security Requirements Secure Architecture DesignReview CodeReview Security Testing Vulnerability Management Environment Hardening Software Environment Governance Construction Verification Deployment Maturity Level 1 Maturity Level 2 Maturity Level 3
  14. 14. GAP Analyse 4/4 • Priorisierte Maßnahmenliste Maturity Level 0 Strategy& Metrics Policy& Compliance Education& Guidance Threat Assessment Security Requirements Secure Architecture DesignReview CodeReview Security Testing Vulnerability Management Environment Hardening Software Environment Maturity Level 1 43 Maturity Level 3 Maturity Level 2 97 61 DeploymentVerificationConstructionGovernance 5 2 8
  15. 15. Beispielhafte Maßnahmen Maßnahmengruppe Aktivität Governance Rolle eines Sicherheitsverantwortlichen definieren Einhaltung bestehender Datenschutzgesetze Secure Coding Policy (10 Gebote!) Training Construction Erstellung eines Inventars an empfohlenen Software Frameworks Erstellen und laufende Aktualisierung von Bedrohungsmodellen Verifizierung Design Review Code Review mit automatisierten Tools Deployment Informelles Security Response Team Sichere Deployment Guides für Admins (Vorlage)
  16. 16. 10 Gebote für sichere Entwicklung 1. Input- und Outputvalidierung 2. Verwendung von Prepared Statements 3. Geringstmögliche Rechte auf DB & OS 4. Passwörter gehasht speichern 5. Dynamische Ausgaben HTML escapen 6. Sichere Cookie Flags setzen 7. File Uploads einschränken (MIME, Größe) 8. Aufstellen einer Passwort Policy 9. Korrekte Fehlermeldungen 10.Korrekter Umgang mit Sessions
  17. 17. Tools? • Freie Tools – FindBugs, PNB – Threat Modelling Tools – Fuzzer • Kommerzielle Tools – Statische & dynamische Code Analyse – PenTesting Werkzeuge – Vulnerability Scanner
  18. 18. Die Frage „wieviel“ Sicherheit man braucht ist ohne Metriken nur ungenau beantwortbar
  19. 19. Sinn von Metriken • Ist meine Security besser als letztes Jahr? • Was bekomme ich für meine Security € ? • Wie stehe ich im Vergleich zum Mitbewerber? • Was sind meine Risikotransferoptionen? – Was sollte ich lieber versichern? • Integration von „Application Security“ in das ISMS!
  20. 20. Einflussfaktoren • Instabilität von Informations-Assets – Organisationen sind von Informationen abhängig die relativ einfach zerstört/verändert/… werden können • Beweisbare Sicherheit • Kostendruck • Haftung – Datenschutz, …
  21. 21. Beispiele für Geschäftsmetriken Branche Metrik Frächter • Frachtkosten pro Kilometer (Verwendete € für LKW oder Bahnfracht dividiert durch Kilometeranzahl). • Ladefaktor (Prozentuelle Auslastung der LKWs= • Leerkilometer Warenhaus • Kosten pro Quadratmeter • Lagerumschlag E-Commerce • Website-Kaufrate (Prozent eindeutiger Besucher die etwas kaufen) Kabelfernsehen • Anschlusskosten je Kunde(Kosten von Marketing, Förderungen, … dividiert durch Anzahl gewonnener Kunden) • Durchschnittlicher Umsatz pro Kunde
  22. 22. Definition einer guten Metrik • Eine Metrik ist ein konsistenter Standard um etwas zu messen. • Eine gute Metrik sollte sein… – Konsistent (nicht subjektiv) – Billig zu messen (automatisiert!) – Kardinal oder Prozentual (quantitiativ!) – 1+ Messeinheiten (Defekte, Stunden, €, …) – Kontextspezifisch • Relevant genug damit eine Entscheidung gefällt werden kann.
  23. 23. Beispiele für Software Metriken • % von Entwicklern die im letzten Jahr eine SW Security Schulung besucht haben. • % an Anwendungen bei denen ein Design Review durchgeführt wurde. • Durchschnittliche Zeit in Tagen zwischen der Entdeckung eines Bugs und der Behebung. • Anzahl an (unbehobenen) Bugs in allen Anwendungen im vergleich zur Vorperiode.
  24. 24. Beispiel für suboptimale Metriken • Vergleich Anzahl an Bugs von verschiedenen Projekten – Unterschiedliche Programmiersprachen „produzieren“ unterschiedliche Fehlerraten . – Vor allem bei automatisierter Analyse. – Projekt A 15.000 Bugs bei 100.000 Codezeilen – Projekt B 3.000 Bugs bei 100.000 Codezeilen – Welches Projekt ist sicherer?
  25. 25. Statische Code Analyse • SAST (Static Application Security Testing) • Analyse ohne die Anwendung auszuführen. • Quellcode muss vorhanden sein. • Manuell oder automatisiert. • Im Normalfall tägliche oder wöchentliche Scans • Toolentscheidung nicht trivial – Viele Faktoren – SATEC Standard als Auswahlhilfe
  26. 26. Arbeitsweise von SAST Tools Abstraktes Modell wird generiert und dieses wird analysiert void main() { int j = 0; int i = 0; while (i < 10){ if (i == 3){ j=j*2; } j = j + i; i = i + 1; } printf ("%dn", j); printf ("%d,n", i); } Enter i = 0 j = j * 2 j = 0 j = j + Ii = i + 1If (i==3) while (i<10) Printf (j) Printf (i) Regelbasierte Fehlersuche
  27. 27. Mögliches Integrationsszenario (vereinfacht) Review von Ergebnissen Sicherheits- verantwortlicher Review Results, Metrics, etc. Entwickler Zentraler Server (Web Interface) Übermittelt Scanresultate SAST Scan (Durchführung autom. über Nacht) 1 4 5 6 Revisions- kontroll- system (z.B. Git, SVN) Hole Code 2 manuell automatisiertBuild Server (z.B. Jenkins) 3
  28. 28. Beispiel für SAST Findings • Passwörter im Quellcode – Anstatt in Konfigurationsdateien • Denial-of-Service Schwachpunkte – z.B. wenn ein Kunde eine 10 GB *.pdf „hochlädt“ • Alle Vorkommen von SQL-Injection – Penetration Tests finden meist nicht alle
  29. 29. Vor- und Nachteile von SAST Tools • Gründliche Checks – Keine Vorlieben, Stärken/Schwächen oder Fähigkeiten von Entwicklern/Auditoren notwendig. • Konsistente Checks – 2 Checks ==1 Ergebnis • Zeigt echtes Problem – Nicht nur Symptome • Zeigt Fehler früher – Vor Pentests oder QA • Findet Fehler in altem Code – Neue Fehlerklassen => schreibe neue Regeln => neue Regeln anwenden => findet neue Fehlerklassen in altem Code. • Kosten – ~ 1000€ - 3000 € pro Jahr pro Entwickler
  30. 30. Zusammenfassung • Sicherheitstests vor allem als Awareness Maßnahme sehen • Sichere Softwareentwicklung einführen – Prozesse wichtig! • Start: GAP Analyse – Es gibt Leitfäden und Standards die ihnen helfen • Metriken um Sicherheit „messbar“ zu machen. – Oft unterstützt durch Tools • Integration von SW Metriken in ISMS
  31. 31. Referenzen • MS SDL – https://www.microsoft.com/security/sdl/default.aspx • OWASP Software Assurance Maturity Model – http://www.opensamm.org/ • The Building Security In Maturity Model (BSIMM) – http://bsimm.com/ • Static Analysis Technologies Evaluation Criteria (SATEC) – http://projects.webappsec.org/w/page/66094278/Static %20Analysis%20Technologies%20Evaluation%20Criteria
  32. 32. Vielen Dank für Ihre Aufmerksamkeit!

×