Autor: Dr. Ralf Huuck, Synopsys<\/p>\n
Moderne Softwareprozesse sind stark von kurzen Produktzyklen, Modularit\u00e4t, und schnellem Markteintritt angetrieben. Dieses spiegelt sich in den sogenannten DevOps Prozessen wider als auch in dem Trend zu zunehmend agileren Ans\u00e4tzen, die eine flexible Antwort auf sich \u00e4ndernde Anforderungen gibt. Auf der anderen Seite sind die Sicherheitsanforderungen insbesondere im Embedded Software Bereich stark gestiegen. Sicherheit erfordert aber gr\u00fcndliches Planen, eine saubere Sicherheitsarchitektur und Spezialkenntnisse, die einem ad hoc Ansatz entgegenstehen. Dieser Vortrag beleuchtet diese scheinbaren Gegens\u00e4tze und die sich daraus ergebenden Konsequenzen.<\/strong><\/p>\n Softwaresicherheit ist eine gro\u00dfe Herausforderung f\u00fcr die Entwicklung von eingebetteten Systemen. Insbesondere die „Security“ von Systemen, die mit der Au\u00dfenwelt agieren, ben\u00f6tigt ein Expertenwissen, das oft rar ist [1]. Dar\u00fcber hinaus ist die Anwendungssicherheit urspr\u00fcnglich nicht im Fokus bei Design- und Implementierungsentscheidungen von eingebettetem System gewesen. Dieses wandelt sich aber in einem Ma\u00dfe, in dem zum einem Software an gr\u00f6\u00dferer Prominenz gewinnt und zum anderen ein gesteigertes Sicherheitsverlangen vorliegt. Als solches wandelt sich auch die Systemindustrie zunehmend zu einer Softwareindustrie.<\/p>\n Einer der gro\u00dfen Trends in der Softwareindustrie ist es, Produktzyklen zu verk\u00fcrzen, um schneller und flexibler am Markt zu sein. Software erlaubt es oft, kontinuierlich neue F\u00e4higkeiten als Upgrades hinzuzuf\u00fcgen, um das Produkt \u00fcber die Softwareeigenschaften zu verbessern und weiterzuentwickeln.\u00a0 Das Verk\u00fcrzen der Produktzyklen geht oft einher mit einem sogenannten\u00a0agilen Entwicklungsprozess<\/em>. Das bedeutet, dass in kurzer Abfolge neue F\u00e4higkeiten definiert werden, die Architektur daf\u00fcr eventuell erweitert wird und eine Implementierung erfolgt, die das bestehende Produkt erweitert und die teilweise inkrementell zu der Vorg\u00e4ngerversion getestet werden kann. Ziel ist es, eine kontinuierliche Produktverbesserung anbieten zu k\u00f6nnen, w\u00e4hrend man gleichzeitig flexible auf Kundenfeedback reagiert.<\/p>\n Der agile Entwicklungsansatz wird heutzutage um das sogenannte\u00a0DevOps<\/em>\u00a0erweitert, wobei nicht nur die Softwareentwicklung agil gehandhabt wird, sondern wobei auch der Gesch\u00e4ftsprozess inklusive das Zusammenstellen der Software und die Auslieferung an den Kunden weitestgehend automatisiert werden.<\/p>\n DevOps und seine Automatisierung stellt eine zus\u00e4tzliche Herausforderung an die Softwaresicherheit. Im Gegensatz zum Wasserfall-Entwicklungsmodell sind die Entwicklungszyklen oft extrem kurz, die eigentliche Implementierung \u00e4ndert sich stetig, und der Testprozess wird oft begleitend statt in einem separaten nachfolgenden Prozess betrieben. Dieses widerspricht den prinzipiellen Sicherheitsanforderungen, die eine stabile sichere Architektur sowie einen oft langwierigen und manuellen Testprozess verlangen, der zum Beispiel ein sicherheitsrelevantes Penetrationstesten erm\u00f6glicht.<\/p>\n Um den Sicherheitsherausforderungen im DevOps Prozess zu begegnen, ist es unerl\u00e4sslich, auch einen gro\u00dfen Grad an Automatisierung in den Sicherheitstestprozess miteinzubeziehen. Daf\u00fcr ist es entscheidend, Softwaretools einsetzen zu k\u00f6nnen, die nicht nur automatisch ablaufen, sondern die auch direkt im Entwicklungsprozess eingesetzt werden k\u00f6nnen. Als Folge dessen verschiebt sich aber auch der Prozess des Sicherheitstestens zunehmend von separaten und speziellen Testteams hin zu Softwareentwicklern.<\/p>\n Im Folgenden beschreiben wir einige der Werkzeuge und Methoden, die sich zum Sicherheitstesten durch den Softwareentwickler eignen. Einige dieser Methoden sind bereits aus der Qualit\u00e4tspr\u00fcfung bekannt, andere haben sich in letzter Zeit speziell f\u00fcr die Softwaresicherheit entwickelt.<\/p>\n Die folgende \u00dcbersicht z\u00e4hlt exemplarisch einige der Werkzeuge auf, die vollautomatisiert benutzbar sind und somit insbesondere den DevOps Prozess unterst\u00fctzen k\u00f6nnen. Wir unterscheiden folgende Werkzeugklassen:<\/p>\n Die statische Programmanalyse hilft, Programmierfehler direkt w\u00e4hrend der Entwicklung zu entdecken und zu beheben. Diese beinhalteten Fehler wie zum Beispiel SQL Injections, Speicher\u00fcberl\u00e4ufe oder nicht-validierte Eingaben. Oft hilft die statische Analyse der Programmentwicklung, um Sicherheitsfehler fr\u00fchzeitig zu erkennen und ihnen vorzubeugen [3]. Typischerweise l\u00e4uft die statische Analyse direkt im Entwicklungsprozess (siehe Abb. 1,\u00a0PDF<\/a>)<\/p>\n Laufzeitmonitore beobachten das Verhalten eines Systems w\u00e4hrend der Ausf\u00fchrung. Sie sind in der Lage, automatisch bestimmte Fehlerklassen wie verd\u00e4chtige Eingaben zu entdecken. Laufzeitmonitore eignen sich sowohl zur Komplementierung funktionaler Tests als auch zur sch\u00fctzenden Begleitung w\u00e4hrend der Programmausf\u00fchrung. Dar\u00fcber hinaus gibt es aktive Laufzeitmonitore, die aktiv Eingaben testen und deren Reaktionen beobachten k\u00f6nnen. Dieses kann insbesondere f\u00fcr Webanwendungen hilfreich sein, um das Verhalten von m\u00f6glichen Angreifern aufzudecken.<\/p>\n Fuzzing beinhaltet das Testen von Systemen mit einer gro\u00dfen Anzahl pseudo-zuf\u00e4lliger Eingaben und Daten [5]. Es wird h\u00e4ufig beim Penetrationstesten verwendet und kann das Verhalten eines Angreifers simulieren. Das Protokollfuzzing geht einen Schritt weiter: Hierbei wird das Hintergrundverst\u00e4ndnis \u00fcber die eigentlichen Protokolle verwendet, um automatisch gezielte Eingaben zu erstellen, die m\u00f6gliche Schwachstellen der Protokollimplementierung abklopfen (siehe Abb. 2,\u00a0PDF<\/a>).<\/p>\n Eine gro\u00dfe Herausforderung im DevOps Prozess ist es, Software von Drittanbietern einzubinden und zu testen. Dieses k\u00f6nnen sowohl Open Source Anwendung und Libraries sein als auch bin\u00e4re Komponenten von Zulieferern. Um diesem Problem Herr zu werden, gibt es automatische Scanner f\u00fcr Source- als auch Bin\u00e4rcode, die Software gegen eine Liste von bekannten fehlerbehafteten Libraries und Code pr\u00fcft. Diese Listen beinhalten oft CVEs und CWEs [4], die von NIST oder anderen Organisationen gepflegt werden.<\/p>\n Trotz dieser Reihe neuer automatischer Werkzeuge f\u00fcr die Verbesserung von Softwaresicherheit bleibt ein Restrisiko, das teilweise h\u00f6her im DevOps Fall als im traditionellen Ansatz ist. Zum einem liegt dieses an der Fehlbarkeit und Beschr\u00e4nkung von Werkzeugen, beziehungsweise dass diese Werkzeuge oft nicht alle F\u00e4lle abdecken und der Mensch weiterhin als Tester ben\u00f6tigt wird. Zum anderen vernachl\u00e4ssigen diese Werkzeuge die allgemeine Architektur, die, falls nicht korrekt designt, ein falsches Sicherheitskonzept vorgibt. Als solches bleibt der Mensch weiterhin unerl\u00e4sslich, um sichere Software zu designen und zu testen.<\/p>\n Die hier vorgestellten Prozesse und Werkzeuge erm\u00f6glichen es, die allgemeine Softwaresicherheit von eingebetteten Systemen teils drastisch zu erh\u00f6hen. Die M\u00f6glichkeit, diese Werkzeuge vollautomatisch ablaufen zu lassen, er\u00f6ffnet die Option, diese Werkzeuge direkt in den DevOps Prozess mit einzubinden. W\u00e4hrend diese Werkzeuge nicht den kompletten Sicherheitsprozess abdecken k\u00f6nnen, erm\u00f6glichen sie es dennoch, den Menschen gezielter und effektiver einzusetzen.<\/p>\n [1] John Viega & Gary McGraw. Building Secure Software. Addison-Wesley – ISBN 0-201-72152-X. Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Agil & Scrum.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema\u00a0Agil & Scrum steht\u00a0hier<\/strong>\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nEinleitung<\/h2>\n
Ver\u00e4nderte Entwicklungsprozesse: Agile und DevOps<\/h2>\n
DevOps und Anwendungssicherheit<\/h2>\n
Werkzeugklassen zum Sicherheitstesten<\/h2>\n
Statische Programmanalyse<\/h3>\n
Eingebettete Laufzeitmonitore<\/h3>\n
Automatisches Fuzzing von Protokollen<\/h3>\n
Bin\u00e4ranalyse von Drittanbieterkomponenten<\/h3>\n
Herausforderungen<\/h2>\n
Zusammenfassung<\/h2>\n
References<\/h2>\n
\n[2] James D. Brown. Mythbusting: DevOps and Security. Wired Magazine, 2013.
\nhttps:\/\/www.wired.com\/insights\/2013\/10\/mythbusting-devops-and-security\/
\n<\/a>[3] Ralf Huuck, Ansgar Fehnker, and Rodiger Wolf. Model Checking Dataflow for Malicious Input. Proceedings of the 6th Workshop on Embedded Systems Security Taipei, Taiwan, Oct 2011. ACM, Article 4, 10 pages, ISBN: 978-1-4503-0819-9.
\n[4] Common Weakness Enumeration.\u00a0https:\/\/cwe.mitre.org\/<\/a>
\n[5] Barton Miller. In Ari Takanen, Jared DeMott and Charlie Miller, Fuzzing for Software Security Testing and Quality Assurance, 2008, ISBN 978-1-59693-214-2<\/p>\n
\nAgil & Scrum – unsere Trainings & Coachings<\/h2>\n
\nAgil & Scrum – Fachwissen<\/h2>\n