Spätestens seit Mirai und seinen DDOS Angriffen ist das klar, dass Security ein wichtiger Aspekt für den embedded und insbesondere den IoT Bereich ist. Leider ist Security ein ziemlich umfangreiches Thema, das sich sowohl durch alle Phasen des Lebenszyklus als auch von der Hardware über die Systemebene bis zur Applikationsschicht durchzieht. Entsprechend vielfältig und komplex sind die technischen Aspekte, um alles sicher zu machen: Von der Validierung der Eingaben, über die Auswahl des passenden Kryptoalgorithmus bis zu den richtigen Kompilereinstellungen sollen Entwickler und Architekten alles wissen sowie richtig anwenden und (nebenbei?) auch noch die features implementieren. Wie soll man hier den Überblick behalten?

Die übliche Antwort ist: ein Softwareentwicklungsprozess, mit z.B. coding guidelines, statischer Codeanalyse oder review checklisten als typische Elemente. Im regulierten Umfeld ist deren Existenz oft normative Anforderung. Über deren Sinnhaftigkeit sagt das nichts. Wenn die Elemente gut aufeinander abgestimmt sind, dann können sie für Entwickler wirklich hilfreich sein. Wenn nicht, sind Codierungsrichtlinien oft nur Prozess-Leichen oder im Projektalltag schlicht ein ärgerliches Arbeitshindernis.

Im Vortrag geht es darum wie man das Zusammenspiel von security guidelines, Training für Entwickler, Werkzeuge zur Codeanalyse und Security Experten so gestalten kann, dass die tägliche Arbeit der Entwickler auch im heterogenen Umfeld tatsächlich unterstützt wird. Schließlich sollte ein embedded C++Entwickler z.B. auf type conversion vulnerabilities achten, während es dem am selben Projekt arbeitenden Could oder Web-Entwickler kaum interessiert. Diese sollten eher auf cross-site scripting usw. achten. Entsprechend ist es wichtig die Aufmerksamkeit der Entwickler und Architekten auf die für sie wichtigen Sicherheitsaspekte zu richten. Die eingesetzten Werkzeuge müssen diese Fokussierung unterstützen. Außerdem darf der Überblick über die security-relevanten Maßnahmen nicht irgendwann verloren gehen. So muss sichergestellt sein, dass in einem späteren service pack z.B. eine Compilerwarnung nicht einfach ersatzlos entfernt wird, wenn sie explizit als Maßnahme gegen buffer overflow Angriffen dient – egal wie sehr sie ggfs. stört. Entsprechend wichtig ist es den Zusammenhang zwischen konkrete Maßnahme bzw. Regel und ihrem Zweck für alle erkennbar zu definieren und auf dem aktuellen Stand zu halten. Zudem muss für den Entwickler klar sein wann, wo und wie die Implementierung erfolgen soll oder wie man eine fehlerhafte Umsetzung vermeidet. Zudem ist wichtig, wie die Regeln in der Praxis geprüft werden sollen und können. Hier kann der zielgerichtete Einsatz von Werkzeugen z.B. zur statischen Codeanalyse einen erheblichen Beitrag leisten oder eben auch die Entwicklung durch unnötige oder falsche Meldungen behindern.

Schließlich werden gerade für IoT gerade wegen Security in Zukunft Regulierungsmaßnahmen zunehmend diskutiert. Dann wird es wichtig – wie in bestehenden regulierten Bereichen auch heute – Maßnahmen zu dokumentieren. Insbesondere im Streitfall gilt es das Einhalten des Stands der Technik nachzuweisen. Dies kann nur gelingen, wenn man trotz der hohen Vielfalt an Einzelmaßnahmen wirklich den Überblick behält und diesen zudem nachweisen kann.