Fünf Faktoren für sichere Software

Statistische Codeanalyse

Fünf Faktoren für sichere Software

Mit dem Internet of Things explodiert die Zahl der Internet-fähigen Geräte. Und damit auch die Möglichkeit für Cyberkriminelle, diese Devices als Angriffsvektoren zu nutzen. Entwickler und Hersteller sind damit gefordert, an ihren Code und ihre Produkte deutlich strengere Sicherheitsanforderungen zu stellen als bislang. Dabei spielen fünf Aspekte eine wichtige Rolle.

Bei der statischen Analyse wird der Code nicht ausgeführt, sondern alle möglichen Zustände in einem Modell überprüft. (Bild: GrammaTech Inc.)

Bei der statischen Analyse wird der Code nicht ausgeführt, sondern alle möglichen Zustände in einem Modell überprüft. (Bild: GrammaTech Inc.)

Ein Mensch stirbt, weil Angreifer seinen Herzschrittmacher aus der Ferne deaktiviert haben. Das Szenario klingt wie aus einem Science-Fiction-Film, ist aber potenziell heute möglich. So kam es Ende August dieses Jahres zu einer Rückrufaktion des Pharmakonzerns Abbott, weil eine Sicherheitslücke einen Herzschrittmacher über Funk angreifbar macht. Und das ist kein Einzelfall, bereits im Oktober 2016 warnte der Hersteller Johnson & Johnson vor einer Sicherheitslücke in einer Insulinpumpe des Unternehmens. Auch wenn die Beispiele aus der Medizintechnik eine besondere Nutzung des IoT darstellen, wird deutlich: An IoT-Geräte müssen andere Maßstäbe angelegt werden als an herkömmliche Clients. Denn nichts anderes sind IoT-Devices zunächst – Clients, die Daten über das Internet senden und empfangen. Und diese Geräte mit den in der IT üblichen Methoden zu schützen, ist schlicht nicht möglich.

Viele IoT-Geräte sind mit sehr geringen Übertragungskapazitäten mit dem Internet verbunden. Für Softwareupdates sind die Kapazitäten zu gering. Darüber hinaus sind die meisten IoT-Geräte weit verteilt oder auch mobil. Firewalls wie in der sonstigen IT scheiden somit aus. Sicherheit muss also ein Designprinzip werden. Eine wichtige Rolle nimmt dabei die statische Codeanalyse als fortlaufendes Korrektiv im Prozess ein: Bei der statischen Analyse wird die Software nicht ausgeführt, sondern ein Modell erzeugt, das geprüft werden kann. Und damit auch mögliche Error Conditions, die in Testszenarien in der Regel nicht auftreten, aber dennoch später für Probleme sorgen können. Um sicheren Code zu erzeugen, sollten sich die Entwicklerteams fünf Prinzipien zu eigen machen.

Strukturierte Informationen zu gefundenen Fehlern helfen den Entwicklern dabei, diese frühzeitig und schnell zu beheben - bevor große Kosten entstehen. (Bild: GrammaTech Inc.)

Strukturierte Informationen zu gefundenen Fehlern helfen den Entwicklern dabei, diese frühzeitig und schnell zu beheben – bevor große Kosten entstehen. (Bild: GrammaTech Inc.)

1. Vorgehensmodell festlegen

Aus Zeitmangel und aufgrund unklarer Vorgaben werden immer wieder die grundlegenden Vorarbeiten bei der Software-Entwicklung vernachlässigt. Dazu gehört, ein Vorgehensmodell festzulegen und zu etablieren, dass man den Software Development Lifecycle in einzelne Phasen gliedert. Innerhalb dieser Phasen sollte auch das Testing und die Codeanalyse fest als fortlaufender Prozess zur Qualitätssicherung eingeplant werden. Vor allem in den frühen Phasen der Software-Entwicklung ist meist noch kein wirkliches Testing möglich, da noch kein lauffähiger Code existiert. Hier ist es umso wichtiger, mit statischer Analyse den Code auf Fehler zu untersuchen. Schwerwiegende Programmierfehler wie Null Pointer Deferences oder Buffer Overruns könnten durch statische Analyse erkannt und frühzeitig behoben werden. Hier gilt die Regel: Je früher ein Fehler gefunden wird, desto geringer sind die Folgekosten.

