Software

Sicherer Einsatz von Third-Party-Code

3. November 2021, 6:00 Uhr | Martin Woodhall, LDRA

Fortsetzung des Artikels von Teil 1

Schutz der Daten und vor Angriffen

Die Forderung nach einer Internetverbindung ist inzwischen an der Tagesordnung. Neben Fehlern, die zu Problemen mit der funktionalen Sicherheit (Safety) führen, sind deshalb auch Schutzaspekte, die die Absicherung nach außen betreffen (Security), bei vernetzten Produkten in den verschiedenen Branchen ein routinemäßiger Faktor. Wie bedeutsam der Schutzaspekt ist, zeigen die Berichte über Datenschutzverletzungen und gehackte Systeme, die beinahe täglich in den Medien erscheinen. Verletzungen der Privatsphäre und Datenlecks können mit hohen Geldstrafen belegt werden, haben negative Folgen für das Image des Unternehmens und können dazu führen, dass die Endanwender mit hohen Geldsummen entschädigt werden müssen.

Ein Beispiel hierfür ist Open SLL, das von den meisten Internetnutzern und von Website-Software genutzt wird. Die in der OpenSLL-Kryptografiebibliothek gefun­dene Heartbleed-Sicherheitslücke hatte Datenschutzverletzungen zur Folge, wie 2014 offengelegt wurde [1]. Treten derartige Schwachstellen in sicherheitskritischen Systemen auf, können Security-Probleme sich auch negativ auf die funktionale Sicherheit auswirken.

Techniken zur Einbindung von Third-Party-Software

Es gibt erprobte Techniken, die zur Minderung der eben beschriebenen Risiken angewandt werden können. Standards zur funktionalen Sicherheit bieten Leitlinien für die Verwendung von Third-Party-Software, die auch als „Software unbekannter Herkunft“ (Software Of Unknown Provenance, SOUP) bezeichnet wird. Die Norm IEC 62304 (Medical device software – Software life cycle processes, IEC 2006) zum Beispiel listet detailliert auf, welche Maßnahmen zu ergreifen sind, wenn für eine für die Verwendung vorgesehene Third-Party-Software kein Werdegang dokumentiert ist – möglicherweise, weil keine Einzelheiten über den benutzten Software-Entwicklungsprozess verfügbar sind

Die ISO 26262 nennt außerdem folgende weitere Maßnahmen:

  • Verfügbarkeit der Spezifikation für das zu integrierende System.
  • Nachweis in Form eines Prüfberichts, dass das zu integrierende System die gestellten Anforderungen erfüllt.
  • Strukturierte Entwicklungsanalyse für systematische Entwicklungsfehler per FMEA, FTA und Anwendung etablierter Entwicklungsmuster und Entwicklungskonfigurationen.
  • Nachweis, dass das zu integrierende System für den vorgesehenen Verwendungszweck geeignet ist.
  • Verifikation bzw. Validierung des Entwurfs durch stark beschleunigte Lebensdauertests, Umgebungstests, Tests außerhalb der spezifizierten Grenzen und Betriebssicherheitstests.
  • Analyse von Betriebsdaten.

Isolation von Third-Party-Software

Eine Möglichkeit, die aus der Integration von Third-Party-Software resultierenden Risiken zu mildern, ist es, diese von der übrigen Codebasis zu isolieren. Erreichen lässt sich eine solche Isolation mit einem Hypervisor oder einer Firewall, durch Partitionierung oder Segmentierung oder aber durch physische Abtrennung (Bild 1).

Anbieter zum Thema

zu Matchmaker+
Entwickler können verschiedene Methoden einsetzen, um Third-Party-Software in einem Embedded-System zu isolieren
Bild 1. Entwickler können verschiedene Methoden einsetzen, um Third-Party-Software in einem Embedded-System zu isolieren.
© LDRA

Die rechts in Bild 1 gezeigte Third-Party-Software wurde hier erfolgreich isoliert. Wie auf der linken Seite angedeutet ist, können native Software und Open-Source-Software in einigen Fällen jedoch auch in großer Nähe zueinander angesiedelt sein.
Beispiel SOUP: Software Of Unknown Provenance.

Die empfohlenen Praktiken für den Softwareentwicklungs-Lebenszyklus sind zu beachten, wenn der native Code im Kopf Referenzierungen zu externen Bibliotheksdateien (Standard Template Library, STL) enthält (Listing).

