Rettet unsere DIY LOOP SYSTEME

Wäre ganz nett wenn man sich da nicht anmelden müsste. Und hier doch etwas mehr stehen würde als einfach nur ein Link.

Sofort erledigt.

dito - war ganz gut, dass ein non-FB-Link dabei war...

Darum geht es:

https://www.federalregister.go…v5bUO4-8f3a8LDbgS2WyjabMs

Und hier kann man dem widersprechen:

https://t.co/5ce60fPTbV 

Im LC gibt es dann noch Textvorschläge, aber die möchte ich nicht einfach klauen...

killler23436 hat dort auch erlaubt/erwünscht zitiert...

Zitat

killer25436

Vorgeschlagener Text aus dem erwähnten Facebook-Post (Das Teilen wird dort explizit gewünscht):

„I live with insulin-requiring diabetes, an incurable chronic disease requiring continuous monitoring of blood glucose values and administration of insulin. It is imperative that access to my own devices remains possible. The ability to receive glucose values from my continuous glucose monitor and the ability to command my insulin pump to deliver insulin are already permitted and expected of me. In fact, if I don’t do these, I will die. So please do not let medical device manufacturers use cybersecurity as a pretense to prevent me from accessing my own devices.“

Es wird weiter darum gebeten, bei der Nennung seines Namens, alternativ auch bei einer anonymen Eingabe, ein „pwd“ oder „t1d“

z. B. „Sally Smith, T1D“, einzufügen. So soll gezeigt werden, dass man zur „Community“ gehört.

Alles anzeigen

Danke heikeov, dann kann ich mir das Copy&Paste sparen. 👍

Erledigt.

Ist erledigt.

Gibts dazu nen Blogpost oder ähnliches? Ich verstehe den groben Kontext (Cybersecurity als Vorwand, den Datenaustausch zwischen Geräten weiter zu verschließen). Aber gibts dazu ne Übersicht, was genau passieren würde, wenn das durchgeht?

Z.B. die Dash-Implementation in AAPS ist ja komplett inoffiziell, ebenso die BYODA-Geschichte. Welche Cybersecurity-Maßnahmen würden da im Raum stehen, die diese "Zugriffsarten" blockieren würden? Und könnten solche Maßnahmen überhaupt in den momentanen Stand der bereits zugelassenen Geräte implementiert werden? Oder wird es sich um zukünftige Geräte drehen, die dann später erst auf den Markt kommen?

Der originale Text ist ja doch heftiger Corporate-Sprech und dazu noch auf nicht dem leichtesten Englisch.

Wenn ich das richtig verstanden habe geht es darum das Zugriffsmöglichkeiten dicht gemacht werden auf Daten von Pumpen, Messgeräten, ..... aufgrund von Cybersecurity Gründen?
Das würde dann bedeuten das für DIY kein Zugriff mehr auf die Daten möglich ist und damit DIY nicht mehr mögliche ist.

Das wird eine Katastrophe sein!

na ja, nicht mehr möglich... es muss ja eine Schnittstelle zur Weiterverarbeitung geben, sonst blieben die Daten ja im Sensor stecken und nützen Niemandem mehr, also ist es (theoretisch) auch wieder hackbar. Die Frage ist, wie groß der Aufwand ist und wie groß die Frusttoleranz bei den Entwicklern ist, das auch zu tun *örks*

Dann sollen sie halt EINE vernünftige Software entwickeln und alle Pumpen und Sensoren damit kompatibel machen, dann nehm ich auch einen kommerziellen Loop

Das Draft von der FDA für diese Guideline findet sich übrigens hier:

https://www.fda.gov/media/119933/download

Liest sich erstmal wie'n Stein.

Ich schau da mal später rein, aber solche Dokumente sind echt schwer zu interpretieren, wenn man nicht zu 100% in der Materie steckt. Und selbst wenn, wird man eigentlich für das Lesen von so nem Teil amtlich bezahlt.

Zitat von Marani

na ja, nicht mehr möglich... es muss ja eine Schnittstelle zur Weiterverarbeitung geben, sonst blieben die Daten ja im Sensor stecken und nützen Niemandem mehr, also ist es (theoretisch) auch wieder hackbar. Die Frage ist, wie groß der Aufwand ist und wie groß die Frusttoleranz bei den Entwicklern ist, das auch zu tun *örks*

Dann sollen sie halt EINE vernünftige Software entwickeln und alle Pumpen und Sensoren damit kompatibel machen, dann nehm ich auch einen kommerziellen Loop

Ich sehe die Idee hinter offen Schnittstellen ganz klar aber ich verstehe auch das die Firmen das nicht machen.

Soweit ich das sehe, sind die offenen Schnittstellen sowieso in der Minderheit. Meiner Kenntnis nach sind nicht viele Pumpen so offen wie z.B. die Dana.

Die Dash (link) und wohl auch die Tandem sind ACE-enabled, das weiß ich.

