Security-orientierte Codierstandards

Andrea Gillhuber,

Im Dschungel der Security-Codierstandards

Die Suche nach Security-orientierten Codierstandards für die Industrie ist gar nicht so leicht. So behalten Sie den Überblick. 

© Shutterstock / Wright Studio

Auf der Suche nach Security-orientierten Codierstandards stößt man auf verschiedene Quellen – von den CERT Coding Standards über OWASP und CWE bis hin zu einer Vielzahl unterschiedlicher Empfehlungen und Best Practices. Hinzu kommen zahlreiche fachspezifische Standards wie MISRA, AUTOSAR sowie eine ganze Familie von Standards auf Basis der Norm IEC 61508. Der Umgang mit dieser Flut an Informationen ist eine echte Herausforderung, und auch herauszufinden, welche Codierstandards sich für das anstehende Projekt am besten eignen. Noch schlimmer ist es, wenn bestehende Software im Softwareentwicklungs-Lebenszyklus so angepasst werden muss, dass sie einem dieser Standards entspricht.

Von CVE bis zu den CWE Top 25

Im Jahr 1999 begann die MITRE Corporation (eine US-amerikanische, nicht auf Gewinn ausgerichtete Organisation, die von der US-Regierung gesponserte Forschungs- und Entwicklungszentren betreibt) mit der Dokumentierung bekannter Software-Sicherheitslücken in der CVE-Liste (Common Vulnerabilities and Exposures). Schnell wuchs diese Liste von zunächst 321 Einträgen auf über 100.000 Einträge im September 2018; sie wird von 92 CVE Numbering Authorities (CNAs, siehe Kasten Glossar) gepflegt. Die CVE-Liste findet weithin Anwendung und wird von vielen Organisationen (unter anderem NIST, DISA) empfohlen.

Anzeige

Mit dem Anwachsen der CVE-Liste musste man ihre Einträge je nach Problemtyp in Gruppen einteilen, um die Ursachen der meisten gängigen Probleme besser zu verstehen und geeignete Maßnahmen für die Vermeidung ähnlicher Probleme in der Zukunft zu treffen. Also startete die MITRE die Kategorisierung der bekannten Probleme im PLOVER-Dokument (Preliminary List of Vulnerability Examples for Researchers). Der Zusammenführung dieser Arbeit mit anderen Forschungsarbeiten entsprang die CWE-Liste (Common Weakness Enumeration), eine formelle Aufstellung der verschiedenen Arten von Software-Schwachstellen.

In der aktuellen Version 3.1 umfasst die CWE-Liste rund 700 Arten von Schwachstellen, eingeteilt in 250 Kategorien und Views. Um trotz der hohen Anzahl die Übersicht nicht zu verlieren, führt die CWE zusammen mit dem SANS Institute eine Liste der 25 gefährlichsten Softwarefehler, also der am weitesten verbreiteten und kritischsten Fehler, die zu gravierenden Schwachstellen in Software führen können. Diese „Top 25“-Liste führen an:

1. CWE-89: Unkorrekte Neutralisierung spezieller Elemente, die in einem SQL-Befehl verwendet werden (SQL Injection)

2. CWE-78: Unkorrekte Neutralisierung spezieller Elemente, die in einem Betriebssystem-Befehl verwendet werden (OS Command Injection)

3. CWE-120: Kopieren in den Puffer, ohne die Größe des Eingabewerts zu prüfen (der klassische Pufferüberlauf)

Standards für funktionale Sicherheit (Safety)

Um die funktionale Sicherheit von elektrischen, elektronischen und programmierbaren elektronischen sicherheitsrelevanten Systemen zu gewährleisten, wurde für alle Anwendungsgebiete die Norm IEC 61508 entwickelt. Sie deckt sämtliche Aspekte eines Computersystems ab, ihr Teil 3 (Software Requirements) befasst sich gezielt mit dem Software-Teil des Systems und enthält eine Vielzahl von Anforderungen für sämtliche Phasen des Softwareentwicklungs-Lebenszyklus. Die IEC 61508-3, Tabelle A.9 (Software Verification) enthält eine Liste von Techniken, die für die Software-Verifikation empfohlen werden, darunter unter anderem die explizite und dringende Empfehlung der statischen Analyse für die höheren SILs.

Während die IEC 61508 eine universelle, in den unterschiedlichsten Branchen angewendete Norm ist, gibt es auch auf bestimmte Einsatzgebiete ausgerichtete Normen wie:

  • Luftfahrt: DO-178C / ED-12C
  • Automobil: ISO 26262
  • Eisenbahn: IEC 62279 / EN 50128
  • Kernkraftwerke: IEC 61513

