Řešení IoT vyhovující HIPAA

HIPAA a IoT

Internet věcí (IoT) roste exponenciálně a některé zprávy předpovídají, že to dosáhne 38 miliard zařízení v roce 2020. S více a více příběhů se objevují vycházející hackovaná zařízení, je potřeba zabezpečení internetu věcí stále naléhavější, a to spíše pro výrobce zdravotnických prostředků s ohledem na HIPAA.

Americký zákon o přenositelnosti a odpovědnosti zdravotního pojištění, neboli HIPAA, není vtip. HIPAA chrání bezpečnost a soukromí elektronických chráněných zdravotních informací pacientů (PHI nebo ePHI) a je prosazována Úřadem pro občanská práva (OCR) amerického ministerstva zdravotnictví a sociálních služeb (DHS). Pokud hledáte digitální certifikáty pro komunikaci kompatibilní s HIPAA, podívejte se na náš článek zde.

HIPAA vyžaduje, aby poskytovatelé zdravotní péče chránili PHI během přepravy nebo v klidu, a pokud tak neučiní, může to mít za následek vysoké pokuty. Pokuty za porušení HIPAA se může pohybovat od 100 do 50,000 1.5 $ za porušení, s maximální pokutou 2019 milionu $ ročně. V roce 418 vedlo 34.9 porušení ke kompromisu XNUMX milionu Američanů s PHI. 

Podniknutí kroků k zabezpečení informací o pacientech a zachování souladu s HIPAA je jistě správný krok. V roce 2019 představovala porušení síťových serverů ohrožení informací 30.6 milionu jednotlivců. V roce 2018 byl hacknut síťový server American Medical Collection Agency (AMCA), což vedlo k 22 milionům pacientů data ohrožena. Finanční důsledky a ztráta podnikání vedly k tomu, že společnost AMCA podala návrh na prohlášení kapitoly 11 o bankrotu. 

Požadavky na přenos informací HIPAA

HIPAA uvádí ohledně zabezpečení přenosu informací následující:

164.312 (e) (1): Standard: Zabezpečení přenosu. Provádět technická bezpečnostní opatření k ochraně před neoprávněným přístupem k elektronicky chráněným zdravotním informacím, které jsou přenášeny prostřednictvím sítě elektronických komunikací.

Protože HIPAA měla být připravena na budoucnost, ponechává tuto směrnici otevřenou. V zásadě platí, že k ochraně před potenciálně nákladným porušením je třeba zavést protokoly k ochraně informací přenášených prostřednictvím sítě elektronických komunikací.

Pro organizaci to znamená, že všechna zařízení, která přenášejí data po síti, zejména ta, která tak činí mimo firemní bránu firewall, musí implementovat mechanismus pro ověřování a šifrování. SSL /TLS se o to může postarat jednosměrně nebo vzájemné ověřování. 

SSL /TLS pro IoT kompatibilní s HIPAA

SSL /TLS použití protokolu asymetrické šifrování zabezpečit data sdílená mezi dvěma počítači na internetu. Kromě toho SSL /TLS zajišťuje ověření totožnosti serveru a / nebo klienta. V nejběžnějším scénáři pomocí jednosměrného ověřování poskytuje server HTTPS prohlížeči návštěvníka certifikát, který byl digitálně podepsán veřejně důvěryhodnou certifikační autoritou (CA), jako je SSL.com. 

Matematika za SSL /TLS zajistit, aby digitálně podepsané certifikáty certifikační autority nemohly být zfalšovány vzhledem k dostatečně velké velikosti klíče. Veřejné CA před vydáním certifikátu ověřují totožnost žadatelů. Rovněž podléhají přísným auditům poskytovatelů operačních systémů a webových prohlížečů, které mají být přijaty a udržovány v důvěryhodných obchodech (seznamy důvěryhodné kořenové certifikáty nainstalován pomocí prohlížeče a softwaru OS).

SSL a ověřovací klienti

Pro většinu aplikací, SSL /TLS používá jednosměrné ověřování serveru vůči klientovi; anonymní klient (webový prohlížeč) vyjedná šifrovanou relaci s webovým serverem, který představuje veřejně důvěryhodný SSL /TLS certifikát k identifikaci během SSL /TLS potřesení rukou. 

I když je jednosměrné ověřování naprosto přijatelné pro většinu procházení webu, stále je zranitelné vůči útokům krádeží pověření, jako je phishing, při kterých útočníci cílí na přihlašovací údaje, jako jsou uživatelská jména a hesla. Phishing útoky podle 22% představuje XNUMX% porušení zabezpečení údajů zpráva od Verizonu. Pro další ochranu se můžete rozhodnout pro vzájemné ověřování. Ve vzájemném ověřování, jakmile je server během ověřování ověřen, odešle CertificateRequest zpráva klientovi. Klient odpoví zasláním certifikátu na server k ověření. S oběma stranami ověřenými pomocí PKIvzájemné ověřování je mnohem bezpečnější než tradiční metody zaměřené na heslo.

Vzájemné ověřování a IoT

Pro výrobce zdravotnických prostředků může být nejlepší volbou vzájemné ověřování serverů a zařízení, protože při identitě klienta a serveru není nic ponecháno náhodě. Například jakmile je chytrý lékařský přístroj připojen k internetu, může se výrobci hodit, aby odesílal a přijímal data na a ze serverů společnosti, aby uživatelé měli přístup k informacím. Pro usnadnění tohoto bezpečného přenosu informací může výrobce zvážit následující:

• Dodejte každému zařízení jedinečný pár kryptografických klíčů a certifikát klienta. Protože veškerá komunikace bude mezi zařízením a servery společnosti, mohou být tyto certifikáty důvěryhodně důvěryhodné, což nabízí další flexibilitu pro zásady, jako je životnost certifikátu.
• Zadejte jedinečný kód zařízení (například sériové číslo nebo QR kód), který může uživatel naskenovat nebo zadat do svého uživatelského účtu na webovém portálu výrobce nebo v aplikaci pro smartphone, aby přidružil zařízení k jeho účtu.
• Jakmile je zařízení připojeno k internetu prostřednictvím Wi-Fi sítě uživatele, otevře se vzájemná komunikace TLS spojení se serverem výrobce. Server se sám ověří v zařízení a vyžádá si certifikát klienta zařízení, který je spojen s jedinečným kódem zadaným uživatelem do jeho účtu.

Obě strany připojení jsou nyní vzájemně ověřeny a mohou posílat zprávy tam a zpět pomocí SSL /TLS šifrování přes protokoly aplikační vrstvy, jako jsou HTTPS a MQTT. Uživatel může přistupovat k datům ze zařízení nebo provádět změny v jeho nastavení pomocí účtu webového portálu nebo aplikace pro smartphone. Mezi těmito dvěma zařízeními nikdy není potřeba provádět neověřené zprávy ani zprávy ve formátu prostého textu.

Poslední slovo

Nenechte se chytit venku. Pokud vás zajímají vlastní řešení IoT SSL.com, vyplňte následující formulář a získejte další informace.