2. Werkzeuge und Methodik

Mit welchen Werkzeugen und Methoden die Entwickler arbeiten, steht in vielen Fällen fest, bevor die Projektspezifikationen definiert sind. Das kann unter Umständen zu Lasten der Produktivität und auch der Qualität gehen. Nicht alle Ansätze und Tools eignen sich gleichermaßen für alle Projekte. Zudem sollte darauf geachtet werden, dass wesentliche Elemente des SDLC wie Codereviews eng in den Arbeitsablauf der Entwickler eingebunden sind. Idealer Weise kann die Code-Analyse direkt in die IDE der Developer integriert werden, hier gibt es seitens der Hersteller bereits einige Angebote. So kann zum Beispiel Codesonar von GrammaTech in die Wind River Workbench integriert werden, die Entwickler müssen somit die Workbench nicht mehr verlassen.

3. Standards und Richtlinien

Jedes Entwicklerteam sollte über ein Mindestmaß an Standards verfügen, die verbindlich vorgeschrieben sind. Dazu gehören einschlägige Normen und Branchenvorgaben wie MISRA-C in der Automotive-Branche. Aber auch interne Richtlinien wie ein Benennungssystem für Variablen fallen unter diese Rubrik. Werden die Standards nicht strikt eingehalten, kann dem fertigen Code in vielen Branchen die Zulassung verweigert werden. Darum schreibt etwa MISRA-C vor, dass die Einhaltung durch den Einsatz von statischer Analyse zu gewährleisten ist. Tools zur statischen Codeanalyse lassen sich dazu mit frei definierbaren Checks auf den jeweils benötigten Rahmen anpassen. Für die üblichen Standards stehen zahlreiche Checks vordefiniert bereit. Auch hier ist es sinnvoll, das Analysetool mit dem Build-System als vertrauenswürdige Quelle zu integrieren.

4. Externer Code

VDC Research ermittelte 2016 in einer Studie, dass im Embedded-Bereich fast 45 Prozent der Code-Basis aktueller Projekte von Dritten stammt. Dadurch entsteht in der Software Supply Chain ein unwägbares Risiko: Ist der Code aus externen Quellen sicher und entspricht er den eigenen Standards? Eine manuelle Prüfung mag bei Quellcode zumindest theoretisch noch möglich sein, bei binären Dateien kommt man so nicht weiter. Es ist also auf jeden Fall sinnvoll, Code aus externen Quellen ebenso zu überprüfen wie die eigene Entwicklungsarbeit. Dazu empfehlen fast alle Standards ab einer gewissen Kritikalität der Anwendung den Einsatz von statischer Analyse. Die meisten Tools sind aber nicht in der Lage, binären Code hinreichend zu analysieren. Codesonar von Grammatech kann sowohl Binärcode als auch Quellcode auf Schwachstellen untersuchen.

5. Strukturierte Code-Reviews

Für die Qualität der Software und für deren Sicherheit ist entscheidend, dass möglichst alle Fehler gefunden werden. Sicher wird es ab einer gewissen Komplexität niemals eine völlig fehlerfreie Software geben. Doch jede Schwachstelle, die von einem Angreifer ausgenutzt werden kann, zieht Folgekosten nach sich und schadet dem Ruf des Unternehmens. Deswegen sollte der Code strukturiert mittels Testing und statischer Analyse auf Herz und Nieren überprüft werden. Regelmäßige Reviews mit einer angemessenen Feedback-Schleife von den ersten Codezeilen bis hin zur Endabnahme vor der Auslieferung kosten zwar Zeit, beschleunigen aber unterm Strich die Time-to-Market und senken den Wartungsaufwand.

Autor: Mark Hermeling
Senior Director Product Marketing
GrammaTech
www.grammatech.com

Ausgabe:
GrammaTech Inc.
www.grammatech.com

Das könnte Sie auch Interessieren