Kategorien: Software & IEC 62304
Tags:

9 Kommentare

  1. Peter Pianegonda | Dienstag, 20. November 2018 um 10:24 Uhr - Antworten

    im Navigator zuoberst rechts hat es einen kleinen Druckfehler:

    IST 62443-5-1
    SOLL 62443-4-1

    Vielen Dank für das Lesen, Zusammenfassen und Aufbereiten.

    Peter Pianegonda


    • Prof. Dr. Christian Johner | Dienstag, 20. November 2018 um 16:17 Uhr - Antworten

      Sie haben ja so Recht! Danke, lieber Herr Pianegonda!

      Danke Ihrer Hilfe konnte ich den Fehler korrigieren. Danke!


  2. Cord | Montag, 26. November 2018 um 09:40 Uhr - Antworten

    Hallo,
    wo ist denn der Leitfaden von Ihnen und dem TÜV Süd verfügbar?


  3. Christian Beck | Montag, 28. Januar 2019 um 11:00 Uhr - Antworten

    Hallo Herr Johner,
    sie schreiben in ihrem Leitfaden: „Es besteht in Europa (im Gegensatz zu den USA) auch keine Pflicht, ein spezifisches Dokument zur IT-Sicherheit
    zu erstellen.“
    Frage dazu: Ist mit dem spezifischen Dokument hier die „Cybersecurity Bill of Materials (CBOM)“ gemeint?
    Viele Grüüße, C. Beck


  4. Gilbert Semmer | Freitag, 22. Februar 2019 um 08:49 Uhr - Antworten

    Hallo Christian,
    mal wieder eine super Analyse und Darstellung eines Standards 🙂
    Mir fällt dabei auf, dass keine der 57 Aspects oder 8 Practises „Security Risk“ explizit benennt.
    Risk Management ist ja ein zentraler Aspekt bei Medical Devices (MD), insbesondere vernetzte MDs (ISO/IEC 80001 family).
    Die AAMI TIR57 stellt den Zusammenhang zwischen Security & Safety Risks gut dar, orientiert sich dabei aber leider an NIST 800, die eher ganze Organisationen betrifft.
    Vielleicht sollte man als Fazit darauf hinweisen, dass es eine spezifische IEC 62443-3-2 „security risk assessment process“ als der der Standards-Family gibt. Dies sollte meiner Ansicht nach ein zentraler Teil eines Secure product development lifecycle sein.
    Note: „security risk assessment“ ist sehr spezifisch, braucht damit spezielle Guidelines (s.a. AAMI TIR57), und es reicht nicht, dies mit einem Satz a là „risk management requirements are woven into the requirements throughout the product life cycle“ abzuhandeln.

    Beste Grüße
    Gilbert


    • Prof. Dr. Christian Johner | Freitag, 22. Februar 2019 um 09:31 Uhr - Antworten

      Lieber Gilbert, ich stimme Dir absolut zu! Das werde ich aktualisieren!

      Im IT-Security-Leitfaden haben wir die Aktivitäten explizit in den Software-/Produktlebenszyklus mit eingewoben. Dieser Leitfaden wird inzwischen auch bei Behörden und benannten Stellen als Standard referenziert, genannt und genutzt.

      Liebe Grüße, Christian


  5. Felix Schirmer | Donnerstag, 18. Juli 2019 um 10:23 Uhr - Antworten

    Naja, also ob die 62443 so empfehlenswert ist, da bin ich mir nicht sicher. Wir fertigen beispielsweise Produkte für Industriekomponenten und überlegen, nach -4-2 zertifizieren zu lassen. In der -4-2 steht drin, als common requirement, dass die Komponente nach -4-1 entwickelt worden sein muss. Eine explizite Anforderung, ob jetzt eine -4-1 Zertifizierung erforderlich ist, steht allerdings nicht drin. Und obwohl wir bei uns natürlich nach modernem SDLC entwickelt und so wohl auch die Anforderung nach -4-1 bestehen würden, kriege ich von KEINEM der üblichen Verdächtigen Zertifizierer eine klare Antwort auf die popeleinfache Frage:

    Brauche ich eine -4-1 Zertifizierung als Vorbedingung für eine -4-2 Zertifizierung?

    Neee. Nur rumgewiesel „lassen Sie uns telefonieren“ blabla „kommt drauf an“. Auf eine JA oder NEIN Frage. Unfassbar, dass so eine simple Fragestellung mit HORRENDEN Auswirkungen auf die Zertifizierungskosten von der 62443 nicht KLIPP UND KLAR geregelt ist. Das ärgert mich.


    • Prof. Dr. Christian Johner | Donnerstag, 18. Juli 2019 um 14:44 Uhr - Antworten

      Sehr geehrter Herr Schirmer,

      danke für Ihre Gedanken.

      Es geht in diesem Beitrag nicht um eine Zertifizierung. Eine Zertifizierung unter dem Dach der DaKKS gibt es für Medizinprodukte auch gar nicht. Damit sind alle entsprechenden Zertifikate nur bedingt wertvoll und erzwingen v.a. keine Konformitätsvermutung.

      In anderen Beiträgen u.a. zur „Zertifizierung nach IEC 62304“ warnen wir sogar vor Beutelschneiderei durch Zertifzierungen.

      Beste Grüße, Christian Johner


Hinterlassen Sie einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.