Der Blätterkatalog benötigt Javascript.
Bitte aktivieren Sie Javascript in Ihren Browser-Einstellungen.
The Blätterkatalog requires Javascript.
Please activate Javascript in your browser settings.
16 Elektronik 16 -17 2020 Software-Engineering wenige Kilobit pro Sekunde völlig ausreichend Für umfassende SoftwareUpdates sind die Kapazitäten jedoch zu gering zumal in einigen der genutzten Funksegmenten regulatorisch festgelegte Zeitfenster zu berücksichtigen sind Außerdem sind die meisten Embedded-Geräte weit verteilt oder mobil eingesetzt Ebenso sind Firewalls zum Schutz vor unerwünschten Aktivitäten lediglich in sehr begrenztem Maße sinnvoll einsetzbar Aus Kostengründen limitierte Hardware-Ressourcen erschweren Updates zusätzlich Ergänzung zum Softwaretest Ziel muss also sein die Systeme bereits mit einem Höchstmaß an Sicherheit zu entwickeln und Fehler bereits so früh wie möglich innerhalb des Software Development Lifecycles SDLC aufzuspüren Ein Standardverfahren dazu ist der Softwaretest Dynamische Tests sind unverzichtbar um funktionale und strukturelle Schwierigkeiten eines Systems zu erkennen Sie haben jedoch eine Einschränkung Ein Test kann Fehler lediglich erkennen wenn ein Testfall den fehlerhaften Code durchläuft zu einer Fehlermeldung führt und diese wiederum ein von der Erwartung abweichendes Ergebnis erzeugt Am Beispiel eines Buffer Overruns wird die Schwierigkeit deutlich Ein einfacher Buffer Overrun in Ckönnte so aussehen char buf 10 … buf 10 = a Hier wird Speicher für ein Array von zehn Zeichen allokiert der Zugriff erfolgt auf den elften Index des Arrays Das Ergebnis des Zugriffs ist nicht definiert In den meisten Fällen wird das Zeichen a in irgendeinen Speicherbereich neben dem Puffer geschrieben und der vorherige Inhalt dabei überschrieben Solche Fehler lassen sich recht einfach aufspüren denn der Index-Wert ist in dem Beispiel hart codiert In der Praxis jedoch stammen die Indizes meist aus unterschiedlichen Quellen wie Anwendereingaben Dateien Signalen von Sensoren und so weiter Ob etwa ein Buffer Overrun im folgenden Beispiel auftritt hängt von der Länge des Strings ab auf den die Variable verweist int i char * s s = char * malloc 100 … i=0 while s i != \0 i++ Ob sich Fehler wie ein Buffer Overrun beim dynamischen Softwaretest zeigen hängt von zwei Faktoren ab Löst der Testfall den Buffer Overrun als Zustandsverletzung aus? Falls ja Verändert die Zustandsverletzung das erwartete Testergebnis? Der erste Punkt lässt sich mit sehr intensivem Testen erfassen bei dem die Entwickler ebenso die Auswirkungen von fehlerhaftem Input und ungültigen Werten ausgiebig untersuchen Bei der zweiten Bedingung wird es schwieriger Testwerkzeuge sind nicht dazu gedacht Zustandsverletzungen direkt zu entdecken Unter Umständen erkennt das Testteam die einfachsten Buffer Overruns nicht solange das Überschreiben des Puffers nicht zu einer falschen Ausgabe oder einem Programmabbruch führt Schwachstellen erkennen Um solche Fehler bereits deutlich früher im SDLC aufzudecken bietet sich die statische Code-Analyse an Vorzugsweise kommen hierfür Werkzeuge zum Einsatz Sie führen den Code nicht aus sondern überführen ihn zunächst in ein Modell Bild 1 Anhand des Modells überprüft das Analyse-Tool alle Steuerungsund Datenströme und prüft deren Korrektheit anhand so genannter Checker Beim Erstellen des Modells aus dem Code arbeitet das Werkzeug ähnlich einem Compiler der Code wird für das Untersuchen in eine Intermediate Representation IR überführt Da die statische Analyse alle Zustände berücksichtigt die das Programm theoretisch einnehmen kann lassen sich potenzielle Fehler mit deutlich höherer Trefferquote aufspüren Zudem geben die Analyse-Tools den Entwicklern viele hilfreiche Informationen die beim Beseitigen der Fehler helfen Standards zur Softwareentwicklung von sicherheitskritischen Anwendungen etwa ISO 26262 in der Automobilbranche oder DO-178 B Cin der Luftfahrt schreiben deswegen die statische Analyse entweder explizit vor oder empfehlen sie dringend Zu den Fehlern die im Fokus der Analyse stehen gehören unter anderem die klassischen Einfallstore für Malware ➔ Buffer Overrun Underrun ➔ Command Injection ➔ Integer Overflow of Allocation Size ➔ SQL Injection ➔ Nonconstant Format String Ein entscheidender Vorteil des Ansatzes ist dass die statische Codeanalyse keinen lauffähigen Code voraussetzt Hiermit ist sie in allen Phasen des SDLC einsetzbar Mit der Prüftiefe ist ebenso der Zeitund Ressourcenaufwand Bild 1 Bei der statischen Code-Analyse wird der Code in eine Intermediate Representation überführt anhand derer alle Steuerungsund Datenströme überprüft werden Bild Grammatech