Es scheint ja hauptsächlich die DIY-Loops zu betreffen, die offene Schnittstellen nutzen, die gewollt offen sind. Ich wär jetzt mal so frei zu behaupten, dass die meisten DIY-Loops (abgesehen von den komplett so gewollten Pumpen wie Dana) irgendwelche Lücken nutzen oder sich als Steuergeräte "ausgeben". Da das sowieso keine geplanten Lücken sind, werden diese durch die Guidance Notes gar nicht erfasst.

Was passieren könnte, wäre, dass die Entwickler bestehende Sicherheitslücken von einer Systemversion zur nächsten schließen. Aber sowas kann jederzeit auch ohne die FDA Guidances passieren.

Allgemein müsste man mal schauen, ob was für einen Dokumentenentwurf es hier geht (link

Zitat

About FDA Guidances

Guidance documents represent the Agency's current thinking on a particular subject. They do not create or confer any rights for or on any person and do not operate to bind FDA or the public. An alternative approach may be used if such approach satisfies the requirements of the applicable statute, regulations, or both. For information on a specific guidance document, please contact the originating office. Another method of obtaining guidance documents is through the Division of Drug Information.

Es handelt sich also bei den Guidances um weniger strenge Dokumente als z.B. Gesetze. Aber sie spiegeln die "Politik", die die FDA (auch bei Zulassung) sich auferlegt, wieder. Sie entsprechen also ein bisschen auch dem Charakter einer Norm (Standard). Da aber die FDA auch Normen veröffentlicht, wäre die Wortwahl wohl etwas falsch.

Zu viel darf an den Geräten im Nachhinein auch nicht geändert werden, ohne dass eine erneute Zulassungsprüfung oder eine Art Delta-Review gemacht werden muss. Daher müsste man sich mit der Weltuntergangsstimmung auch etwas zurückhalten können.

Cybersecurity ist ein großes Thema in der Industrie. Für manche Wirtschaftsfelder gibt es keine normativen (also ISO-Normen, EN, etc) Regulierungen, denen man in Sachen Cybersecurity folgen muss. Für den Automotive-Bereich z.B. hat sich erst in den letzten 10 Jahren was getan (IEC_62443, etc), manches sogar erst letztes Jahr.

Ich habe die FDA-Guideline, um die es hier geht, bisher nur überflogen. Aber soweit ich das seh (oberflächlich, wirklich!) scheint es hauptsächlich darum zu gehen, dass Cybersecurity-Aspekte in die Entwicklung und Zulassung von medizinischen Geräten einfließen sollen. Für vernünftige Cybersecurity müssen eine Menge strikte Vorkehrungen getroffen werden, was an sich auch sinnvoll ist. Leider beißt sich vernünftige Cybersecurity leider mit vielen Bequemlichkeiten aus dem Alltag.

Zitat

A Secure Product Development Framework (SPDF) may be one way to satisfy QSR
149 requirements
150 Cybersecurity threats have the potential to exploit one or more vulnerabilities that could lead
151 to patient harm. The greater the number of vulnerabilities that exist and/or are identified over
152 time in a system in which a device operates, the easier a threat can compromise the safety
153 and effectiveness of the medical device. A Secure Product Development Framework (SPDF)
is a set of processes that help reduce the number and severity of vulnerabilities in products.1

Alles anzeigen

Hier mal aus der Einleitung. So ein SPDF (link) ist an sich sinnvoll. Ich bin mit dem Vorläuferkonzept SDLC nicht vertraut, aber solche Vorgänge machen sinn. Problem ist nur, dass wir fürs Loopen halt Schwachstellen ausnutzen. Ein DIY-Looper nutzt u.U. die selben Einfallswege wie ein Hacker.

Jetzt bin ich beim Tippen doch ins Dokument gegangen. Args. Hier meine Einschätzung soweit (ohne Gewähr):

1. Introduction, Scope, Background (Formalitäten) (Seite 1-3)
2. General Principles (Quasi die Einleitung, warum CySec wichtig ist, weitere Formalitäten) (Seite 4-7)
3. SPDF (ein Framework, an dem mach lang entwickeln kann - quasi eine Box an Werkzeugen und Prozessen, die in der Entwicklung eines Geräts genutzt werden müssen oder sollen, damit genügend Cybersecurity gewährleistet wird) wird vorgestellt. Hier müsste man schauen, was relevant ist. Vermutlich nicht viel, da dies nur neu entwickelte Geräte betrifft. (Seite 8-16)
4. Security Architektur (eine weitere Forderung an die medizinischen Geräte) (Seite 16-20)
5. Security Testing (relevant für die Entwicklung, nicht für den Endnutzer) (Seite 22-23)
6. Security Transparenz (Hab ich noch nicht angeschaut) (Seite 24-27)
7. Anhänge (noch nicht angeschaut)

Wichtig wäre zu wissen:

• Müssen solche Guidelines bei bestehenden Zulassungen (also die Geräte, die wir momentan benutzen) im Nachtrag erfüllt werden, um die FDA-Zulassung zu behalten? Oder gilt sowas erst bei Neuzulassungen?
• Wie pflanzt sich so eine FDA-Guidance überhaupt in die EU-Zulassung fort?
• Es gibt Geräte, die explizit offen konzipiert sind (die DANA zum Beispiel). Da müsste man schauen, wie die Entwickler da vorgehen. Für Looper mit Geräten, die sowieso offen ausgelegt sind, seh ich erstmal keine Sorge solange die Entwickler diese Richtung beibehalten wollen. Für kommerzielle Loops, wo die Entwickler eh Schnittstellen sicher bauen müssen, wird sich vermtl. eh nix ändern.

Für die DIY-Looper seh ich die Probleme hauptsächlich auf Seite 28 unter "Authentication":

Zitat

There are generally two types of authentication controls—information and entities—and a
1046 properly-secured system is able to prove the existence of both.
1047
Authentication of information52 1048 exists where the device and the system in which it operates is
1049 able to prove that information originated at a known and trusted source, and that the information
1050 has not been altered in transit between the original source and the point at which authenticity is
1051 verified. It is important to note that while authenticity implies that data is accurate and has been
1052 safeguarded from unauthorized user modification (i.e., integrity), integrity alone does not
1053 provide assurance that the data is real and came from a trusted source. Therefore, for the
1054 purposes of this guidance, authentication is discussed as a larger security objective over integrity.
1055
1056 Authentication of entities exists where a device and the system in which it operates is able to
1057 prove the identity of an endpoint (whether hardware and/or software) from whi

Alles anzeigen

Die meisten DIY-Loops nutzen ja die Schwäche, sowohl dass die Herkunft einer Information/Befehls (meist AAPS, OAPS, Loop) als auch der Befehl selbst eigentlich als "fremdartig" erkannt werden müsste.

Natürlich gilt auch der Satz hier:

Zitat

On a technical level, the strength of a device’s authentication scheme is defined by the amount of
1070 effort, including time, that an unauthorized party would need to expend to identify the
1071 decomposition of the authentication scheme

Stimmt schon, aber meist investieren die Loop-Entwickler mehr Zeit in das knacken eines Systems als jemand, der sich einen Geldvorteil erhofft. Kann natürlich am Ende so sein, dass die Cybersecurity-Hürden nicht so hoch angesetzt werden wie man zunächst befürchtet. Sicher ist kaum ein System, es geht nur darum, das Knacken so lang dauern zu lassen, dass es sich finanziell nicht "lohnt", den Aufwand zu betreiben. Mal abwarten.

Zitat von Szaladin

Es gibt Geräte, die explizit offen konzipiert sind (die DANA zum Beispiel). Da müsste man schauen, wie die Entwickler da vorgehen. Für Looper mit Geräten, die sowieso offen ausgelegt sind, seh ich erstmal keine Sorge solange die Entwickler diese Richtung beibehalten wollen.

Im schlimmsten Fall ist es IME-DC nicht mehr erlaubt, die Schnittstelle so offen zu konzipieren. Dann wären wirklich alle betroffen.

Aber ich bleibe erstmal gelassen und setzt auf unsere AAPS-Programmierer. Bis jetzt sind alle Pumpen und CGMS steuerbar geworden, egal wie verschlüsselt.

LG

zuckerstück

Sicherheitsvorkehrungen sind ja eigentlich dafür da, um zu verhindern, dass eine Software unberechtigterweise manipuliert werden kann. Das bedeutet aber nicht, dass die von der Software verarbeiteten oder erzeugten Daten nicht ausgelesen werden können/dürfen bzw. an eine Schnittstelle zur Verfügung gestellt werden. Die Schnittstelle kann ja technisch als Einbahnstraße ausgelegt werden. Die Befürchtung ist nur, dass die Hersteller unter dem Deckmantel der Cybersicherheit den Zugriff auf die Daten zusätzlich erschweren.

Der Diabetologe Dr. Frank Best hatte mal auf Diatec einen Beitrag zum Thema „Wem gehören die Daten“ gepostet, der leider nicht mehr online ist. Deshalb füge ich den Beitrag unten als Anhang bei. Darin findet man folgendes:

Dabei hat sich der G-BA bei der Zulassung von rt-CGM-Geräten unmissverständlich ausgedrückt:

MVV_RL §3 Abs. 6: „Soweit der Einsatz des Gerätes eine Verwendung, Erhebung,

Verarbeitung oder Nutzung personenbezogener oder personen-beziehbarer Daten vorsieht, muss sichergestellt sein, dass diese allein zum Zwecke der Behandlung der Patientin oder des Patienten erfolgen und eine Nutzung ohne Zugriff Dritter, insbesondere der Hersteller, möglich ist.“

Was bedeutet das? Nun, wenn man einflussreich ist, über die finanziellen Mittel

verfügt und eine gute Lobby hat, dann kann man sich auch schon mal über Regeln

hinwegsetzen. Das fördert sicher nicht das Vertrauen in demokratische

Spielregeln. Man könnte auch sagen, das ist asozial.

Wem gehören die Daten - diatec Kommentar Frank Best.pdf