- BSI Leitfaden einbauen
- AAMI 57 durchgehen
- UL 2900 durchgehen
- Prozessanforderungen spezifischer formulieren
- Fehlende Links einfügen
- Feedback von Olaf Teichert einarbeiten
- Checkliste nach Produkt und Prozess umsortieren
- Feedback von IT Sicherheitsexperten des TÜV Süd einbauen
- Hinweise geben, wie man mit Risiken umgeht (s. Kommentar von Andreas unten)
- Definitionen ergänzen oder referenzieren oder Anhang löschen
- Anforderungen durchnummerieren
- Fußnoten neu durchnummerieren
- Leitfaden ins Englische übersetzen
Risikomanagement: Ich stimmt Dir Georg insofern zu, dass die Cybersecurity Risiken anderes zu betrachten sind, als andere Risiken. Ich halte aber die ISO 14971 durchaus für geeignet. @Christian Johner (Johner Institut GmbH): vielleicht können wir im Rahmen unseres Papiers noch ein wenig erläutern, wie das mit Wahrscheinlichkeit und Risiko zu verstehen ist:
- Beim Schweregrad ist nicht nur der einzelnen Patienten zu betrachten, sondern auch die Tragweite abzuschätzen. Sprich, ob ein Risiko z.B. ein ganzes Krankenaus oder nur einen einzelnen Patienten betrifft.
- Bei der Ermittlung der Wahrscheinlichkeit der Gefährdungssituation sind zwei zusätzliche Aspekte zu berücksichtigen. Die Wahrscheinlichkeit ist höher einzuschätzen, wenn ein Angreifer einen hohen Nutzen von einem Angriff hat. Die Wahrscheinlichkeit ist ebenfalls höher einzuschätzen, wenn der Angreifer nur einen niedrigen Aufwand treiben muss.
1.) Die Behörden (BfArM hat es ja im Juni laut herumgetönt, die neue ISO 14971 wird es auch aufgreifen), werden die Berücksichtigung von Cyber-Attacken in der Safety-Analyse unter dem Begriff "foreseeable misuse" einordnen. Der Leitfaden sagt fast nichts zu den VERFAHREN solcher Analysen und dem Zusammenhang zur ZWECKBESTIMMUNG und EINSATZUMGEBUNG. Wir überlassen es also dem Hersteller, da im Einzelfall selber festzulegen, was er denn als "foreseeable" betrachtet. Ist im Moment auch besser so, da der Begriff "foreseeable" gerade in Bezug auch Cyber-Attacken in den letzten Jahren viele Szenarien zusätzlich abdecken muss und dieser Trend noch weiter geht. Der Bedeutungskreis dieses Wortes wächst somit seit etwa zehn Jahren und Hersteller rennen diesbezüglich den Behörden und Gesetzgebern hinterher. Ist nun mal so.
2.) Als Verallgemeinerung von 1.) kann man überhaupt mal fragen, ob nicht der gesamte Prozess des Safety-Risk-MANAGEMENT auch die Bestimmung der 'Mitigations' systematisch und vollständig alle notwendigen Security-Controls herleiten würde. Weiter gedacht: Mit dem perfekten Safety-Prozess bräuchte man überhaupt keine Liste von Security-Controls . Extrem gesagt: Das Kapitel "Produkt-Anforderungen" wäre theoretisch gar nicht nötig, weil ja alle Security-Controls als 'Mitigations' aus der Safety-Analyse purzeln würden. (( Die heutige Wahrheit ist wohl, dass mancher SW-Designer und Produktmanager dankbar für jede Art von Checkliste ist- ich bin's auch )) Fazit: Der Leitfaden heute leistet mit der Liste der Anforderungen das wichtigste für die angemessenen Controls, ideal wäre ein perfekter Safety-Prozess.
3.) In Zukunft werden Supply-Chain-Attacken über die IT-Arbeitsplätze der Entwickler und über zugekaufte Hardware, Tools, Libraries, Middleware das ganz große Thema. An allen Leitfäden, Checklisten und Prozessen vorbei ist dann die Malware schon mit Auslieferung im Produkt - schöne Aussichten ! Fazit: Der Leitfaden sagt nichts über die Errichtung einer sicheren Office- Infrastruktur und wenig über "trusted supply chain management" - also die "Digitalisierung von Vertrauen in Zulieferer".
Alle diese Trends verschieben natürlich den Fokus vom Produkt zum Prozess und die Mühen der Produkt-Zertifizierung würden dadurch stark reduziert.