Was ist ein Secure Development Lifecycle?
Der ursprünglich von Microsoft entwickelte Sichere Entwicklungszyklus bzw. Secure Development Lifecycle (SDL) beschreibt Prozessanforderungen, die in der Produktentwicklung und in der Wartung zu berücksichtigen sind. Beispiele für solche Anforderungen sind:
- Threat Modeling/Bedrohungsanalyse: sie dient zur Identifikation und Behandlung von Cyber Security Bedrohungen bereits während der Produktentwicklung
- Secure by Design: Das Produkt wird nach „Cyber Secure“ sicheren Gesichtspunkten entwickelt. Dabei werden beispielsweise physische und logische Schnittstellen betrachtet.
- Security-Issue Handling/Schwachstellen Management: Beschreibt die Behandlung von Schwachstellen/Vulnerabilities im Produkt in der Wartungsphase.
Die einzelnen SDL-Anforderungen werden oft Phasen zugeordnet, siehe die folgende Grafik.
Das Ziel eines SDL ist Produkte nach modernen und sicheren Methoden zu entwickeln und zu warten. Auch die kontinuierliche Produktweiterentwicklung wird abgedeckt.
Secure Development Lifecycles sind mittlerweile Teil verschiedener domänenspezifischer Cyber Security Standards, z.B.:
- in der Industrieautomatisierung die IEC 62443-Serie
- in der IT die ISO 2700x-Serie
- im Bereich der Kraftfahrzeuge die ISO 21434
Dieser Artikel fokussiert sich auf die IEC 62443 Serie. In der IEC 62443 adressiert der SDL nicht nur Software-Aspekte, sondern auch Hardware- und Firmware-Aspekte.
Warum braucht es einen SDL?
Oder – Wie hängen eigentlich ein Secure Development Lifecycle und Security Features/Eigenschaften zusammen?
Die Motivation für einen SDL aus Sicht von beteiligten Stakeholdern möchte ich aus dem Blickwickel eines einfachen Beispielszenarios beschreiben.
Stellen wir uns einen Kundenwunsch nach einer „Cyber Secure“ sicheren Edge Controller Lösung vor. Der anzuschaffende Edge Controller soll Roboterdaten sammeln und unidirektional in die Cloud zur dortigen Auswertung schicken. Der Anlagenbetreiber möchte mit dieser Investition, die Effizienz seiner Produktion steigern und mögliche Wartungen rechtzeitig erkennen können.
Es ist nicht ungewöhnlich das Cyber Security als einzelne Produkteigenschaft verstanden wird.
So hat man das Bild von einer Art Security Checkbox vor sich, die erfüllt ist oder eben nicht.
Bei näherer Betrachtung der scheinbar singulären Produkteigenschaft Cyber Security erkennt man einzelne Eigenschaften wie verschlüsselte Netzwerkkommunikation, Benutzerverwaltung, oder die Updatebarkeit des Edge Controllers. Also einzelne Cyber Security Features/Eigenschaften die ein Produkt unterstützt.
Was hat nun die Produkteigenschaft Updatebarkeit des Edge Controllers mit einen SDL zu tun?
Kurzum: Ohne einen SDL gäbe es keine sicher funktionierende und robust ins Produkt integrierten Softwareupdates und Patches. Ein SDL befähigt beispielsweise den Komponentenhersteller des Edge Controllers die Softwareupdates und Patches sicher ins Produkt zu integrieren.
Wer hat Interesse an einen SDL?
Das Interesse an einen SDL beginnt nicht selten mit der Begründung „weil der Kunde Cyber Security fordert“ 😄
Warum auch nicht?
Es mag eine nüchterne Anforderung im Vertrag sein. Aber ein Anlagenbetreiber wünscht sich verständlicher Weise sein Maschinen-Ausfallrisiko aufgrund von Cyber Security Vorfällen zu minimieren. Außerdem haben Betreiber ein Interesse daran regulatorische Cyber Security Anforderung z.B. im Bereich der der kritischen Infrastruktur einzuhalten.
Aus Sicht des Anlagenbetreibers kann dieses Ziel unter anderem dadurch erreicht werden, wenn alle Dienstleister und Zulieferer eine sichere Produktentwicklung und Wartung umsetzen. Am Beispiel des neu anzuschaffenden Edge Controllers zur Datensammlung in der Cloud ergibt sich beispielsweise folgende – vereinfachte – Supply Chain.
Der Maschinenbauer möchte in dieser Kette dem Betreiber gegenüber eine „Cyber Secure“ sicheren Edge Controller Lösung anbieten. Seinerseits soll das Risiko einer mangelhaften Umsetzung von Cyber Security Eigenschaften in verwendeten Komponenten reduziert werden.
Der Komponentenhersteller und dessen Dienstleister und Zulieferer wiederum möchten dem Maschinenbauer gegenüber einen plausiblen Nachweis von robust und modern entwickelter Soft-, Hard-, und Firmware geben. Außerdem möchten sie ihre Produktattraktivität durch das Plus an „integrierter“ Cyber Security steigern.
Alle Beteiligten eint die Sicherung des aktuellen und künftigen Geschäfts, durch Cyber Secure entwickelte Produkte.
Zusammengefasst: Der Forderung nach einem „Cyber Secure“ sicheren Produkt nähert man sich, wenn alle Beteiligten einen SDL folgen. Nicht zuletzt durch diese Verkettung haben alle ein Interesse an einen SDL.
Offensichtlich ist es insbesondere für dem Anlagenbetreiber und den Maschinenbauer hilfreich, wenn Komponentenhersteller oder Applikationsentwickler nach branchenüblichen SDLs, wie der IEC 62443-4-1 entwickeln. Eine Auditierung, eine Supplier Bewertung kann hier leichter ohne Normtransfers durchgeführt werden.
Wie viel Aufwand ist es einen SDL im Unternehmen einzuführen?
Vorab ist unbedingt erforderlich, dass das Unternehmensmanagement die Einführung und Umsetzung eines SDLs unterstützt. Dieses Bestreben verursacht in jedem Fall Aufwände.
Eine pauschale Antwort nach erwartbarem Aufwand gibt es nicht – wie vermutlich zu erwarten war 😉 Ich möchte aber die Einflussgrößen aufzeigen, die den individuellen Aufwand abschätzbarer machen.
Ein SDL beschreibt Prozessanforderungen, die in der Produktentwicklung und Wartung zu berücksichtigen sind. Je nach prozessreife eines Unternehmens gibt es möglicherweise bereits Produktentwicklungsprozesse oder Managementprozesse, wie z.B. Qualitätsmanagement nach ISO 9001. Auf ein solches Prozessfundament kann aufgebaut werden.
Außerdem bietet sich ein iteratives Vorgehen an, um das Unternehmen zur SDL-Reife zu führen. Einzelne Teilorganisationen, z.B. Produktgruppen können voraussichtlich leichter neue/angepasste Prozesse adaptieren als gleich die gesamte Organisation.
Hierbei sollten die Verantwortlichen aber nicht die unternehmensweit gültigen Prozesse aus den Augen verlieren. Vermutlich ist es nicht im Interesse des Unternehmens am Ende einen Blumenstrauß aus einzelnen SDL-Prozessen zu haben.
Auch die notwendige fachliche Expertise für den Entwurf der Prozesse ist zu berücksichtigen. In der Konsequenz ist dann auch die notwendige Cyber Security Expertise der einzelnen Mitarbeiter zu vermitteln. Die definierten SDL-Prozesse sollen ja auch gelebt werden können. Siehe hierzu auch den Artikel Security Expertise im Automatisierungsunternehmen aufbauen.
Des Weiteren beeinflusst der angestrebte Reifegrad des SDL den erwarteten Aufwand.
Das Spektrum reicht hier von schlicht dokumentieren Prozessen bis hin zu nachweisbar durchgeführten Prozessschritten mit Evidenzen und entsprechenden Prozessmetriken. Und schließlich muss eine mögliche Prozesszertifizierung noch berücksichtigt werden.
Und noch eine Überlegung
Ich empfehle am Anfang des Wegs nicht den Anspruch zu erliegen aus dem Stand alles perfekt umsetzen zu wollen.
Wichtig ist, dass man sich auf den SDL-Weg macht. Das Stichwort hier ist „Continuous Improvement“, also die kontinuierliche Verbesserung. Dieser Schritt ist beispielsweise explizit Teil der IEC 62443-4-1. Jeder zusätzliche Angriffsvektor und jede weitere Secure Design Entscheidung, die bei der Entwicklung des Edge Controllers berücksichtigt werden, machen das Produkt sicherer. Daran haben alle Beteiligten ein Interesse.