Security Engineering Software von Anfang an sicher entwickeln

Transkript

1 Security Engineering Software von Anfang an sicher entwickeln ASQF Safety & Security Day Rhein-Main Jens Palluch, Method Park Consulting GmbH

2 Quelle: Motivation 2

3 Motivation Zum Zeitpunkt der Untersuchung hatte ConnectedDrive sechs Schwachpunkte, die seine Sicherheit kompromittierten: BMW verwendet in allen Fahrzeugen dieselben symmetrischen Schlüssel. Einige Dienste verzichten bei der Datenübertragung zum BMW-Backend auf eine Transportverschlüsselung. Die Integrität der ConnectedDrive-Konfiguration wird nicht geschützt. Die Combox verrät mit NGTP-Fehlermeldungen die VIN des Fahrzeugs. Per SMS versendete Daten im NGTP-Format werden mit dem unsicheren DES-Verfahren verschlüsselt. Die Combox hat keinen Schutz vor Replay-Angriffen. Diese Probleme wären einfach vermeidbar gewesen. So sind Funktionen zur Transportverschlüsselung durchaus vorhanden, wurden aber nur für einige ConnectedDrive-Dienste genutzt. Außerdem individualisiert der Hersteller die betroffenen Steuergeräte, indem er beispielsweise die VIN einprogrammiert. Dabei sollte es möglich sein, auch fahrzeugindividuelle Schlüssel abzuspeichern. Quelle: Auto, öffne dich! - Sicherheitslücken bei BMWs ConnectedDrive, c't 05/2015, S. 86 3

4 Quelle: Motivation 4

5 Motivation We wouldn't have to spend so much time, money, and effort on network security if we didn't have such bad software security. [Vorwort von Bruce Schneier in: Viega & McGraw: Building Secure Software - How to Avoid Security Problems the Right Way, Addison Wesley, 2001] Present software development methods lack in-depth security awareness, discipline, best practice, and rigor, and this is evidenced by the sheer quantity of security patches issued each year by all software vendors. [Howard & Lipner: The Security Development Lifecycle - SDL: A Process for Developing Demonstrably More Secure Software, Microsoft Press, 2006] 5

6 Was ist Security? Security: The degree to which a product or system protects information and data so that persons or other products or systems have the degree of data access appropriate to their types and levels of authorisation. [vom ISO product quality model] 6

7 Security-Grundwerte Vertraulichkeit Schutz vertraulicher Informationen vor unbefugter Preisgabe Integrität Informationen sind vollständig, korrekt und gegen unerlaubte Veränderung bzw. Löschung geschützt Verfügbarkeit Befugte können zum geforderten Zeitpunkt auf Informationen zugreifen 7

8 Safety vs. Security ISO PKWs bis 3,5 Tonnen Sicherheit (safety): Freiheit von unvertretbaren Risiken. Risiko (risk): Kombination der Wahrscheinlichkeit des Auftretens eines Schadens und der Schweregrad dieses Schadens. Schaden (harm): Physische Verletzung oder Schädigung der menschlichen Gesundheit 8

9 Safety vs. Security Risikomanagement nach EN ISO Hersteller von Medizinprodukten Sicherheit (safety): Freiheit von unvertretbaren Risiken. Risiko (risk): Kombination der Wahrscheinlichkeit des Auftretens eines Schadens und der Schweregrad dieses Schadens. Schaden (harm): Physische Verletzung oder Schädigung der menschlichen Gesundheit oder Schädigung von Gütern oder der Umwelt. 9

10 Safety vs. Security Risikomanagement nach IEC Betreiber von Medizinprodukten Sicherheit (safety): Freiheit von unvertretbaren Risiken. Risiko (risk): Kombination der Wahrscheinlichkeit des Auftretens eines Schadens und der Schweregrad dieses Schadens. Schaden (harm): Physische Verletzung oder Schädigung der menschlichen Gesundheit oder Schädigung von Gütern oder der Umwelt. 10