Listing. Nativer Code mit Referenzierung der STL-Bibliothek (#include-Anweisung an den Compiler)
Listing. Nativer Code mit Referenzierung der STL-Bibliothek (#include-Anweisung an den Compiler).
© LDRA

Der Ausgangspunkt wäre hier die Ableitung eines Satzes von Anforderungen für die findWeekday-Methode, begleitet von einem Satz von Testfällen, die zur Validierung der Anforderungen und zur Überprüfung der Robustheit des Codes im Umgang mit Grenzfällen dienen.

Fehlgeschlagene Testfälle werden anschließend ausgewertet, und es wird geprüft, ob der Code kompromittiert wurde. Daraufhin werden die Anforderungen ergänzt, um die Erkenntnisse zu berücksichtigen, die neu über den Code gewonnen wurden. Wurden die SOUP-Anforderungen verstanden, ist es möglich, Testfälle zum Validieren dieser Anforderungen zu erstellen und künftige Fehler auf iterative Weise zu behandeln.

Für einen überschaubaren Code, wie in diesem Beispiel, gestaltet sich dieser Prozess natürlich unkompliziert, aber in Wirklichkeit ist die Anwendung der SOUP-Methodik potenziell recht zeitraubend. Entscheidend ist, wie weit die Herkunft der Software nachvollziehbar ist.

Die STL ist ein Beispiel für einen Fall, in dem die SOUP-Methodik praktikabel ist, denn diese Bibliothek wird vom GNU GCC-Projekt zur Verfügung gestellt. Dieses wiederum wendet dokumentierte Planungs-, Konfigurations- und Änderungsmanagement-Prozesse an, verfügt über eine dokumentierte Anforderungsspezifikation und hält entsprechend gepflegte Test Suites bereit, die vom Integrator ausgeführt werden können.

Wenn die Praktiken vom Integrator sorgfältig geprüft und als geeignet erachtet wurden, kann eine Begründung dafür formuliert werden, der STL zu vertrauen und der Software die Eignung für den Verwendungszweck zu bescheinigen. In Fällen, in denen das Fehlerrisiko kritisch oder das Verhalten der Third-Party-Software nicht dokumentiert oder unklar ist, lässt sich durch Anwendung der SOUP-Methodik zusätzliches Vertrauen schaffen.

Entwicklung und Code prüfen

Prüfungen der Entwicklung und des Codes sind weitere etablierte Techniken, mit denen sich Schwachstellen in der Softwarestruktur und im Quellcode aufdecken lassen. Empfehlenswert ist es, den Quellcode der zugelieferten Software – sofern verfügbar – auf bekannte Programmierprobleme hin zu untersuchen.

Programmierrichtlinien und Datenbanken mit Programmierproblemen sind leicht verfügbar und automatisierbar. Bild 2 zeigt die typische Ausgabe eines Tools zur Analyse von C-Code, das die Konformität zu verschiedenen Programmierstandards misst.

Ergebnis einer mit der LDRA Tool Suite durchgeführten Codeprüfung an Open-Source-Software zur Messung der Konformität zu den Programmierstandards MISRA C, CERT C und CWE
Bild 2. Ergebnis einer mit der LDRA Tool Suite durchgeführten Codeprüfung an Open-Source-Software zur Messung der Konformität zu den Programmierstandards MISRA C, CERT C und CWE.
© LDRA

Steht der Quellcode nicht zur Verfügung, zum Beispiel dann, wenn die COTS-Software als System-Image geliefert wird, kann alternativ die Compliance Guidance von  MISRA Compliance: 2020 genutzt werden. Anhand dieser Leitlinien können die Anbieter von Third-Party-Software den Nachweis erbringen, dass ihr Softwareentwicklungsprozess von untadeliger Qualität ist.

Third-Party-Code in eigene Software integrieren

Eine verbreitet genutzte Möglichkeit zur Minimierung des Integrationsaufwands ist es, die Integration einmalig vorzunehmen und die Codebasis anschließend »einzufrieren«, damit für die weitere Dauer des Projekts keine Änderungen mehr vorgenommen werden können. Jedes Release des Softwareentwicklungsprozesses wird dann als »zertifizierte« Version der Software beispielsweise gemäß ISO 26262 betrachtet. Wird allerdings die Third-Party-Software auf eine neue Version aktualisiert, muss der Validierungs- und Verifikationsprozess mit der neuen Codebasis wiederholt werden.

Diese Methode hat jedoch ihre Tücken. Zuallererst kann möglicherweise nicht davon ausgegangen werden, dass zu keiner Zeit Änderungen an der Third-Party-Software erforderlich sein werden. Beispielsweise muss bei einem System, bei dem es auf die Sicherheit ankommt, angenommen werden, dass es zu einer Sicherheitsverletzung kommt. Dann müssen effektive Abhilfemaßnahmen geplant werden, die mit großer Wahrscheinlichkeit Änderungen am Code bedingen.

Third-Party-Software wird in einem breiteren iterativen Softwareentwicklungsprozesses eingebunden
Bild 3. Third-Party-Software wird in einem breiteren iterativen Softwareentwicklungsprozesses eingebunden.
© LDRA

Eine weitere Vorgehensweise, die sich in einigen Branchen als Best Practice etabliert, ist die regelmäßige Integration von Third-Party-Software, um von den neuesten Eigenschaften und Sicherheits-Updates profitieren zu können. Bild 3 illustriert einen typischen Prozess zur Integration von Third-Party-Software im Rahmen eines umfangreicheren, iterativen Softwareentwicklungsprozesses.

Die Norm IEC 62304 legt nahe, dass Medizingeräte-Software die Anforderungen erfüllen und funktionale Fähigkeiten enthalten soll, um die »Kompatibilität zu Upgrades oder mehreren SOUP-Varianten oder anderen Geräteversionen« zu bieten.

 

Literatur

[1] USN-2165-1: OpenSSL vulnerabilities. Canonical, 7. April 2014, https://ubuntu.com/security/notices/USN-2165-1.

 


  1. Sicherer Einsatz von Third-Party-Code
  2. Schutz der Daten und vor Angriffen

Verwandte Artikel

LDRA Inc.