Auch wenn sie die spezifischen Besonderheiten eines bestimmten Gebiets adressieren, ähneln sie sich in ihrem Grundgedanken – zumindest aus dem Blickwinkel der Software: Alle verlangen die Anwendung der statischen Analyse am entwickelten Code, neben anderen Verifikationstechniken. Außerdem bieten sie allgemeine Richtlinien hinsichtlich der zu ergreifenden Maßnahmen, lassen aber gleichzeitig einen breiten Interpretationsspielraum. Normalerweise benennen sie keine bestimmten, anzuwendenden Codierungs-Konventionen oder Codierstandards, nur die ISO 26262 nennt MISRA C als Beispiel einer Codierrichtlinie für die Programmiersprache C.

Sichere Codierstandards (Security)

Die Tabelle „Designs and Coding Standards von IEC 61508-3“ listet Softwaredesign-Techniken, die für bestimmte SILs empfohlen (Recommended – R) oder dringend empfohlen (Highly Recommended – HR) werden. © Parasoft

Das Schreiben von sicherem („secure“) Code heißt: Der geschriebene Code ist nicht angreifbar, weist also keine potenziell ausnutzbaren Schwachstellen oder Sicherheitslücken auf. Zusätzlich muss der geschriebene Code gewisse sichere Muster (im Sinne von „safe“) aufweisen und unsichere Muster vermeiden. Diese Muster unterscheiden sich von einer Programmiersprache zur anderen. Es gibt es keinen Satz „Goldener Regeln“, deren Befolgung die Sicherheit der Software garantiert. Einige verbreitet eingesetzte Codierstandards tragen dem Safety-Aspekt Rechnung:

  • Für die C-Sprache: MISRA-C- und SEI-CERT-C-Codierstandard,
  • Für die C++-Sprache: Codierstandards MISRA C++ und JSF AV C++, Codierstandard SEI CERT C++, Codierrichtlinien AUTOSAR C++ (siehe Glossar am Ende des Beitrags).

Bewährte Vorgehensweisen

Bei der Absicherung des Codes kommt es auf die richtige Wahl an. Muss die Software nach einem bestimmten Functional-Safety-Standard zertifiziert werden (zum Beispiel ISO 26262 für Automotive- oder DO-178C für Luftfahrt-Anwendungen), ist die erste Entscheidung bereits gefällt. Ungeachtet dessen muss aber über den/die Codierstandard/-s oder die Teilmenge des Standards entschieden werden, den die entwickelte Software zwingend einzuhalten hat. Dies kann (muss aber nicht) einer der zuvor erwähnten Standards sein.

Dann geht es um die Auswahl eines geeigneten statischen Analysetools, weil es nicht möglich ist, die Einhaltung all dieser Regeln auf manuellem Weg zu verifizieren. Angeboten werden sowohl quelloffene als auch kommerzielle statische Analysetools. Hier einige Auswahlkriterien:

  • Wird der beziehungsweise werden die gewählte(n) Codierstandard(s) von dem Tool ganz oder teilweise unterstützt?
  • Wenn der betreffende Funktionssicherheits-Standard die Tool-Qualifikation verlangt, ist zu fragen, ob das Tool zertifiziert ist, und ob es das Qualification Kit bietet?
  • Kann das Tool die Analyse-Reports in der für die Konformitäts-Analyse benötigten Form vorlegen?
  • Kann es die Analyse-Reports in einer für die Entwickler leicht lesbaren Form erzeugen?
  • Lässt sich das Tool einwandfrei in die verwendeten IDEs, Build- und CI-Systeme integrieren?
  • Gestattet es eine selektive Analyse von neuem, geändertem oder bestehendem Code?
  • Unterstützt das Tool eine flexible Konfiguration der Analyse?
  • Nutzt das Tool Risk-Scoring-Algorithmen als Hilfestellung beim Priorisieren der gefundenen Defekte?

Zusätzlich betreibt die CWE Community das CWE Compatibility and Effectiveness Program, einen formellen Prüf- und Evaluierungsprozess für ein Produkt oder einen Service. Die Liste mit Produkten und Services, die als „Officially CWE-Compatible“ eingestuft werden, umfasst derzeit 55 Einträge. Steht das gewählte Tool in dieser Liste, ist sichergestellt, dass es die finale Stufe des formellen CWE Compatibility Program der MITRE-Organisation erreicht hat.

Hat man den Codierstandard und die erforderlichen Tools definiert, sollte die weitere Arbeit für die von Grund auf neu gestarteten Softwareprojekte einfach sein: Man muss nur das Tool in das CI-System integrieren und sicherstellen, dass kein Defekt unberücksichtigt bleibt.

