• Noser.com
facebook
linkedin
twitter
youtube
  • NOSERmobile
    • Android
    • HTML 5
    • Hybrid Apps
    • iOS
    • Windows Phone
  • NOSERembedded
    • Medizintechnik
  • NOSERprojektmanagement
  • NOSERtesting
  • NOSERlifecycle
    • .NET Allgemein
    • Application Lifecylce Management
    • Apps
    • Architektur
    • ASP.NET
    • Azure
    • Cleancode
    • Cloud
    • Silverlight
    • Visual Studio / Team Foundation Server
    • Windows 8
    • Windows Presentation Foundation
  • NOSERinnovation
    • Big Data
    • Cloud
    • IoT
    • Operations Research
    • Augmented Reality
    • RFID, NFC, Bluetooth LE

Der Safety-Plan: Die wichtigsten Antworten mit Checkliste

28. Oktober 2021
Leuenberger Matthias
0
EN 50126, IEC 61508, IEC/EN 62061, ISO 26262, Safety-Plan, Sicherheitsnachweis
Der Safety-Plan: Die wichtigsten Antworten mit Checkliste

Der Safety-Plan ist DAS zentrale Dokument in jedem sicherheitsrelevanten Projekt. Obwohl sich der technische Inhalt von Projekt zu Projekt oder von Norm zu Norm unterscheidet, gehören doch immer dieselben Themen in den Safety-Plan. Doch was genau ist er und was gehört hinein? Hier die wichtigsten Antworten mit Checkliste!

Safety-Plan

 

Was ist der Safety-Plan?

Der Safety-Plan heisst auch Sicherheitsnachweis und beschreibt, wie die Sicherheit eines Geräts eingehalten wird. Dazu:

  • identifiziert er alle relevanten Tätigkeiten
  • beschreibt er angewandte Methoden
  • beschreibt er getroffene Massnahmen

Wieso braucht es den Safety-Plan?

Laut Gesetz muss jedes Produkt beweisen, dass es nach «State-of-the-Art» entwickelt wurde und die anwendbaren Normen einhält. Erst dadurch besteht bei einem Gerichtsfall ein Anspruch auf die Unschuldsvermutung. Der Safety-Plan beinhaltet genau diesen Beweis.

Die meisten sicherheitsrelevanten Normen fordern zudem explizit einen Sicherheitsnachweis. Z.B. IEC 61508, EN 50126, IEC/EN 62061 oder ISO 26262.

Wer macht den Safety-Plan?

Verantwortlich für den Safety-Plan ist der Safety-Manager. Er erstellt ihn zu Beginn des Projekts und pflegt ihn bis zum Projekt-Schluss. Dazu dienen ihm als Input die wichtigen System-Dokumente, wie z.B. Systemdefinition, Risiko-Analyse oder Projektplan. Zudem wird der Safety-Plan vom Safety-Team und dem Accessor gegengeprüft.

Checkliste: Was gehört hinein?

Folgende Themen gehören in den Safety-Plan:

  • Relevante Tätigkeiten
    Listet anhand des Projektplans alle relevanten Tätigkeiten auf und beschreibt diese. Dabei dürfen Risiko-Analyse und Qualitätssicherung nicht fehlen.
  • Safety-Requirements
    Beschreibt die Massnahmen, Techniken oder Methoden für die Erfüllung der Safety-Requirements.

    Best-Practice Tipp
    Dazu sind die Tabellen Techniken/Methoden aus der zu erfüllenden Norm sehr hilfreich. Am besten 1:1 herauskopieren und zu jedem Punkt beschreiben, wie er erfüllt wird oder eben nicht.

  • Rollen
    Listet alle Rollen im Projekt mit den dazugehörigen Rechten, Pflichten und erforderlichen Kompetenzen vollständig auf.
  • Tools
    Listet alle verwendeten Tools für die Entwicklung und das Qualitätsmanagement auf und klassifiziert diese (siehe IEC 61508 für mögliche Klassen). Essentielle Tools werden zudem beurteilt und validiert.
  • Artefakte
    Listet alle Artefakte auf, welche im Entwicklungs- und Lebenszyklus des Produkts entstehen. Dabei werden zu jedem Artefakt die Ablage und die Verantwortlichkeiten definiert.
  • Dokumentation
    Listet alle Dokumente und deren hierarchischen Aufbau auf. Wichtig dabei sind die Ablage und die Verantwortlichkeiten.

    Best-Practice Tipp
    Bei den Verantwortlichkeiten lohnt es sich, im Detail zu definieren, wer das Dokument erstellt, wer es reviewt und wer es freigibt.

  • Verification & Validation
    Bescheibt die Planung (oder Grobplanung) der V&V-Phase. Somit wird ersichtlich, wie die Sicherheit und die Korrektheit geprüft werden.
  • Configuration-Management
    Beschreibt die Strategie für das Configuration-Management und schafft einen Einblick in den Lösungsansatz.

