Security Development Lifecycle

Andrea Gillhuber,

Sichere Produktentwicklung

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.

© Michael715/Shutterstock.com

In den letzten Jahren hat das CERT-Netzwerk gemäß dem Konzept der Common Vulnerability Enumeration, kurz: CVE, jährlich weltweit über 10.000 IT-Sicherheitsschwachstellen in Produkten bekanntgemacht. Sicher gibt es noch weitaus mehr unerkannte oder unveröffentlichte Angriffspunkte. Wie kann also etwas gegen diese Situation unternommen werden?

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.

1. Spezifikation der IT-Sicherheitsanforderungen

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.

Anzeige
Bild 1: Angestrebtes Schutzniveau. © Phoenix Contact

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 (Bild 1).

2. Security-by-Design: belastbares Konzept aufbauen

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 (Bild 2).

Bild 2: Bewertung von Bedrohungen. © Phoenix Contact

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.

3. Sichere Implementierung: (Programmier-)Handwerk verstehen

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.

4. Security-Tests: Vertrauen schaffen

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. Darüber hinaus 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.

5. Security Defect Management: Schwachstellen adressieren

Bild 3: Prinzipielles Vorgehen bei potenziellen Schwachstellen. © Phoenix Contact

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 laufend kontrolliert werden (Bild 3).

6. Security-Updates: Patches bereitstellen

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.  

7. Security-Dokumentation: Handbücher vorhalten

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.  

8. Security-Management: Prozesse und Verantwortungen klären

Bild 4: Gesamtübersicht über den sicheren Lebenszyklus. © Phoenix Contact

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 (Bild 4).

Sicherer Lebenszyklus: Qualität langfristig sicherstellen

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. 

Dr.-Ing. Lutz Jänicke ist Corporate Product & Solution Security Officer bei Phoenix Contact in Blomberg

Literatur
[1] https://cwe.mitre.org/data/index.html

Anzeige

Das könnte Sie auch interessieren

Anzeige

Cybersecurity

Security by Design

Sicherheitsrisiken, insbesondere Cyberrisiken, bei neuen Produkten oder Industrieprozessen von Anfang an zu vermeiden, das ist das Ziel von Security by Design. TÜV Nord ergänzt nun seine Kompetenzen in diesem Bereich mit einer Kooperation mit Silver...

mehr...

Industrie-PCs

Alle Tools an Bord

Die Vorteile von Edge-Anwendungen sind bekannt. Allerdings kann eine traditionelle SPS die anfallenden Daten nicht lokal vorverarbeiten. Mit Edge-PCs inklusive vor­installierter Software-Tools lassen sich IoT-Applikationen einfach umsetzen.

mehr...
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige

Sicherheit im IIoT

Industrial Security 4.0

Das produzierende Gewerbe erfährt durch Edge Computing viele Vorteile: IoT-Geräte, Maschinen und Systeme profitieren von einer geringen Latenz, und sollte das Internet ausfallen, funktionieren IoT-Geräte weiterhin. Doch entstehen durch die...

mehr...

KIT

Sicherheit für eingebettete Systeme

In dem am Karlsruher Institut für Technologie (KIT) koordinierten Projekt Xandar erarbeiten Partner aus Wissenschaft und Wirtschaft eine komplette Werkzeugkette zur Softwareentwicklung und Hardware-Software-Integration für komplexe Anwendungen.

mehr...