Proteggete i dati dei pazienti prima che diventino una notifica di violazione

L'esposizione di ePHI fa scattare la notifica obbligatoria

Secondo HIPAA, l'accesso non autorizzato anche alla cartella di un solo paziente impone la notifica della violazione all'HHS e, se del caso, al paziente stesso. I difetti di controllo degli accessi che causano queste esposizioni, come l'IDOR e l'autorizzazione non funzionante nelle API FHIR, sono esattamente ciò che Penetrify individua.

La HIPAA Security Rule richiede test regolari

45 CFR §164.308(a)(8) richiede valutazioni tecniche e non tecniche regolari dei vostri controlli di sicurezza. «Regolare» significa più di una volta all'anno se rilasciate codice ogni mese, e Penetrify rende il test continuo economicamente praticabile.

Le API FHIR introducono nuove superfici di attacco

Gli standard moderni di interoperabilità sanitaria (FHIR R4, SMART on FHIR) creano endpoint API che espongono dati dei pazienti su larga scala. Un'autorizzazione mal configurata su un singolo endpoint FHIR può esporre l'intera popolazione di pazienti.

45 CFR §164.308(a)(8): valutazione regolare delle salvaguardie tecniche e non tecniche

Controllo 10.m: penetration test come parte del programma di gestione delle vulnerabilità

CC6.1: controlli di accesso logici con prove dei penetration test

A.12.6: gestione delle vulnerabilità tecniche con test di sicurezza regolari

HIPAA oggi, e la norma proposta che rende esplicito il penetration testing

L'attuale HIPAA Security Rule richiede una valutazione «regolare» tecnica e non tecnica delle salvaguardie (45 CFR §164.308(a)(8)) senza nominare esplicitamente il penetration test, ed è per questo che i programmi di sicurezza sanitari variano così tanto. Quell'ambiguità sta per finire: l'aggiornamento della Security Rule proposto dall'HHS (NPRM pubblicata il 6 gennaio 2025) renderebbe espliciti i requisiti, incluso il penetration test almeno ogni 12 mesi e la scansione delle vulnerabilità almeno ogni sei mesi.

A metà 2026 la norma è ancora proposta e non definitiva, e l'OCR continua ad applicare la Security Rule vigente. La direzione però è inequivocabile, e le indagini dell'OCR già oggi trattano l'assenza di test tecnici come prova di un'analisi dei rischi inadeguata, la carenza più citata nei procedimenti sanzionatori. Costruire adesso la cadenza dei test significa che la futura norma definitiva sarà un non-evento; aspettare significa mettere in piedi un programma sotto la pressione di una scadenza di conformità.

Il test continuo risponde inoltre al criterio di «regolare» già oggi meglio di qualsiasi incarico annuale: uno storico documentato di scansioni lungo tutto l'anno, ciascuna con i propri risultati e le prove di remediation, è esattamente il tipo di valutazione continuativa che descrive il §164.308(a)(8).

FHIR e SMART on FHIR: l'interoperabilità è una superficie di attacco

I mandati statunitensi sull'interoperabilità hanno spostato i dati dei pazienti dietro API standardizzate: risorse FHIR R4, autorizzazione SMART on FHIR, export massivo dei dati. La standardizzazione aiuta però anche gli attaccanti: sanno esattamente quali endpoint esistono (/Patient, /Observation, /DocumentReference) ed esattamente cosa lascia trapelare uno mal configurato. Un singolo endpoint FHIR che non applica l'autorizzazione a livello di risorsa può esporre un'intera popolazione di pazienti e, a differenza di un portatile rubato, lo fa in silenzio.

Le modalità di guasto ricorrenti sono precise: ID di risorsa accettati senza verificare la relazione di cura dell'utente richiedente (IDOR su scala di popolazione), scope SMART concessi in modo ampio e mai applicati per singola risorsa, ed endpoint di export massivo raggiungibili con credenziali pensate per l'accesso a un singolo record. Penetrify verifica questi confini di autorizzazione come li sonda un attaccante: tra ruoli, tra pazienti, tra scope, a ogni deploy della vostra API.

Penetrify verifica i confini di autorizzazione su tutti i ruoli utente (clinico, amministratore, paziente) e cerca in modo specifico vulnerabilità IDOR che espongano cartelle di pazienti fuori dalle relazioni di cura autorizzate. È la causa numero uno delle violazioni di dati in sanità.

Ogni scansione produce un report con marca temporale e ordinato per gravità. Quando l'OCR verifica il vostro programma di sicurezza, potete dimostrare uno storico documentato di test di sicurezza regolari su tutta l'applicazione, non un singolo report annuale relativo a un solo momento.

Penetrify verifica le implementazioni FHIR R4 e SMART on FHIR su applicazione dei confini di autorizzazione, validazione degli scope e controllo di accesso alle risorse: proprio le superfici di attacco che gli strumenti DAST standard non sono configurati per testare.

Penetrify non modifica, non elimina e non esfiltra mai dati. Verifica osservando le risposte dell'applicazione, non eseguendo operazioni di scrittura. Utilizzabile in sicurezza su ambienti di staging che rispecchiano la struttura dei dati dei pazienti in produzione.