CERT vs. MISRA vs. ISO/IEC 17961

Der richtige Coding-Standard für sichere Embedded Software

Seite: 2/2

Firmen zum Thema

Den geeigneten Coding-Standard für die richtige Anwendung wählen

Flowchart: Wann empfiehlt sich der Einsatz welches Coding-Standards? Weiß unterlegte Standards sind im jeweiligen Fall stark empfohlen. Grau unterlegte sind tauglich, aber im direkten Vergleich weniger stark.
Flowchart: Wann empfiehlt sich der Einsatz welches Coding-Standards? Weiß unterlegte Standards sind im jeweiligen Fall stark empfohlen. Grau unterlegte sind tauglich, aber im direkten Vergleich weniger stark.
(Bild: PRQA)

Den einen besten Standard für das Kodieren geschützter Software gibt es nicht. Die richtige Auswahl muss verschiedene Aspekte berücksichtigen – wie lange dauert das Projekt (hier ist die Stabilität der Referenz von großer Bedeutung), welche Sprachversion wird eingesetzt? Und: gibt es bestehenden Code?

Erst informieren, dann auswählen. Das Flussdiagramm links kann die Auswahl optimieren.

Szenario 1: Wenn die Anforderungen eine Compliance mit einem anerkannten Coding-Standard vorschreiben (ein übliches Szenario bei sicherheitskritischen Anwendungen), dann ist MISRA C die erste Wahl. Die neueste Version dieses Standards ist MISRA C:2012 mit der Ergänzung 1. Wird eine Vorgängerversion von MISRA verlangt (zum Beispiel MISRA C:2004), dann profitiert das Projekt, wenn man zusätzlich die Sicherheitsregeln von ISO/IEC 17961:2013 einbindet (es erfordert einen gewissen Aufwand, die C-Version anzupassen und die Überschneidungen zu entfernen. Mit dem Addendum 2 von MISRA C:2012 “Coverage of MISRA C:2012 against ISO/IEC 17961:2012 C Secure” ist man auf einem guten Weg.)

Szenario 2: Sofern für die Anwendung keine Compliance-Anforderungen bestehen und es keinen Bedarf an Hochleistungen auf Kosten der Code-Portabilität gibt, empfiehlt sich weiterhin, den Blick auf höchste Integrität zu richten. Auch in diesem Fall wäre MISRA C:2012 die beste Wahl.

Szenario 3: In Szenario 1, wie auch in Szenario 2 könnte CERT C im Hinblick auf die Security wertvolle Unterstützung bieten. Die Empfehlung lautet, CERT C parallel in die vorgeschlagenen Standards einzubinden (im Flussdiagramm ist das durch eine gestrichelte Linie angedeutet). Wenn MISRA C:2012 jedoch als zu restriktiv angesehen wird – zum Beispiel bei einem Ansatz mit hoher Integrität – wäre die Empfehlung, nur CERT C einzusetzen. Damit schafft man Code Security auf einem guten Niveau.

Schlussfolgerungen

Für welchen Coding-Standard man sich entscheidet, um sicheren Code zu erzeugen, hängt von vielerlei Faktoren ab. Dazu muss man die Eigenschaften und Vorteile jedes Standards kennen. Und vor allem wissen, wie sie die Anforderungen des aktuellen Entwicklungsprojekts erfüllen können.

Das hier gezeigte Verfahren zielt darauf, automatisiertes Testen mit Werkzeugen wie den automatisierten Analysetools QA-C und QA-C++ von PRQA durchzuführen. Solche Tools führen eine Tiefenanalyse von Softwarecode durch, um Fehler zu entdecken und zu eliminieren. Oder am besten: gar nicht erst entstehen zu lassen. Sie erzwingen automatisch das Einhalten von Kodierungsregeln für standardkonforme Software.

Gefahr für die Industrie: Schon vor Meltdown und Spectre waren industrielle Steuerungsanlagen  und Embedded-Systeme durch Cyberattacken bedroht.

Warum Security by Design im IoT noch nicht angekommen ist

Da Safety und Security zum Teil unterschiedliche Regelsätze und Protokolle verwenden, zogen es Softwareentwickler in der Vergangenheit vor, eines der beiden über das andere zu priorisieren – meist zu Lasten der Security. Doch das ist nicht zwingend nötig.

Lösbarer Konflikt – Safety und Security in der Softwareentwicklung

Die Sicherheit eingebetteter Systeme ist unerbittlichen Attacken ausgesetzt. Darunter sind auch SCADA-Systeme (Supervisory Contron and Data Acquisition), die Industrieanlagen, Verkehrsnetze oder Kraftwerke überwachen und steuern.

Software-Design

Grundlagen der Sicherheit bei Embedded-Software

* Richard Bellairs ist Product Marketing Manager bei PRQA.

(ID:45190803)