Tymczasem okazuje się, że znaczna część tych systemów jest programowana przy użyciu standardowych narzędzi do programowania mikrokontrolerów i poddawana jedynie prostym testom funkcjonalnym. Podobna sytuacja panuje na rynku urządzeń stacjonarnych (np. ultrasonografy), które działają na bazie systemów operacyjnych ogólnego przeznaczenia i często w archaicznych wersjach (np. Windows 2000 czy Windows 3.1), dostarczanych na zasadzie "włącz i zapomnij". Co gorsza, wiele z nich można podłączyć do sieci.
Raport przygotowany przez Software Freedom Law Center ("Software Transparency in Implantable Medical Devices") dokumentuje liczne przypadki wycofywania urządzeń medycznych, w tym także wszczepialnych - rozruszników, pomp insulinowych czy zewnętrznych pomp infuzyjnych, podających leki na przykład w chemioterapii. W latach 2005-2009 amerykańska agencja do spraw leków (FDA) otrzymała prawie 60 tys. zgłoszeń dotyczących nieprawidłowego działania pomp infuzyjnych, w tym także takie, które skutkowały pogorszeniem stanu chorych czy nawet śmiercią.
W tym okresie dopuszczenie do obrotu wycofano dla 87 pomp, z czego 14 zakwalifikowano jako posiadające wady "klasy pierwszej", czyli o "uzasanionym prawdopodobieństwie spowodowania poważnego uszczerbku na zdrowiu lub śmierci".
Jedna z pomp zewnętrznych na przykład błędnie rozpoznawała wciśnięcia klawiszy podczas programowania przez lekarza lub pielęgniarkę, rejestrując wartość podwójnie, co skutkowało np. podaniem pacjentowi dawki studziesięciokrotnie większej (1100 mg zamiast 10 mg).
Raport Software Freedom Law Center (SFLC) zawiera także tezy, z którymi trudno się zgodzić bo używa wymienionych przypadków jako argumentu, że samo zastąpienie systemów komercyjnych oprogramowaniem z otwartym kodem źródłowym poprawi bezpieczeństwo urządzeń medycznych. Niestety, w rzeczywistości nieaktualizowany Linux będzie po 1-2 latach tak samo podatny na ataki jak nieaktualizowany Windows czy dowolny inny system operacyjny ogólnego przeznaczenia.
Rozwiązaniem opisanych przez SFLC problemów jest stosowanie technik tworzenia bezpiecznego oprogramowania do zastosowań krytycznych, w szczególności formalnej weryfikacja poprawności kodu oraz objęcie całego procesu tworzenia oprogramowania metodykami takimi jak SDL.
- ~Rosiu
- 2010-07-30 10:25:34
1100 mg zamiast 10 mg to nie jest "dziesięciokrotnie", tylko 110-krotnie większa dawka.
- ~Tomek
- 2010-07-30 10:27:48
Jeżeli wartość 1100 jest 10 razy większa od 10, to ja jestem 110 razy głupszy od autora tego tekstu..
- ~Gosć
- 2010-07-30 10:51:40
To straszne, że SLA nie przewidują dla oszczędności wymiany, przeglądu lub aktualizacji wersji oprogramowania urządzenia (i ewentualnego systemu operacyjnego) a tym bardziej, że dopuszcza się aplikacje i systemy bez zablokowania dostępu do świata zewnętrznego - przecież w połowie lat 90 ubiegłego wieku juz tak robiono z powodzeniem (był brak możliwości włamania na dużym audycie bezpieczeństwa nawet po 10 latach w tym na platformie i narzędziami MS). Wiadomo kasa i czas bo są konkurenci a nie ma takiej kontroli i wymogów (chociaż tu są niezmiernie upierdliwe ale inne).
- ~enkidu
- 2010-07-30 11:11:16
tad, jak to sobie wyobrażasz? wycinanie modułu rozrusznika z zalanego, tytanowego korpusu, żeby zrobić aktualizację? nonsens. Urządzenia te i tak pozwalają na wiele - "zdalnie" są zmieniane parametry ich pracy. Że to niebezpieczne? owszem, ale robienie w tym celu kolejnych operacji byłoby dla pacjentów większym zagrożeniem, niż zatrzymanie akcji serca (posiadacze rozruszników są poinstruowani, co robić w takich sytuacjach)
- pawel.krawczyk
- 2010-07-30 15:52:51
Błyskotliwość części czytelników jest poruszająca, ale artykule jest napisane "na przykład dziesięciokrotnie".
- ~Mateusz
- 2010-07-30 16:40:17
@Pawel: A "błyskotliwość" autora mogłby polegać na poprawieniu tego zdania w tekście, albo na powstrzymaniu się od odpowiedzi, która jest już tylko "brnięciem" (piszemy dla inżynierów - oni są wyczuleni na takie nielogiczności)
- ~m
- 2010-07-30 18:33:28
@Pawel Nie rozumiesz treści artykułu ani komentarzy. Sam też napisałeś z błędem. A jak tam na koloni...
- ~ciekawy
- 2010-07-30 18:51:13
takie urządzenia, szczególnie jak jest do nich dostęp "z zewnątrz" (np. pompa insulinowa) powinny mieć po prostu zworkę lub podobnie działające rozwiązanie które uniemożliwia zmianę ich parametrów. Z rozrusznikiem serca będzie trudniej, ale tu wystarczyło by np. kontrolować wewnętrzny przełącznik poprzez przyłożenie magnesu. Proste rozwiązania, a bez przełączenia nie ma programowania/zmian. Aktualizacja oczywiście odpada, nie wyobrażam sobie zmiany firmware rozrusznika serca, ale zmianę konfiguracji warto zabezpieczyć.
- ~Michoo
- 2010-07-31 20:37:00
@ciekawy "nie wyobrażam sobie zmiany firmware rozrusznika serca" Czyli gdy okazuje się że rozrusznik ma wadę i w pewnych sytuacjach może zadziałać nieprawidłowo to kroimy pacjenta zamiast w 1/10 sekundy zainstalować uaktualnienie? Zrobienie tego bezpiecznie by wymagało np architektury z dobrze napisanym szyfrowaniem asymetrycznym - z rozrusznikiem dostajesz certyfikat pozwalający podpisać aktualizację czy też zmianę konfiguracji. "kontrolować wewnętrzny przełącznik poprzez przyłożenie magnesu" A co za problem w tłoku w komunikacji miejskiej przyłożyć na chwilę magnes?
- ~ciekawy
- 2010-07-31 21:09:50
Michoo, nie problem. Nie problem też kogoś zadźgać nożem. Jednak nie zakładałbym aż tak ekstremalnych sytuacji. Po prostu chodzi o to, żeby np. podczas kontroli lekarz niechcący go nie przeprogramował. Oczywiście z szyfrowaniem i certyfikatem to dobry pomysł. Jednak urządzenie typu rozrusznik jest naprawdę bardzo proste. Teraz wyobraź sobie, że byłoby tam o wiele więcej elektroniki i co najgorsze o wiele więcej oprogramowania. I nich ci jeden z procesów ma wyciek pamięci z zawiesi całość? Uważam, że przy takich zastosowaniach musi być prosto i bezawaryjnie. A każda dodatkowa linia kodu to kilka potencjalnych wpadek.
- pawel.krawczyk
- 2010-08-02 15:15:41
Poprawione zgodnie z życzeniem.
Popularne produkty
Bezpieczna dieta wysokobiałkowa
Pobierz bezpłatnego e-booka 
Kariera w IT 2012
