Chrońcie dane pacjentów, zanim staną się zgłoszeniem naruszenia

Ujawnienie ePHI uruchamia obowiązkowe zgłoszenie naruszenia

Zgodnie z HIPAA nieuprawniony dostęp do dokumentacji choćby jednego pacjenta wymaga zgłoszenia naruszenia do HHS, a w określonych przypadkach także pacjentowi. Błędy kontroli dostępu powodujące takie ujawnienia, jak IDOR i wadliwa autoryzacja w API FHIR, to dokładnie to, co znajduje Penetrify.

HIPAA Security Rule wymaga regularnego testowania

45 CFR §164.308(a)(8) wymaga regularnych technicznych i nietechnicznych ocen waszych kontroli bezpieczeństwa. „Regularnie” oznacza częściej niż raz w roku, jeśli wdrażacie kod co miesiąc, a Penetrify czyni ciągłe testowanie ekonomicznie wykonalnym.

API FHIR wprowadzają nowe powierzchnie ataku

Nowoczesne standardy interoperacyjności w ochronie zdrowia (FHIR R4, SMART on FHIR) tworzą endpointy API wystawiające dane pacjentów na dużą skalę. Źle skonfigurowana autoryzacja na jednym endpointcie FHIR może ujawnić całą waszą populację pacjentów.

45 CFR §164.308(a)(8): regularna ocena zabezpieczeń technicznych i nietechnicznych

Kontrola 10.m: testy penetracyjne jako element programu zarządzania podatnościami

CC6.1: logiczne kontrole dostępu z dowodami z testów penetracyjnych

A.12.6: zarządzanie podatnościami technicznymi z regularnym testowaniem bezpieczeństwa

HIPAA dziś i proponowany przepis, który wprost nazywa testy penetracyjne

Obecna HIPAA Security Rule wymaga „regularnej” technicznej i nietechnicznej oceny zabezpieczeń (45 CFR §164.308(a)(8)), nie nazywając wprost testów penetracyjnych, i właśnie dlatego programy bezpieczeństwa w ochronie zdrowia tak bardzo się różnią. Ta niejednoznaczność właśnie się kończy: proponowana przez HHS aktualizacja Security Rule (NPRM opublikowane 6 stycznia 2025 roku) uczyniłaby wymagania wyraźnymi, w tym testy penetracyjne co najmniej raz na 12 miesięcy i skanowanie podatności co najmniej raz na sześć miesięcy.

W połowie 2026 roku przepis jest wciąż projektem, nie wersją ostateczną, a OCR nadal egzekwuje obowiązującą Security Rule. Kierunek jest jednak jednoznaczny, a postępowania OCR już dziś traktują brak testów technicznych jako dowód niedostatecznej analizy ryzyka, czyli najczęściej wskazywanego uchybienia w sprawach egzekucyjnych. Wprowadzenie rytmu testowania teraz sprawia, że przyszły przepis końcowy będzie formalnością; czekanie oznacza budowanie programu pod presją terminu zgodności.

Ciągłe testowanie już dziś odpowiada na kryterium „regularności” lepiej niż jakiekolwiek roczne zlecenie: udokumentowana historia skanowań przez cały rok, każde z własnymi znaleziskami i dowodami naprawy, to dokładnie ten rodzaj bieżącej oceny, który opisuje §164.308(a)(8).

FHIR i SMART on FHIR: interoperacyjność jest powierzchnią ataku

Amerykańskie wymogi interoperacyjności przeniosły dane pacjentów za ustandaryzowane API: zasoby FHIR R4, autoryzację SMART on FHIR, masowy eksport danych. Standaryzacja pomaga jednak także atakującym: wiedzą dokładnie, jakie endpointy istnieją (/Patient, /Observation, /DocumentReference) i dokładnie, co wycieka z tego źle skonfigurowanego. Pojedynczy endpoint FHIR, który nie egzekwuje autoryzacji na poziomie zasobu, może ujawnić całą populację pacjentów i, w odróżnieniu od skradzionego laptopa, robi to po cichu.

Powtarzalne tryby awarii są konkretne: identyfikatory zasobów przyjmowane bez weryfikacji relacji opieki użytkownika pytającego (IDOR w skali populacji), zakresy SMART przyznawane szeroko i nigdy nieegzekwowane per zasób oraz endpointy eksportu masowego osiągalne przy użyciu poświadczeń przeznaczonych do dostępu do pojedynczego rekordu. Penetrify sprawdza te granice autoryzacji tak, jak sonduje je atakujący: między rolami, między pacjentami, między zakresami, przy każdym wdrożeniu waszego API.

Penetrify sprawdza granice autoryzacji we wszystkich rolach użytkowników (klinicysta, administrator, pacjent) i celowo szuka podatności IDOR ujawniających dokumentację pacjentów poza autoryzowanymi relacjami opieki. To przyczyna numer jeden naruszeń danych w ochronie zdrowia.

Każde skanowanie tworzy raport ze znacznikiem czasu i uporządkowany według istotności. Kiedy OCR będzie audytować wasz program bezpieczeństwa, wykażecie udokumentowaną historię regularnego testowania bezpieczeństwa całej aplikacji, a nie jeden roczny raport z jednego momentu.

Penetrify sprawdza implementacje FHIR R4 i SMART on FHIR pod kątem egzekwowania granic autoryzacji, walidacji zakresów i kontroli dostępu do zasobów: dokładnie tych powierzchni ataku, do testowania których standardowe narzędzia DAST nie są skonfigurowane.

Penetrify nigdy nie modyfikuje, nie usuwa ani nie wyprowadza danych. Testuje, obserwując odpowiedzi aplikacji, a nie wykonując operacje zapisu. Można go bezpiecznie uruchomić na środowisku staging odwzorowującym strukturę produkcyjnych danych pacjentów.