Wie viel Software-Sicherheit
ist genug?
27.03.2014
“America has no […] friends or
enemies, only interests” (H. Kissinger)
Was macht Software so gefährlich?
• Komplex
• Man kann sie oft nicht „abdrehen“
• Oft nicht im Fokus
– Extra „Schicht“ übe...
Bill Gates’ “berühmtes” Email
Kategorisierungsansatz
Automatisierte
Bedrohungen
Ziele:
Zugangspunkte
Beispiele:
Botnetze
Spam
Eigenschaften:
 Weder gez...
Blackhole Administration Panel
Anzahl
infizierter
PCs
Erfolgsquote
Angewandte
Exploits
Software Sicherheit: Der traditionelle Ansatz
• Periodische Security Tests:
– Oft nach dem Deployment
– Bug Fixing teuer
–...
Sicherheit in die Entwicklung!
• Symptome beheben: Firewalls, IDS, Pentests
• Ursachen beheben: Design & Code Audits,
Secu...
Secure Development Life Cycle
(SDLC)
• Ansatz um Sicherheit in den
Entwicklungsprozess zu integrieren.
• Mehrere bekannte ...
Startpunkt: SDLC GAP Analyse
• SOLL-IST Vergleich von
Entwicklungsabteilungen
• An Standard(s) orientiert
• Soll verhinder...
GAP Analyse 1/4
Maturity Level 0
Strategy&
Metrics
Policy&
Compliance
Education&
Guidance
Threat
Assessment
Security
Requi...
GAP Analyse 2/4
• Industrie Benchmarks (BSIMM)
Maturity Level 0
Strategy&
Metrics
Policy&
Compliance
Education&
Guidance
T...
GAP Analyse 3/4
• Mein IST Stand…
Maturity Level 0
Strategy&
Metrics
Policy&
Compliance
Education&
Guidance
Threat
Assessm...
GAP Analyse 4/4
• Priorisierte Maßnahmenliste
Maturity Level 0
Strategy&
Metrics
Policy&
Compliance
Education&
Guidance
Th...
Beispielhafte Maßnahmen
Maßnahmengruppe Aktivität
Governance Rolle eines Sicherheitsverantwortlichen definieren
Einhaltung...
10 Gebote für sichere Entwicklung
1. Input- und Outputvalidierung
2. Verwendung von Prepared Statements
3. Geringstmöglich...
Tools?
• Freie Tools
– FindBugs, PNB
– Threat Modelling Tools
– Fuzzer
• Kommerzielle Tools
– Statische & dynamische Code ...
Die Frage „wieviel“ Sicherheit
man braucht ist ohne Metriken
nur ungenau beantwortbar
Sinn von Metriken
• Ist meine Security besser als letztes Jahr?
• Was bekomme ich für meine Security € ?
• Wie stehe ich i...
Einflussfaktoren
• Instabilität von Informations-Assets
– Organisationen sind von Informationen
abhängig die relativ einfa...
Beispiele für Geschäftsmetriken
Branche Metrik
Frächter • Frachtkosten pro Kilometer (Verwendete € für LKW oder
Bahnfracht...
Definition einer guten Metrik
• Eine Metrik ist ein konsistenter Standard um
etwas zu messen.
• Eine gute Metrik sollte se...
Beispiele für Software Metriken
• % von Entwicklern die im letzten Jahr eine
SW Security Schulung besucht haben.
• % an An...
Beispiel für suboptimale Metriken
• Vergleich Anzahl an Bugs von verschiedenen
Projekten
– Unterschiedliche Programmierspr...
Statische Code Analyse
• SAST (Static Application Security Testing)
• Analyse ohne die Anwendung auszuführen.
• Quellcode ...
Arbeitsweise von SAST Tools
Abstraktes Modell wird generiert und dieses wird analysiert
void main()
{
int j = 0;
int i = 0...
Mögliches Integrationsszenario
(vereinfacht)
Review von Ergebnissen
Sicherheits-
verantwortlicher
Review Results,
Metrics,...
Beispiel für SAST Findings
• Passwörter im Quellcode
– Anstatt in Konfigurationsdateien
• Denial-of-Service Schwachpunkte
...
Vor- und Nachteile von SAST Tools
• Gründliche Checks
– Keine Vorlieben, Stärken/Schwächen oder Fähigkeiten von
Entwickler...
Zusammenfassung
• Sicherheitstests vor allem als Awareness
Maßnahme sehen
• Sichere Softwareentwicklung einführen
– Prozes...
Referenzen
• MS SDL
– https://www.microsoft.com/security/sdl/default.aspx
• OWASP Software Assurance Maturity Model
– http...
Vielen Dank für Ihre
Aufmerksamkeit!
Wie viel Softwaresicherheit ist genug?
Nächste SlideShare
Wird geladen in …5
×

Wie viel Softwaresicherheit ist genug?

1.120 Aufrufe

Veröffentlicht am

Wie kann ich Software Security messbar machen

Veröffentlicht in: Technologie
0 Kommentare
1 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.120
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
27
Aktionen
Geteilt
0
Downloads
6
Kommentare
0
Gefällt mir
1
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

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!

×