Lesezeit 5 min
Wieso braucht es das?
Lange wurde das Thema Informationssicherheit stiefmütterlich behandelt, denn am Markt ist die Nachfrage nach funktionalen Anforderungen grösser als die Nachfrage nach nichtfunktionalen Anforderungen. Informationssicherheit ist eine nichtfunktionale Anforderung, sie umzusetzen kostet Geld und Zeit. Warum sollten Sie es trotzdem tun?
Das Aufkommen von vernetzten Geräte (IoT, IIoT, Things etc.) führt dazu, dass Geräte welche früher durch ihr Design im vorgesehenen Umfeld sicher waren (keine Verbindung mit dem Internet), neu nicht mehr sicher sind.
Wo stehen wir heute bei embedded Security by Design?
In Gebieten, welche bereits stark reglementiert sind, wie z.B. Medical, Automotive, Avionik, Bahn und Finanzwirtschaft, wurden die entsprechenden Normen bereits angepasst und Informationssicherheit ist Pflicht.
Der Ruf nach (minimal) Standards für alle Branchen wird immer grösser. Es ist abzusehen, dass der Bereich der Informationssicherheit bald reglementiert werden wird, wie dies bereits für die EMV und die funktionale Sicherheit geschehen ist.
Wer fordert Secure by Design?
Vorschriften und Normen, wie z. B. der EU Cybersecurity Act, die IEC 62443 oder die medizinischen Normen 745/2017 (MDR) und 746/2017 (IVDR), fordern, dass bei der Entwicklung und dem Betrieb von Geräten das Prinzip Secure by Design angewendet wird.
Was bedeutet Secure by Design?
Die IEC 62443 hat einen eigenen Normenteil, der sich mit diesem Thema auseinandersetzt, nämlich Teil 4-1: Secure product development lifecycle requirements.
Auch die Medical Device Coordination Group verfolgt mit ihrer Handlungsempfehlung MDCG 2019-16 (Guidance on Cybersecurity for medical devices) den Ansatz Secure by Design.
Das verwendete Vorgehensmodell definiert acht Praktiken und verfolgt eine Defense-in-Depth-Strategie.
Praktiken für einen Security-Entwicklungslebenszyklus (Secure Development Lifecycle, SDL)
Alle Praktiken zusammen definieren die notwendigen Prozesse, die vorhanden und etabliert sein müssen um Secure by Design, und somit die Defense-in-Depth-Strategie, über den gesamten Gerätelebenszyklus zu garantieren. Die Praktiken werden oft iterativ angewendet.
Weiter definiert die IEC 62443 ein Reifegradmodell, welches sich an CMMI anlehnt, um die Erfüllung der Anforderungen bezüglich Informationssicherheit zu belegen. Ziel des Reifegradmodells ist es, dass die Entwicklungsorganisation die Qualität der Informationssicherheit zeigt, und dass der Geräteanwender bewerten kann, ob die Qualität für den vorgesehenen Einsatzzweck genügt.
Praktik 1 - Sicherheitsmanagement (Security Management)
Stellen Sie sicher, dass alle sicherheitsrelevanten Aktivitäten während des gesamten Lebenszyklus des Gerätes geplant, dokumentiert und ausgeführt werden.
Dazu erstellen Sie am besten einen Sicherheitsplan, analog einem Safetyplan in der funktionalen Sicherheit.
Praktik 2 - Spezifikation von Sicherheitsanforderungen (Specification of Security Requirements)
Stellen Sie sicher, dass die Anforderungen an die Informationssicherheit des Gerätes und der angenommene Sicherheitskontext dokumentiert sind.
Am Anfang der Spezifikation steht die Erstellung eines spezifischen Bedrohungsmodells für das Gerät. Ziel dieses Modells ist es, systematisch potenzielle Bedrohungen, wie z. B. strukturelle Schwachstellen oder das Fehlen geeigneter Schutzmassnahmen zu identifizieren, und daraus die Sicherheitsanforderungen für das Gerät abzuleiten. Die Anforderungen müssen den gesamten Lebenszyklus berücksichtigen, d. h. von der Entwicklung bis zur Ausserbetriebnahme des Gerätes.
Es ist essenziell, dass das Modell regelmässig überprüft und bei Bedarf (z. B. als Reaktion auf das Auftreten neuer Bedrohungen) aktualisiert wird, auch wenn sich das Gerät selbst nicht ändert.
Die Dokumentation des angenommenen Sicherheitskontext stellt sicher, dass die Entwickler und die Anwender das gleiche Verständnis haben, wie das Gerät bestimmungsgemäss zu nutzen ist. Z.B. klärt es Fragen wie: Gibt es einen physikalischen Geräteschutz? Steht das Gerät hinter einer Firewall? Diese Informationen helfen den Entwicklern geeignete Designentscheidungen zu treffen.
Praktik 3 - Sicherheit durch Design (Security by Design)
Stellen Sie sicher, dass in allen Phasen der Entwicklung, d.h. von der Systemarchitektur bis zum Detaildesign, die Informationssicherheit des Gerätes berücksichtigt wird.
Dies ist der eigentliche "technische" Teil von Secure by Design, der z.B. in "Secure by Design, Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software " von CISA stark betont wird.
Hier stehen besonders die internen und externen physikalischen und logischen Geräteschnittstellen im Fokus, welche identifiziert und charakterisiert werden müssen.
Weiter sind mehrere Verteidigungsschichten (Defense-in-Depth-Strategie) vorzusehen. Dies bedeutet: Jede Schicht hat eine zugewiesene Verantwortlichkeit und reduziert die Angriffsfläche der nächsten Schicht. Jede Schicht muss davon ausgehen, dass die unterliegende Schicht kompromittiert sein kann. Das Design der Schichten erfolgt auf der Basis des Bedrohungsmodells (Praktik 2) und folgt einem risikobasierten Ansatz.
Auch müssen aktuelle sicherheitsrelevante Technologien, wie z. B. Secure Boot, verschlüsselte Kommunikation etc., angewandt werden.
Praktik 4 - Sichere Implementierung (Secure Implementation)
Stellen Sie sicher, dass die Sicherheitsanforderungen für Hard- und Software korrekt implementiert sind.
Dies erfolgt mittels Vorgaben (Design-Vorgaben, Programmierrichtlinien etc.) und Reviews (Peer-Review, statische Codeanalyse etc.).
Praktik 5 - Verifikation und Validation der Informationssicherheit (Security Verification and Validation)
Stellen Sie sicher, dass das Gerät alle Sicherheitsanforderungen erfüllt und dass alle Test-Aktivitäten dokumentiert sind.
Die Sicherheitstest erfolgen an unterschiedlichen Zeitpunkten im Entwicklungszyklus und decken folgende Aspekte ab:
- Testen, dass alle Sicherheitsanforderungen (Praktik 1) erfüllt sind
- Testen der Wirksamkeit der Bedrohungsabwehr (z. B. Testen jeder einzelnen Schicht einer mehrschichtigen Verteidigungsstrategie)
- Prüfung auf bekannte Schwachstellen (z. B. MITRE, OWASP)
- Penetrationstest (entdecken von Schwachstellen)
Die Tests können automatisch (Unit-Test, Fuzzing, Schwachstellen-Scanner etc.), manuell (Testlisten, Penetrationstest etc.) oder kombiniert erfolgen.
Praktik 6 - Management von sicherheitsrelevanten Sachverhalten (Management of Security-Related Issues)
Stellen Sie sicher, dass alle gemeldeten Sicherheitsprobleme aufgenommen und entsprechend den anderen Praktiken behandelt werden.
Mögliche interne und externe Quellen, die Sicherheitsprobleme entdecken und melden, sind:
- Tester (Verifikation und Validation)
- Lieferanten von Drittanbieter-Komponenten
- Geräteanwender (Integratoren, Servicepersonal etc.)
Praktik 7 - Verwaltung von Sicherheitsupdates (Security Update Management)
Stellen Sie sicher, dass für ein Gerät rechtzeitig Sicherheitsupdates zur Verfügung gestellt werden.
Die Sicherheitsupdates müssen mindestens auf Regression getestet werden.
Praktik 8 - Sicherheitsrichtlinien (Security Guidelines)
Stellen Sie sicher, dass eine Benutzerdokumentation existiert, die beschreibt wie das Gerät sicher zu konfigurieren, betreiben, warten und entsorgen ist.
Besonders wichtig ist, dass der Anwender weiss, in welchem Kontext das Gerät sicher verwendet werden kann.
Was müssen Sie tun, um Secure by Design zu leben?
Wer bereits eine etablierte Prozesslandschaft für die Entwicklung hat, z. B. CMMI oder aSPICE, für den ist der Schritt klein. Definieren Sie Prozesse für die neuen Praktiken, und fügen Sie diese Prozesse zu Ihrer Prozesslandschaft hinzu. Schulen Sie Ihre Mitarbeiter und verwenden Sie die Erkenntnisse aus Ihren Entwicklungsprojekten, um iterativ Ihre Informationssicherheits-Prozesse zu verbessern.
Wenn Sie noch keine geeignete Prozesslandschaft haben, ist es jetzt der richtige Zeitpunkt, um sich damit zu befassen. Um das Thema Informationssicherheit kommt niemand mehr herum. Und wie in diesem Blog dargestellt, sind Prozesse das A und O für Security by Design, auch für embedded Security by Design.
Benötigen Sie Wissen oder Unterstützung für das Erstellen von Entwicklungs-Prozessen oder bei der Umsetzung Ihres Entwicklungsprojektes? Wir unterstützen Sie gerne dabei!
Alois Cavelti
Haben Sie zusätzliche Fragen? Haben Sie eine andere Meinung? Wenn ja, mailen Sie mir oder kommentieren Sie Ihre Gedanken unten!
Autor
Keine Kommentare