Auf den ersten Blick liefert das CVE-Konzept bereits eine Antwort. Jede Meldung wird einem Schwachstellentyp (Common Weaknesses Enumeration) zugeordnet, beispielsweise CWE-20 „Ungenügende Prüfung von Eingaben“. Allerdings dürfte es kaum möglich sein, als Entwicklungsziel die Abwesenheit von Fehlern bei allen 1.248 Einträgen in der Datenbank [1] anzustreben. Wie lässt sich dann eine hohe Security-Qualität erzielen? Um ein schwachstellenarmes Produkt zu entwickeln, sollte ein Prozess für einen sicheren Lebenszyklus (Security Development Lifecycle) zum Einsatz kommen. Die Norm IEC 62443-4-1 beschreibt ein solches Verfahren für Automatisierungssysteme. Der Ablauf setzt sich aus acht Elementen zusammen, die nachfolgend vorgestellt werden sollen. 

Im ersten Schritt ist es wichtig, die relevanten Nutzungsbedingungen für das Produkt zu verstehen und zu beschreiben. Wird das Produkt von vertrauenswürdigem Personal in einer kontrollierten Umgebung bedient? Oder ist es so unkontrollierbar wie das im Supermarkt installierte Kartenterminal? Welche Informationen werden verarbeitet? Handelt es sich lediglich um Daten des Anwenders oder sind Informationen einer weiteren Partei – zum Beispiel eines Maschinenbauers oder Integrators – zu berücksichtigen? Durch die Beantwortung entsprechender Fragen lässt sich der Schutzbedarf des Produkts sowie seiner Funktionen und Daten ermitteln, und die Bedrohungen können erarbeitet werden. Gefährdungen entstehen hier beispielsweise aus der Manipulation oder dem Auslesen von Daten bei einem physischen Zugriff. Sind mehrere Parteien involviert, resultieren Bedrohungen unter anderem aus dem Offenlegen des Steuerungsprogramms eines Maschinenbauers durch den Anwender. 

Auf dieser Grundlage werden die Sicherheitsanforderungen formuliert, die für das weitere Vorgehen entscheidend sind. Ist das Produkt in seiner Umgebung gefährdet, muss es den physischen Zugriff erschweren und derartige Versuche erkennbar machen. Sollen Informationen verschiedener Parteien geschützt werden, erweist es sich als notwendig, dass die Rechteverwaltung die Zugriffe sauber trennt. Zu den Sicherheitszielen gehört auch die Festlegung des zu erreichenden Sicherheitsniveaus, das sich an der Angreiferstärke orientiert. Sind große Werte abzusichern, werden mehr Attacken abgewehrt werden müssen. Im Ergebnis sollten die Sicherheitsanforderungen bei der Konzeption und Umsetzung des Security-Konzepts vollständig vorliegen, damit sie einbezogen werden können.

Bewährte Security-Konzepte nutzen

Das Produkt wird nun so gestaltet, dass sein Aufbau und die Funktionen die Schutzziele erfüllen und es in der Lage ist, die zusammengetragenen Bedrohungen abzuwehren. Zu diesem Zweck sind bewährte Security-Konzepte wie die Minimierung von Ausführungs- und Zugriffsrechten, mehrstufige Sicherheitsmechanismen und die Verringerung von Angriffsflächen in Betracht zu ziehen. Die Anwendung erprobter Entwurfsregeln vermeidet viele der oben aufgeführten Schwachstellentypen. Dabei muss die Bedrohungsanalyse gemäß dem ausgearbeiteten Entwurf weitergeführt werden. Hier wird die Bedrohung durch mögliche Angriffspunkte bewertet, um die Gefährdung zu ermitteln. Erst wenn der Eintritt des möglichen Schadens bei allen Bedrohungen als unwahrscheinlich genug angesehen wird, lässt sich das Restrisiko akzeptieren. Die Sicherheit des Designs wird durch ein Vier-Augen-Prinzip unterstützt. 

Von verschlüsselten Kommunikationsverbindungen bis zu speziellen Chips zur Ablage elektronischer Schlüssel zu Prozessoren, die nur digital signierten Code ausführen, stehen viele technische Mittel zur Verfügung. Zur Verwaltung der Informationen mehrerer Parteien kann ein passendes Rechte- und Rollenmanagement vorgesehen werden. Auf diese Weise liegt ein belastbares Konzept vor, das sich nicht so einfach aushebeln lässt. 

Bestehende Programmierrichtlinien beachten, Schwachstellen verhindern

Die saubere Realisierung des Designs in Hard- und Software stellt das zweite wesentliche Element zur Verhinderung von Schwachstellen dar. Programmierrichtlinien enthalten Vorgaben, deren Beachtung beim Unterbinden typischer Fehler hilft. Als Beispiele seien die Vorschriften zum richtigen Umgang mit der Länge von Zeichenketten oder der Nutzung von Sonderzeichen genannt. Sehr wichtig ist zudem die korrekte Handhabung von Fehlermeldungen. Getreu dem Motto „Wenn alles nach Plan läuft, treten keine Fehler auf“ werden diese Hinweise gerne in der Entwicklung ignoriert, sodass sie im realen Einsatz zu Sicherheitslücken führen. Dabei gibt es für fast alle Programmiersprachen als Beispiel heranziehbare Programmierrichtlinien. Zur Überprüfung der Implementierung können neben dem Vier-Augen-Prinzip ebenfalls Werkzeuge verwendet werden, welche den entstandenen Code auf Einhaltung der Vorgaben oder typische Fehlermuster untersuchen (Static Code Analysis). Bei Berücksichtigung der geschilderten Vorgehensweise zeichnet sich das Programm durch eine hohe Qualität und weniger Fehler aus – auch hinsichtlich der Security. 