Was ist das Wichtigste am Safety-Plan?

Der Safety-Plan muss wasserfest sein. Dazu sind ein erfahrener Safety-Manager, ein geschultes Safety-Team und eine gesunde “Safety-Kultur” nötig. Fehlt dem Projekt-Team die nötige Kompetenz dafür, muss sie dringend eingeholt werden!

Best-Practice Tipp
EN 50126 und ISO 26262 haben eine sehr fortgeschrittene Ansicht und vertiefte Informationen über den Sicherheitsnachweis. Somit sind sie quasi «State-of-the-Art» und Grundlage für jeden modernen Safety-Plan.

Damit zum Schluss und dem wohl wichtigsten «Safety-Mantra», welches auch für den Safety-Plan gilt:

Safety muss nicht nur definiert und akzeptiert, sondern auch gelebt werden!

 

 

In 6 Schritten zur sicheren Software

16. September 2020
Leuenberger Matthias
1
Architektur, Funktionale Sicherheit, Medizintechnik, Safety, Softwarequalität

Hast du dich auch schon gefragt:

“Wie mache ich eine gute Software für sicherheitskritische Anwendungen?”

Ich habe dir die besten und wichtigsten Punkte für eine sichere Software zusammengetragen und in einem 6-Schritte-Plan zusammengefasst!

Nun aber zu den Details, damit dir die 6 Schritte auch gelingen!

Schritt 1: Definiere dein Vorgehen

Für deine sichere Software musst du zuerst ein Vorgehen für den gesamten Entwicklungsprozess und Lebenszyklus definieren. Aus Sicht der Normen gehören dazu folgende Punkte:

  • Qualitätsmanagement, also wie kannst du die Qualität mittels Anforderungen, Reviews und Tracing sicherstellen.

  • Risikomanagement, also wie kannst du das Risiko analysieren, erkennen, dokumentieren und bewerten.

  • Softwaresicherheitszyklus, also wie stellst du sicher, dass die Software am Schluss auch das macht was sie soll und keine systematischen Fehler entstehen.

  • Templates und Vorgehensanweisungen für die Architektur-Dokumentation, die Architektur-Bewertung und weitere Artefakte.

Ich hoffe, du hast für diesen Schritt viel Manpower und Erfahrung in deiner Firma zu Verfügung, denn allein stemmen geht hier (fast) nicht.

Schritt 2: Kenne dein Produkt

Damit du die richtige Software erstellst, musst du natürlich dein Produkt kennen. Dazu musst du eine Anforderungsanalyse und eine Risikoanalyse machen. Sie dienen dir als Grundlage für die Qualitäts- und Sicherheitsanforderungen.

Die genaue Kenntnis der Qualitätsanforderungen ist essenziell bei einer Software im normativen Umfeld. Denn nur dadurch kannst du die richtige Architektur erstellen und am Schluss mittels Bewertung richtig analysieren. Achte darauf, dass du die Qualitätsanforderungen mittels Qualitätsszenarios definierst.

Die wichtigsten Qualitätsanforderungen, welche immer wieder im Zusammenhang mit funktionaler Sicherheit fallen und auch in deiner Architektur abgedeckt werden sollten sind:
Korrektheit, Robustheit, Deterministisch, Modular, Kapselung, Einfachheit, Aufdeckung von Fehlern.
Die Qualitätsanforderungen erfüllst du mit den richtigen Methoden, Modulen und Muster.

Die Sicherheitsanforderungen ergänzen die funktionalen Anforderungen, also was will der Benutzer vom System, mit sicherheitskritischen Anforderungen, also alles, damit der Benutzer nicht zu Schaden kommt. Die Risikoanalyse dient hier neben deiner Erfahrung als bester Input. Ein detailliertes Verständnis der Anforderungen und des Umfelds, in welchem die Software eingesetzt wird ist ebenfalls von Nöten.

Nicht zuletzt solltest du in diesem Schritt den Systemkontext definieren. Achte darauf, dass du eine saubere Trennung der Umsysteme und verständliche Verantwortlichkeiten der Schnittstellen notierst.

