Applikationssicherheit im gesamten Entwicklungszyklus mit Hilfe von OpenSAMM und BSIMM

Transkript

1 Applikationssicherheit im gesamten Entwicklungszyklus mit Hilfe von OpenSAMM und BSIMM Lucas v. Stockhausen Software Security Consultant

2 Angreifer 288 Mrd. US$ weltweit für IT Sicherheitsbudget PCs Netzwerk Software Geistiges Eigentum Kundendaten 165 Mio US$, oder 0,06% Geschäftsprozesse Geschäftsgeheimnisse

3 Heise Newsletter vom Januar 2011

4 Fallbeispiel: Heartland Payment Systems Heartland Payment Systems Übernimmt Zahlungsabwicklung für 2,500+ klein und mittelständische Unternehmen im Kreditkartenumfeld 1997 #62 in den USA 2009 #4 in den USA, #8 in der Welt Der Einbruch gehört nach wie vor zu den largest ever Hoch organisiert Daten von 94 Mio. Kreditkarten & Kundenkarden (EC) wurden gestohlen Visa erkennt den PCI-DSS Status ab Aktien fallen um 80% Auflaufende Kosten bis Anfang 2011 über 140 Mio. US$

5 Fallbeispiel: Heartland Payment Systems

6 Fallbeispiel: Heartland Payment Systems Ein Script entdeckt eine verwundbare Application SQL Injection Zugriff auf das Firmennetzwerk Über Monate offen 94 Mio. Kartendatensätze gestohlen

7 Fallbeispiel: RBS World Pay RBS WorldPay ist die US Tochter für Zahlungsabwicklung der Royal Bank of Scotland Es wurden von 1,5 Mio. Kartenbesitzern Kontodaten sowie persönliche Daten potenziell kompromitiert, ebenso wie 1,1 Mio. Sozialversicherungsnummern Ebenfalls wurde ca. 100 komplette Kreditkarteninformationen gestohlen (Full magnetic stripe) An über 130 Geldautomaten in 49 Städten und 16 Länder wurde am 8. November 2008 innerhalb von 30 Minuten mit diesen Karten Geld abgehoben Die Angreifer scheinen in der Lage gewesen zu sein, auch die Limits der Karten zu manipulieren, da in diesen 30 Minuten 9 Millionen US$ abgehoben wurden. Das macht pro Karte einen Betrag von US$

8 Fallbeispiel: RBS World Pay Das Ende der Geschichte 09. August Estland liefert die vermutlichen Drahtzieher in die USA aus

9 SDLC Secure Development Lifecycle Menschen Prozesse Technologien

10 Sicherheit im Lebenszyklus einer Applikation

11 Maturity Models

12 BSIMM

13 BSIMM Pro Practice gibt es 3 Level: Level 1: überschaubar und einfach Level 2: schwieriger, benötigt mehr Koordination Level 3: Rocket Science Es gibt 109 Aktivitäten verteilt auf die 12 Practices und 3 Level

14 BSIMM: Beispiel Training Level 1: Ernennen von Sicherheitsverantwortlichen. (4 Aktivitäten) Aktivität 1: Aufklärungsarbeit Level 2: Erstellen von massgeschneiderten rollenbasierten Trainings und Durchführung auf Anfrage. (5 Activities) Aktivität 1: Angebot von Rollenbasierten erweiterten Lehrplänen (Werkzeuge, Technologien,...) Level 3: Anerkennung für Fähigkeiten und erstellen einer beruflichen Laufbahn (4 Activities) Activity 1: Anerkunnung von Fortschritt (Zertifikate or HR)

15 OpenSAMM / SSA

16 OpenSAMM / SSA Jede Security Practice besteht aus 3 Maturity Leveln Level 1: Grundverständnis und zur Verfügung stellen von Sicherheitspraktiken auf einer ad hoc basis. Level 2: Erweitere Effektivität und / oder Effizienz von Sicherheitsprkaktiken. Level 3: Umfangreiche Beherrschung der gesamten Sicherheitspraktiken Jeder Level hat dazugehörige Zielsetzungen, Aktivitäten, Überprüfungskritierien und Resultate.

17 OpenSAMM / SSA Beispiel Education&Guidance Level 1: Anbieten von Resourcen zu den Themen sichere Entwicklung und Deployment für die Entwicklungsabteilung Aktivität 1: Durchführung von Aufklärungsveranstaltungen Level 2: Ausbildung aller Mitarbeiter im sicheren Entwicklungszyklus mit rollenspezifischer Orientierung. Aktivität 1: Durchführen von Rollenspezifischen Applikationssicherheitstrainings. Level 3: Verpflichtende umfangreiche Sicherheitstrainings und Zertifizierung der Mitarbeiter Aktivität 1: Erstellen eines formalen Applikationssicherheitsportales.

18 Vergleich der Aktivitäten OpenSAMM / SSA Lev1-Akt1: Durchführung von Aufklärungsveranstaltungen Lev2-Akt1: Durchführen von Rollenspezifischen Applikationssicherheitstrainings Lev3-Akt1: Erstellen eines formalen Applikationssicherheitsportales. Lev3-Akt2: Erstellen Aufgabenspezifischer Prüfungen und Zertifizierungen BSIMM Lev1-Akti1: Aufklärungsarbeit Lev2-Akt1: Angebot von Rollenbasierten erweiterten Lehrplänen (Werkzeuge, Technologien,...) Lev3-Akt1: Anerkunnung von Fortschritt (Zertifikate or HR)

