en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

Soluzioni IoT conformi HIPAA

HIPAA e IoT

L'Internet of Things (IoT) sta crescendo in modo esponenziale, con alcuni rapporti che prevedono che si estenderà 38 miliardi di dispositivi nel 2020. Con più e più storie All'emergere dell'uscita di dispositivi hackerati, la necessità di proteggere l'Internet degli oggetti sta diventando sempre più urgente, soprattutto per i produttori di dispositivi medici che hanno in mente l'HIPAA.

Lo US Health Insurance Portability and Accountability Act, o HIPAA, non è uno scherzo. HIPAA protegge la sicurezza e la privacy delle informazioni sanitarie protette elettroniche (PHI o ePHI) dei pazienti ed è applicato dall'Office for Civil Rights (OCR) del Dipartimento della salute e dei servizi umani (DHS) degli Stati Uniti. Se stai cercando certificati digitali per comunicazioni conformi a HIPAA, controlla il nostro articolo qui.

L'HIPAA richiede che gli operatori sanitari proteggano le PHI durante il trasporto oa riposo, e il mancato rispetto di questa precauzione può comportare pesanti sanzioni. Sanzioni per violazioni HIPAA può variare da $ 100 a $ 50,000 per violazione, con una penale massima di $ 1.5 milioni all'anno. Nel 2019, 418 violazioni hanno portato alla compromissione di 34.9 milioni di PHI americani. 

Adottare subito misure per proteggere le informazioni sui pazienti e mantenere la conformità HIPAA è sicuramente la mossa giusta. Nel 2019, le violazioni dei server di rete hanno causato la compromissione di informazioni di 30.6 milioni di persone. Nel 2018, il server di rete dell'American Medical Collection Agency (AMCA) è stato violato, portando a 22 milioni di pazienti il ​​loro dati compromessi. Le ripercussioni finanziarie e la perdita di affari hanno portato alla dichiarazione di fallimento di AMCA per il Capitolo 11. 

 

Requisiti per la trasmissione delle informazioni HIPAA

L'HIPAA afferma quanto segue in merito alla sicurezza della trasmissione delle informazioni:

164.312 (e) (1): Standard: sicurezza della trasmissione. Attuare misure tecniche di sicurezza per impedire l'accesso non autorizzato alle informazioni sanitarie protette elettroniche che vengono trasmesse su una rete di comunicazioni elettroniche.

Poiché HIPAA doveva essere a prova di futuro, lascia questa direttiva aperta. Fondamentalmente, per proteggersi da violazioni potenzialmente costose, sono necessari protocolli per proteggere le informazioni trasmesse su una rete di comunicazioni elettroniche.

Per un'organizzazione, ciò significa che tutti i dispositivi che trasmettono dati su una rete, in particolare quelli che lo fanno al di fuori di un firewall aziendale, devono implementare un meccanismo di autenticazione e crittografia. SSL /TLS può occuparsene sia a senso unico che autenticazione reciproca

SSL /TLS per IoT conforme a HIPAA

SSL /TLS usi del protocollo crittografia asimmetrica per proteggere i dati condivisi tra due computer su Internet. Inoltre, SSL /TLS assicura che le identità del server e / o del client siano convalidate. Nello scenario più comune, utilizzando l'autenticazione unidirezionale, un server HTTPS fornisce al browser di un visitatore un certificato che è stato firmato digitalmente da un'autorità di certificazione (CA) pubblicamente attendibile come SSL.com. 

La matematica dietro SSL /TLS garantire che i certificati firmati digitalmente di una CA siano praticamente impossibili da falsificare data una dimensione della chiave sufficientemente grande. Le CA pubbliche verificano l'identità dei richiedenti prima di emettere i certificati. Sono inoltre soggetti a rigorosi controlli da parte dei fornitori di sistemi operativi e browser Web per essere accettati e mantenuti nei trust store (elenchi di certificati radice attendibili installato con browser e software OS).

SSL e client di autenticazione

Per la maggior parte delle applicazioni, SSL /TLS utilizza l'autenticazione unidirezionale di un server a un client; un client anonimo (il browser web) negozia una sessione crittografata con un server web, che presenta un SSL /TLS certificato per identificarsi durante il SSL /TLS stretta di mano. 

Sebbene l'autenticazione unidirezionale sia perfettamente accettabile per la maggior parte della navigazione sul Web, è ancora vulnerabile agli attacchi di furto di credenziali come il phishing in cui gli aggressori prendono di mira le credenziali di accesso come nomi utente e password. Attacchi di phishing rappresentano il 22% delle violazioni dei dati, secondo un rapporto di Verizon. Per una protezione aggiuntiva, puoi optare per l'autenticazione reciproca. Nella mutua autenticazione, una volta che il server è stato autenticato durante l'handshake, invierà un file CertificateRequest messaggio al cliente. Il client risponderà inviando un certificato al server per l'autenticazione. Con entrambi i lati autenticati con PKI, l'autenticazione reciproca è molto più sicura dei metodi tradizionali incentrati sulle password.

Autenticazione reciproca e IoT

Per i produttori di dispositivi medici, l'autenticazione reciproca di server e dispositivi potrebbe essere l'opzione migliore, in quanto non lasciare nulla al caso con le identità di client e server. Ad esempio, una volta che un dispositivo medico intelligente è connesso a Internet, a un produttore potrebbe piacere che invii e riceva dati da e verso i server dell'azienda, in modo che gli utenti possano accedere alle informazioni. Per facilitare questo trasferimento sicuro di informazioni, il produttore potrebbe considerare quanto segue:

  • Spedisci ogni dispositivo con una coppia di chiavi crittografiche e un certificato client univoci. Poiché tutte le comunicazioni avverranno tra il dispositivo e i server dell'azienda, questi certificati potrebbero essere considerati attendibili privatamente, offrendo ulteriore flessibilità per criteri come la durata dei certificati.
  • Fornire un codice dispositivo univoco (come un numero di serie o un codice QR) che l'utente può scansionare o inserire nel proprio account utente sul portale Web del produttore o sull'app per smartphone per associare il dispositivo al proprio account.
  • Una volta che il dispositivo è connesso a Internet tramite la rete Wi-Fi dell'utente, aprirà una mutua TLS connessione con il server del produttore. Il server si autenticherà sul dispositivo e richiederà il certificato client del dispositivo, che è associato al codice univoco inserito dall'utente nel proprio account.

Le due parti della connessione sono ora reciprocamente autenticate e possono inviare messaggi avanti e indietro con SSL /TLS crittografia su protocolli a livello di applicazione come HTTPS e MQTT. L'utente può accedere ai dati dal dispositivo o apportare modifiche alle sue impostazioni con l'account del portale web o l'app per smartphone. Non c'è mai bisogno di messaggi di testo non autenticati o in chiaro tra i due dispositivi.

Ultima parola

Non farti cogliere allo scoperto. Se sei interessato alle soluzioni IoT personalizzate di SSL.com, compila il modulo sottostante per ottenere maggiori informazioni.

Iscriviti alla Newsletter di SSL.com

Non perdere nuovi articoli e aggiornamenti da SSL.com