Und natürlich musst du alle oben genannten Punkte sauber dokumentieren.

Schritt 3: Get Ready!

Bevor du mit der Architektur anfängst empfehle ich dir wärmstens, dich in allen Belangen bereit zu machen. Dazu gehört für mich, dass du:

  • Bereits eine Coding-Guideline aufstellst
  • Deine Toolchain bereits in Betrieb nimmst
  • Dich bereits der Themen Code-Review, Statische Code-Analyse, Testing und Continiuous Integration annimmst

  • Mit DevOps und der Produktion Kontakt aufnimmst

Alle diese Themen musst du nicht fertig abarbeiten, aber sie geben einen solch wichtigen Input für deine Architektur, dass ein herausschieben meist keinen Sinn macht.

Schritt 4: Starte mit Bewährtem

Wenn du eine gute Software machst, startest du immer mit einer Architektur-Vision und Architektur-Prinzipien. Sie zwingen dich – auch wenn du voller Elan und Ideen bist – kurz inne zuhalten und das grosse Ganze in einfachen und verständlichen Punkten zu dokumentieren.

Lehne dich dabei an bestehende Architektur-Prinzipien deiner Firma an! Dies wird die Akzeptanz stark steigern und allen Projektbeteiligten helfen, eine sichere Software zu entwickeln.

In der Architektur-Vision wählst du bereits ein Architektur-Muster und legst damit den wichtigsten Baustein deiner Software. Für Embedded-Systems im normativen Umfeld eignen sich am besten Hierarchische-Systeme. Sie sind aus Bausteinen in unterschiedlichen Ebenen in einer Hierarchie angeordnet.
Der prominenteste Vertreter daraus ist das Schichten-Modell. Es biete gute Lösungen für Themen wie: Modularität, Kapselung, Einfachheit und Determinismus.

Zudem solltest du die folgenden bewährten Module in deine Software einplanen. Sie lösen dir die grundlegendsten querschnittlichen Architektur-Themen:

  • Logger, also zum Loggen von Fehlern und Debug-Informationen aus allen Schichten
  • Error- oder Assert-Handler, also ein systemweiter Anlauf-Punkt für Fehlerhandling
  • Protective/Sanity, ein Sicherheitsmodul, welches viele Sicherheitsanforderungen realisiert
  • SafetyContainers, eine Sammlung an Containers mit sichergestellter Daten-Integrität

Schritt 5: Implementiere sicher

Kommst du zur Realisierung des Systems, musst du auch sicher implementieren. Dazu gehört, dass du Safety-Measures anwendest, auf Fehleraufdeckung achtest und natürlich umfangreich testest.

Die Safety-Measures sind Massnahmen, welche du im Design und der Implementierung umsetzt, um die Software sicher zu gestalten. Die meisten Safety-Measures wurden bereits durch die Risikoanalyse gefunden, die weiteren findest du auf Grund deiner Erfahrung oder der anzuwendenden Norm. Die Safety-Measures, welche ich immer wieder angetroffen habe sind:

  • Bereichsprüfungen an Schnittstellen von Komponenten
  • Prüfung der zwischengespeicherten Daten mit CRC oder redundanten Daten
  • Plausibilitätsprüfungen über verschiedene Daten-Arten
  • Programmflussüberwachung
  • Runtime-Tests zur Sicherstellung der Korrektheit des Prozessors, wie z.B. RAM, ROM
  • Prüfungen auf nullptr
  • Zyklisches verarbeiten und versenden der Daten

Auch beim Klassen-Design gilt es, auf bewährtes zu setzten. Dazu gehören insbesondere Design-Patterns. Die im Safety-Bereich immer wieder angetroffenen sind: Singleton, State, Observer, Factory-Pattern. Achte auch auf saubere Interfaces an Schnittstellen der Komponenten. Dies erleichtert nicht nur die Dokumentation, sondern auch das Testing.

Es ist aber auch wichtig, dass in deiner Software Fehler nicht unbemerkt bleiben. Die Fehleraufdeckung erreichst du, indem du die Fehler in der Hierarchie weiter hinauf gibst und/oder den Error- oder Assert-Handler involvierst.

Natürlich ist Testing auf allen Ebenen auch für dein sichere Software wichtig. Getestet wird wie in anderen Systemen auch. Trotzdem möchte ich dir noch ein paar Punkte mitgeben, welche mich beim Testing nach Norm immer wieder beschäftigt haben:

  • Teste möglichst zeitnah und periodisch.
  • Tests müssen von allen Projekt-beteiligten auch lokal ausgeführt werden können.
  • Achte auf sauberes Tracing zu den Anforderungen.

