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!
Was bedeutet Secure by Design für die Geräteentwicklung? Embedded Secure by Design?