Die einzelnen Standards beinhalten mitunter eine große Anzahl an Regeln. Um den Überblick zu erleichtern, werden normalerweise die Regeln in den Standards in mehrere Kategorien eingeteilt. © Parasoft

In aller Regel aber müssen Codierstandards auch für Software durchgesetzt werden, die sich bereits in der Entwicklung befinden. Dann kann das blinde Ausführen der Analyse mit der gesamten Codebasis zu Hunderten von Defektmeldungen führen, die in ihrer Gesamtheit schwierig zu handhaben sind. Zum Glück bietet der Markt mehrere Techniken zur Vereinfachung dieses Vorgangs.

Empfehlenswert ist, sich zunächst auf den neu geschriebenen oder modifizierten Code zu konzentrieren. So lässt sich vermeiden, dass nach Einrichtung des Codierstandards neue Defekte entstehen. Eine weitere bewährte Vorgehensweise ist das Einordnen der gemeldeten Defekte nach ihrer Wichtigkeit, so werden die gravierendsten Fehler als erste bearbeitet.

Für die CERT-C- und CERT-C++-Regeln gibt es eine Risikobewertung, die eine einfache Priorisierung der gefundenen Fehler ermöglicht. © Parasoft

Hilfreich ist eine nach Priorität geordnete Liste der Defekte im Verbund mit der konfigurierbaren Liste der durchzusetzenden Regeln, um sich zunächst auf die Regeln mit dem höchsten Schweregrad zu konzentrieren und die Zahl der Regeln auszuweiten, nachdem die gravierendsten Defekte behoben sind.

Die besten Berichte der statischen Analyse sind nutzlos, wenn die Entwickler sie nicht zum Reparieren des Codes nutzen. Darum ist es am wichtigsten, sicherzustellen, dass sich geeignete Maßnahmen des Entwicklungsteams an die Analyse anschließen – als Voraussetzung für bessere Software in puncto Safety und Security.

Michal Rozenau, Project Lead Engineer bei Parasoft / ag

Literatur

[1] Hicken Arthur, Parasoft, Embedded Cybersecurity Through Secure Coding Standards CWE and CERT

  1. MITRE Corporation, Common Vulnerabilities and Exposures (CVE)
  2. MITRE Corporation, Common Weakness Enumeration (CWE)
  3. IEC, IEC 61508-3:2010 Functional safety of electrical/electronic/programmable electronic safety-related systems – Part 3: Software requirements
  4. ISO, ISO 26262-6:2011(en) Road vehicles – Functional safety – Part 6: Product development at the software level
  5. Carnegie Mellon University, SEI CERT C Coding Standard
  6. Carnegie Mellon University, SEI CERT C++ Coding Standard

Glossar:

CVE Numbering Authorities (CNAs) sind unterschiedliche Organisationen (u. a. Schwachstellen-Erforscher, Produktanbieter sowie Bug-Bounty-Programme, die gleichsam ein Kopfgeld für die Aufdeckung von Programmfehlern aussetzen) auf der ganzen Welt, die die Berechtigung haben, erkannte Probleme mit CVE-IDs zu versehen.

MISRA C und MISRA C++ wurden von der MISRA (Motor Industry Software Reliability Association) entwickelt, die Codierrichtlinien AUTOSAR C++ dagegen von der AUTOSAR (AUTomotive Open System ARchitecture)-Entwicklungspartnerschaft. Für die Entwicklung des Codierstandards JSF AV C++ zeichnet die Lockheed Martin Corporation verantwortlich. Die Codierstandards SEI CERT C und C++ enthalten allgemeine Regeln, die die Safety, Zuverlässigkeit und Security von Softwaresystemen, die in den Programmiersprachen C und C++ entwickelt wurden, gewährleisten sollen.

Anzeige

Das könnte Sie auch interessieren

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige

Cebit

Sieben mittelstandsgerechte IT-Lösungen

Gemeinsam mit den Geschäftspartnern präsentiert IBM auf der Cebit mittelstandsgerechte IT-Lösungen in sieben unterschiedlichen Themenfeldern. So können Besucher "auf einen Streich" die gesamte Bandbreite der IT-Welt von morgen in Augenschein nehmen.

mehr...

Newsletter bestellen

Immer auf dem Laufenden mit dem SCOPE Newsletter

Aktuelle Unternehmensnachrichten, Produktnews und Innovationen kostenfrei in Ihrer Mailbox.

AGB und Datenschutz gelesen und bestätigt.
Zur Startseite