Definierte Sicherheitseigenschaften testen

Die Überprüfung der Sicherheitseigenschaften muss mehrere Aspekte abdecken: Für jede im Rahmen der Spezifikation aufgestellte Sicherheitsanforderung sind die jeweiligen Nachweise durch Tests zu erbringen. Zudem wird ein Nachweis bezüglich der Wirksamkeit sämtlicher im Entwurf festgelegten Sicherheitsmaßnahmen verlangt. Ferner muss eine manuelle oder automatische Kontrolle auf bekannte Schwachstellen sowie häufig eintretende Fehler und Probleme durchgeführt werden, um typische Implementierungsfehler oder bereits publizierte Unzulänglichkeiten in genutzten Teilkomponenten aufzudecken.   

Zum Stand der Technik gehören ebenfalls Fuzzing-Tests: Durch die Versendung zufällig verfälschter Daten lässt sich die Robustheit des Produkts überprüfen. Schließlich sollte ein Experte einen Angriffstest (Penetration-Test) vornehmen. Unabhängig vom normalen Team versucht der Fachmann, die Sicherheitsschranken des Produkts zu überwinden. Aufgrund seiner Autonomie soll Betriebsblindheit vermieden werden. Der Penetration-Test lässt sich intern oder durch einen spezialisierten Dienstleister umsetzen. Das beschriebene Vorgehen resultiert in einem großen Vertrauen in die Security-Fähigkeit des Produkts. 

Auftretende Sicherheitsmeldungen kontinuierlich überwachen

Trotz der Realisierung aller Tests gilt: Die Abwesenheit des Beweises (für Schwachstellen) ist kein Beweis für die Abwesenheit (von Schwachstellen). Schwachstellenfreie Produkte gibt es nicht. Insofern zählen deren laufende Überwachung sowie die Entgegennahme von Sicherheitsmeldungen als fester Bestandteil des Produktlebenszyklus. An die Öffentlichkeit gelangte Probleme sind zu bewerten und führen unter Umständen zu Sicherheitshinweisen (Advisory) und Security-Updates. Die Security-Qualität und Widerstandsfähigkeit der Produkte müssen also kontinuierlich kontrolliert werden.

Nachvollziehbare Patches und ausführliche Dokumentation 

Die Behebung von Sicherheitslücken erfolgt meist über die Bereitstellung von Security-Updates, sogenannte Patches. Diese sind auf Nebenwirkungen zu testen und so zu dokumentieren, dass der Anwender des Produkts über sein Vorgehen entscheiden kann. Updates müssen selbstverständlich in der Form zugänglich gemacht werden, dass sich ihre Integrität prüfen lässt. Auf diese Weise bleiben die Security-Qualität und Widerstandsfähigkeit der Produkte im Feld bestehen.   

Damit das Produkt sicher eingesetzt werden kann, benötigt der Anwender eine ausführliche Dokumentation, etwa über die vorgesehenen Einsatzbedingungen, die Sicherheitsfunktionen, Netzwerkverbindungen und die Integration in zentrale Systeme, beispielsweise zum Benutzermanagement oder zur Security-Überwachung. Der Anwender wird auch darüber in Kenntnis gesetzt, was er für die sichere Verwendung des Produkts in Bezug auf dessen Einrichtung oder Bedienung beachten muss, zum Beispiel wo sich Informationen zu möglichen Schwachstellen und verfügbaren Updates finden lassen. Liegt eine solche Dokumentation vor, kann der Anwender die Security-Eigenschaften und -Qualitäten des Produkts vollständig ausnutzen.   

Schließlich – und in Wirklichkeit schon von Beginn an – sind Prozesse und Verantwortungen zu klären, die Qualifikation der Mitarbeiter sicherzustellen und sämtliche Abläufe zu organisieren. Letztlich muss dafür gesorgt sein, dass kein Produkt freigegeben werden kann, das nicht alle Security-Tests bestanden hat und bei dem nicht sämtliche bekannten Security-Probleme behoben sind. So können Anwender volles Vertrauen in ihren Lieferanten haben. 

Vermeiden eines falschen Sicherheitsgefühls

Spezifische Security-Funktionen, wie die Verschlüsselung oder Zugriffssteuerung, stehen bisher nicht im Mittelpunkt. Die internationale Norm IEC 62443-4-2 beschreibt Security-Funktionen für Komponenten, die im Hinblick auf das Zusammenspiel von Security-Funktionen gemäß IEC 62443-3-3 erforderlich sind. Das alleinige Vorhandensein dieser Funktionen hilft jedoch nur wenig und erzeugt ein falsches Gefühl von Sicherheit, wenn die Funktion oder das gesamte Produkt fehlerhaft implementiert ist. Daher setzt die IEC 62443-4-2 einen sicheren Lebenszyklus gemäß IEC 62443-4-1 voraus.   
Ein Produkt, das im sicheren Lebenszyklus entwickelt und gepflegt wird, zeichnet sich immer durch eine hohe Security-Qualität aus, auf die ein Anwender vertrauen kann. Aufgrund der Zertifizierung seines Lebenszyklusprozesses untermauert der Produkthersteller dieses Vertrauen. Eine Produktzertifizierung nach IEC 62443 baut auf den sicheren Prozess auf und bestätigt die Produkteigenschaften, erfasst allerdings stets lediglich einen bestimmten Zeitpunkt. 

Quelle
(1) https://cwe.mitre.org/data/index.html

Autor
Lutz Jänicke, Corporate Product & Solution Security Officer