11 Safety vs. Security Risikomanagement nach IEC Betreiber von Medizinprodukten Sicherheit (safety): Freiheit von unvertretbaren Risiken bzgl. physischer Verletzung oder Schädigung der menschlichen Gesundheit oder Schädigung von Gütern oder der Umwelt. Risiko (risk): Kombination der Wahrscheinlichkeit des Auftretens eines Schadens und der Schweregrad dieses Schadens. Schaden (harm): Physische Verletzung oder Schädigung der menschlichen Gesundheit oder Schädigung von Gütern oder der Umwelt oder Reduzierung der Effektivität oder Verstöße gegen die Daten- und Systemsicherheit. 11

12 Security Engineering Standards ISO/IEC Lifecycle NIST Special Publication Security Engineering Microsoft SDL SAMM Benchmark BSIMM SSE-CMM (ISO/IEC 21827) 12

13 NIST Special Publication Security Considerations in the System Development Life Cycle definiert Security-Aktivitäten und Kontrollpunkte für jede der 5 Lebenszyklusphasen 1. Initiation Security mehr aus Sicht von Geschäftsrisiken berücksichtigen 2. Development/Acquisition Entwicklungsund Test-Aktivitäten 3. Implementation/Assessment Aktivitäten zur Integration des Systems in die Produktivumgebung 4. Operations and Maintenance Aktivitäten für Betrieb und Wartung 5. Disposal Aktivitäten bzgl. Archivierung, usw. 13

14 MS Security Development Lifecycle Training Design Requirements Implementation Verification Release Response Umsetzung der ISO/IEC Dokumentation im Internet Microsoft SDL - Developer Starter Kit 14 Themen Jedes Thema: Powerpoint-Präsentation Traineranleitung Aufgezeichnete Präsentation Verständnisfragen (inkl. Antworten) 14

15 Software Assurance Maturity Model (SAMM) 15

16 Security Engineering Anforderungen Misuse Cases Security-Anforderungen Design Bedrohungsmodellierung Entwurfsprinzipien Security-Design-Review Codierrichtlinien Security-Code-Reviews Statische Codeanalysen Implementierung Penetration Tests Fuzzing Test 16

17 Bedrohungen und Schwachstellen Bedrohung (Threat): Umstand oder Ereignis Umstand oder Ereignis, der oder das die Verfügbarkeit, Integrität oder Vertraulichkeit von Informationen beeinträchtigen kann. Schwachstelle (Vulnerability): Eine Schwachstelle ist ein sicherheitsrelevanter Fehler eines IT- Systems oder einer Institution. Ursachen können in der Konzeption, den verwendeten Algorithmen, der Implementation, der Konfiguration, dem Betrieb sowie der Organisation liegen. Wert (Asset) Werte sind alles, was wichtig für eine Institution ist (Vermögen, Wissen, Gegenstände, Gesundheit). [Quelle: 17

18 Bedrohungsmodellierung Identifiziere Securityziele Systemüberblick / Kontext Validierung Identifiziere Bedrohungen und Schwachstellen Schutzmaßnahmen umsetzen 18

19 Datenflussdiagramm Prozess Name Datenspeicher Name Datenfluss Name Terminator (Datenquellen/-senken) Name 19

20 Entwurfsprinzipien Single Access Point Berechtigungskonzepte (Zugriffskontrollmodelle) Authentifizierung Erlaubnisprinzip Verschlüsselung von Kommunikation und Daten Need-to-know bzw. Least privilege 20

21 Apples SSL-Fehler (CVE ) Quelle: 21

22 Zusammenfassung Security Engineering muss stärker beachtet werden Security von Anfang an in der Entwicklung berücksichtigen Essentiell: Bedrohungsanalysen/Bedrohungsmodellierung Eigenentwicklung von Grundfunktionen (Verschlüsselung, Authentifizierung, usw.) vermeiden 22

23 Jens Palluch Method Park Consulting GmbH