Schritt 6: Reflektiere

Die Reflexion der entstandenen Software wird meist vernachlässigt. Dabei kann sie sehr viele wichtige Rückmeldungen über verbleibende Risiken geben. Ich selbst durfte auch noch nie ein “schöne” Architektur-Bewertung nach z.B. ATAM durchführen. Dazu fehlten in jedem bisherigen Projekt Zeit und Budget. Es gibt zum Glück aber noch andere Orte, wo Reflexion stattfinden kann!

Wird zum Beispiel die Architektur-Arbeit nicht nur vom Architekten alleine, sondern vom Entwicklungs-Team erledigt, bringt dies bereits bei der Erarbeitung wichtige und kritische Einblicke.

Oder du machst im Entwicklungs-Team kleine Reviews von ausgewählten Aspekten, z.B. in Form eines Walkthrough. Dies bringt trotz der Kürze bereits viele Erkenntnisse und Akzeptanz im Team mit sich.

Nutze auch die Sprint-Reviews, um wichtige Architektur-Entscheide kurz vorzustellen. Da an den Reviews meist ein interdisziplinäres Team anwesend ist, kommen die richtigen Fragen und Risiken werden so besser aufgedeckt.

In einem sicheren System ist zudem meist ein Sicherheitsnachweis normativ gefordert. Er ist eine Beweisführung, warum das System aus Sicht des Autors sicher ist und wie es die normativen Anforderungen erfüllt. Meist wird der Sicherheitsnachweis parallel oder nach der Realisierung-Phase des Projekts von einem Safety-Manager erstellt. Nutze den Austausch mit dem Safety-Manager und arbeitet wo möglich die Verbesserungen ein.

Sind wir nun fertig?

Ja, denn wenn du das alles Umsetzten kannst, hast du deine Software im Griff! Eine Prüfung nach Norm ist dann nur noch eine Formsache. Damit das gelingt und du ein Grossteil mit in dein Projekt nehmen kannst, habe ich die genannten Punkte nochmals zusammen gefasst: “Best Practice” sichere Software.

Viel Erfolg!

12

Tag Cloud

.NET android ANgular Angular Js AngularJs Arduino ASP.Net automated testing Azure Big Data C# C++ Cloud continuous integration Elm Embedded gRPC Internet of Things IoT Java Javascript M2M OWASP Projektmanagement protobuf Python Raspberry Pi Reactive Programming REST Scrum Security Softwarequalität SPA Testen testing Testmanagement Teststrategie Visual Studio WebAPI windows windows phone 8 WPF Xamarin Xamarin.Android Xamarin.Forms

Archive

Current Posts

  • Lasttests mit NBomber
  • Kreative Interaktion mit Xamarin.Forms Touch-Actions
  • Angular vs. React: Ein pragmatischer Vergleich
  • Eine Alternative zu Azure Time Series Insights, bitte?
  • Focus on the Secure Storage service of Trusted Firmware (TFM)

Last Comments

  • Noser Blog Touch-Actions in Xamarin.Forms - Noser Blog bei Mach mehr aus Animationen in Xamarin.Forms mit SkiaSharp
  • Noser Blog Focus on the Secure Storage service of Trusted Firmware (TFM) - Noser Blog bei First run of the Trusted Firmware (TFM) application
  • Noser Blog First run of the Trusted Firmware (TFM) application - Noser Blog bei Focus on the Secure Storage service of Trusted Firmware (TFM)
  • Noser Blog Focus on the Secure Storage service of Trusted Firmware (TFM) - Noser Blog bei Security management with Trusted Firmware
  • Noser Blog ZeroMQ / NetMQ mit Protocobuf - Noser Blog bei Tutorial: Protocol Buffers in ASP.NET Core

Popular Posts

Xamarin.Android Code Obfuscation

6 Comments

ManuScripts: Wenn jemand eine Reise tut... Funktionale Programmierung mit Elm - Teil 1 - Aufbruch

5 Comments

ManuScripts: Wenn jemand eine Reise tut... Funktionale Programmierung mit Elm - Teil 2 - Kein Picknick

4 Comments

Contact us

  1. Name *
    * Please enter your name
  2. Email *
    * Please enter a valid email address
  3. Message *
    * Please enter message
© 2013 NOSER ENGINEERING AG. All rights reserved. Datenschutz | Cookie-Richtlinie