19 Theorie und Praxis Wie können uns BSIMM und OpenSAMM bei der Umsetzung helfen?

20 Was brauchen wir? Wir müssen wissen, was wir erreichen wollen Eine gute Idee ist es hierbei, auf Firmen im eigenen Bereich zu blicken BSIMM kann hier hervorragend helfen

21 Scorecard Leere Scorecard Best Prac&ces Im eigenen Bereich eigener Score Roadmap Objec&ve 3 Objec&ve Objec&ve Level 0 Strat & Met Poli & Comp Edu & Gui Threat Ass Sec Req Secure Arch Design Rev Code Rev Sec Tes&ng Vul Mgmt Env Harden Ops Enable Governance Construc&on Verifica&on Deployment

22 SSA Best Practices - Grundsätze Schnelle Identifizierung und Behebung von kritischen Fehlern Weder die Behebung vergessen noch versuchen das unmögliche zu erreichen. Verhindere die Einführung neuer Verwundbarkeiten Integration in den bestehen SDLC mit minimalen Prozessänderungen Flexibilität sicherstellen bei Änderungen im SDLC Support für Entwickler zur Verfügung stellen Training im Kontext des eigenen Projektes Mentoring wo immer nötig Überwachen und kontrollieren Automatisierte Erfassung von Verwundbarkeitsstatistiken und deren Veröffentlichung Sicherstellen der Prozesse durch ein Sicherheitsgate Ständige Verbesserung 22

23 SSA Best Practice Bewertung Pilot Bewertung Ausrollen Verbesserung Einführen eines SSA Team

24 SSA Best Practice Bewertung Pilot Bewertung Ausrollen Verbesserung Grundlegende Bewertung gegen das SSA Maturity Model Wo steht man? SSA Zielvision Wo möchte man hin? SSA High-Level Roadmap Wie will man dort hin? Implementierungsplan für die erste Phase Nächste Schritte Einführen eines SSA Team

25 SSA Best Practice Bewertung Pilot Bewertung Ausrollen Verbesserung Aufstellen und vorantreiben des SSA Programmes Erfordert Support vom höheren Managment Erstellen von Richtlinien Applikationssicherheit Center of Excellence (CoE) Unterstützen der Entwicklungsteams Definieren der SDLC Kontrollpunkte Erstellen eines initialen Sicherheitsgates Aufsetzen des Governance Modules Applikationskatalog Erstellen von Compliance Reports Einführen eines SSA Team

26 Beispiel einer Sicherheitsrichtlinie Alle Entwickler müssen in Techniken der sicheren Entwicklung trainiert sein. Während der Definition eines Projektes ist eine Bewertung des Risikos der Applikation verpflichtend, basierend auf den Daten auf welche die App zugreift und der Angriffsoberfläche. Für Hochrisikoapplikationen: Eine Sicherheitsüberprüfung is während der Design Phase erforderlich Sämtliche Codeerweiterungen/veränderungen müssen vor dem ausrollen von einer anderen Person als dem Entwickler überprüft werden. Sämtlicher Code muss mit dem Fortify Static Code Analyzer überprüft und die Ergebnisse wöchentlich begutachtet werden Alle OWASP Top 10 Verwundbarkeiten müssen vor der Freigabe des Codes entfernt werden.

27 SSA Best Practice Bewertung Pilot Bewertung Ausrollen Verbesserung Einführen eines SSA Team Arbeit mit der Appliktion/Team Aufsetzen der Fortify Infrastruktur Erstüberprüfung Support bei der Behebung Fortify 360 Training Mentoring Erfassung von Metriken Business As Usual Prozess Integration Erfahrung sammeln Erstellte Dokumente und Prozesse beeinflussen das SSA Programm

28 SSA Best Practice Bewertung Pilot Bewertung Ausrollen Verbesserung Grundlegende Bewertung gegen das SSA Maturity Model Wo steht man? SSA Zielvision Wo möchte man hin? SSA High-Level Roadmap Wie will man dort hin? Implementierungsplan für die erste Phase Nächste Schritte Einführen eines SSA Team

29 SSA Best Practice Approach Bewertung Pilot Bewertung Ausrollen Verbesserung Einführen eines SSA Team Veröffentlichen des SSA Programmes Pilotteam gilt als Referenz Ausrollen über die gesamte Organisation abhängig von den Businessrisiken Für jedes Team gilt Erstüberprüfung Fortify 360 Training Mentoring Business as Usual Prozessintegration Veröffentlichung der Metriken

30 SSA Best Practice Approach Bewertung Pilot Bewertung Ausrollen Verbesserung Einführen eines SSA Team Erhöhen des Maturity Levels in sämtlichen Funktionen Erhöhen der Sicherheits-Messlatte Einführen von wiederkehrenden Verbesserungsschleifen

31 Ziele und Vorteile von Software Security Assurance SSA Eine erfolgreiche Software Security Initiative führt zu: messbar redzuiertem Risiko für existierende Applikationen einem kontrollierten Prozess um Verwundbarkeiten in neuen Versionen vorzubeugen reduzierten Kosten, Verzögerungen und unnötigen Aufwand für Notfall Bug-Fixes und die Bearbeitung von Vorfällen.

32 Vielen Dank 32