Registrazione per HIPAA: controllo sicuro in Linux
HOWTO sulla registrazione HIPAA, parte 2
L’Health Insurance Portability and Accountability Act del 1996 (HIPAA) delinea gli standard di sicurezza e privacy pertinenti per le informazioni sanitarie, sia elettroniche che fisiche. La missione principale della legge è "migliorare la portabilità e la continuità della copertura assicurativa sanitaria nei mercati di gruppo e individuali, combattere gli sprechi, le frodi e gli abusi nell'assicurazione sanitaria e nella fornitura di assistenza sanitaria" (HIPAA Act del 1996 http://www .hhs.gov/ocr/privacy/). Un recente miglioramento dell'HIPAA è denominato Health Information Technology for Economic and Clinical Health Act o HITECH Act. La legge cerca di "promuovere l'adozione e l'uso significativo della tecnologia informatica sanitaria" e "affronta i problemi di privacy e sicurezza associati alla trasmissione elettronica di informazioni sanitarie". (Legge HITECH del 2009 )
Come accennato in precedenza, l'HIPAA in sé non scende al livello dei controlli di sicurezza e delle tecnologie da implementare. Ciò richiede che le organizzazioni interessate dall’HIPAA - note anche come “entità coperte” - cerchino di seguire lo spirito del regolamento anziché la sua lettera. Ciò che è anche interessante notare è che le compagnie assicurative e molti ospedali che accettano carte di pagamento sono soggetti sia all’HIPAA che al PCI DSS (trattati nelle nostre newsletter precedenti). Comprensibilmente, l’ambito della loro applicabilità all’interno dell’organizzazione potrebbe essere diverso poiché i sistemi di elaborazione dei pagamenti non dovrebbero archiviare le informazioni sulla salute dei pazienti e viceversa. Tuttavia, considerare gli stessi controlli tecnici e amministrativi per entrambi i regolamenti è prudente e consentirà di risparmiare denaro sia a breve che a lungo termine.
La newsletter precedente si concentrava sulla registrazione HIPAA generale, sui processi di revisione dei registri e sulla registrazione della piattaforma. Questa puntata della newsletter tratta questioni di registrazione delle applicazioni specifiche per le applicazioni mediche.
Sebbene la registrazione a livello di piattaforma sia utile per proteggere le informazioni sanitarie sensibili, è un dato di fatto che la maggior parte delle informazioni sanitarie viene archiviata in database ed elaborata da applicazioni sanitarie specifiche. Tali applicazioni vengono acquistate da fornitori specializzati o sviluppate internamente tramite sviluppatori esternalizzati.
L'HIPAA dei controlli di audit, menzionato nella Sezione 164.312(b), si applica alla registrazione delle applicazioni tanto o più che alla registrazione della piattaforma. Ciò significa che le applicazioni personalizzate devono essere progettate per avere una registrazione adeguata. La registrazione delle applicazioni esistenti deve essere valutata con una registrazione adeguata: è opportuno notare che molte applicazioni legacy spesso non registrano dettagli sufficienti per gli eventi e potrebbero addirittura saltare del tutto la registrazione degli eventi. Pertanto, prima di intraprendere questo progetto, è opportuno determinare quali applicazioni all'interno della propria organizzazione contengono informazioni sanitarie protette (PHI) e quali sono i livelli e i metodi di registrazione esistenti.
Definiamo alcune linee guida su cosa registrare per soddisfare lo spirito e la lettera dei requisiti di sicurezza HIPAA e i chiarimenti NIST 800-66 HIPAA.
Guida alla registrazione delle applicazioni
Prima di poter definire una buona registrazione HIPAA, consideriamo l'utilizzo tipico della sicurezza per i dati di registro.
I migliori registri di controllo di alto livello ti dicono esattamente cosa è successo (quando, dove e come) e chi è stato coinvolto. Tali registri sono adatti per l'analisi manuale, semiautomatica e automatizzata. Idealmente, possono essere analizzati senza avere a portata di mano l'applicazione che li ha prodotti - e sicuramente senza avere a disposizione lo sviluppatore dell'applicazione. Nel caso di applicazioni sanitarie, tale sviluppatore potrebbe non essere del tutto disponibile e il team di sicurezza dovrà procedere da solo. Dal punto di vista della gestione dei log, i log possono essere centralizzati per l'analisi e la conservazione. Infine, non dovrebbero rallentare il sistema e possono dimostrarsi affidabili, se utilizzati come prove forensi.
È necessario definire due cose principali.
- Innanzitutto, ci sono tipi di attività o eventi che devono sempre essere registrati. Ad esempio, le decisioni sull’autenticazione, l’accesso alle informazioni sanitarie e le modifiche al sistema dovrebbero sempre apparire nei registri.
- In secondo luogo, per ogni tipo di evento registrato esiste un particolato dettagliato che è obbligatorio per la sua interpretazione, sia da parte di un essere umano che di un sistema automatizzato. Ad esempio, ogni registro dovrebbe avere un timestamp affidabile e ogni registro relativo all'attività dell'utente dovrebbe contenere il nome utente di quell'utente.
Va inoltre notato che alcuni dettagli non dovrebbero mai essere registrati. L'esempio è ovvio: le password delle applicazioni o del sistema non dovrebbero mai apparire nei log (questo, purtroppo, a volte accade ancora per le applicazioni web). Altrettanto ovviamente, le informazioni sanitarie stesse dovrebbero essere tenute fuori dai registri.
Quali eventi registrare?
Qual è il tema generale per la selezione degli eventi da registrare?
Chiaramente, dobbiamo sapere chi, quando e perché accede a qualsiasi informazione sanitaria. Dobbiamo anche sapere chi lo aggiunge, lo modifica o lo elimina. Ma non è tutto: dobbiamo anche tenere conto di chi tenta, senza riuscirci, di leggere, modificare o cancellare le informazioni. Se non siamo in grado di registrare l'accesso a ciascun dato, dobbiamo registrare attentamente tutti gli accessi all'applicazione stessa.
Successivamente, dobbiamo sapere chi esegue altre azioni sui sistemi che elaborano le informazioni sanitarie poiché tali attività potrebbero influire sul futuro accesso ai dati sanitari. Ad esempio, dobbiamo registrare se qualcuno si disconnette o aggiunge un nuovo componente al sistema che potrebbe consentire un accesso illimitato ai dati. Inoltre, dobbiamo registrare altri eventi critici e preoccupanti sui sistemi informativi sanitari, poiché tali eventi potrebbero presentare prove circostanziali di accessi non autorizzati.
Il seguente elenco presenta una visione strutturata dei criteri di cui sopra:
Autenticazione, autorizzazione, accesso
- Decisioni di autenticazione/autorizzazione, riuscite e fallite (vedere “stato” di seguito) - e in particolare l'autenticazione privilegiata
- La registrazione delle disconnessione degli utenti è importante anche per sapere quando l'utente non ha più accesso all'applicazione
- Passaggio da un account utente all'altro
- Accesso al sistema, accesso ai dati, accesso ai componenti dell'applicazione
- Accesso di rete all'applicazione, incluso l'accesso remoto da un componente dell'applicazione a un altro in un ambiente distribuito
Modifiche
- Modifiche al sistema/applicazione (in particolare modifiche ai privilegi)
Problemi di disponibilità
- Avviamenti e arresti di sistemi, applicazioni e moduli/componenti applicativi
"Cattiveria"/Minacce
- Ingressi non validi altri possibili abusi dell'applicazione
Sebbene creare un elenco completo di "cosa registrare" per ogni applicazione sanitaria esistente sia probabilmente impossibile, l'elenco riportato sopra dovrebbe fornire un utile punto di partenza per le applicazioni pertinenti. Può essere convertito nella policy di registrazione dell'applicazione senza molto lavoro aggiuntivo. Fare riferimento alla newsletter precedente per l'impostazione del processo di monitoraggio e revisione dei registri.
Quali dettagli registrare?
Successivamente, quali dati dovresti registrare per ciascun evento e a quale livello di dettaglio dovresti registrarlo? Il tema generale che usiamo qui è il seguente:
Chi era coinvolto?
>Quello che è successo?
Dove è successo?
Quando è successo?
Perchè è successo?
Come è successo?
L'elenco seguente fornisce un punto di partenza basato su quel tema:
Timestamp + fuso orario : aiuta a rispondere alla domanda "quando", il fuso orario è essenziale per le applicazioni distribuite
Sistema, applicazione o componente: aiuta a rispondere alla domanda "dove" e deve fornire anche il contesto applicativo pertinente
Origine: per i messaggi relativi alla connettività di rete o al funzionamento delle applicazioni distribuite, i log devono anche rispondere alla domanda "da dove" fornendo un'origine di rete.
Nome utente: aiuta a rispondere alla domanda "chi?", per quegli eventi rilevanti per le attività dell'utente o dell'amministratore
Azione: aiuta a rispondere alla domanda “cosa?” fornendo la natura dell'evento che viene registrato nel registro
Oggetto: aiuta anche a rispondere alla domanda "cosa?" aiutando a sapere quale componente di sistema o altro oggetto (come l'account utente) è stato interessato
Stato: aiuta anche a rispondere alla domanda "cosa?" spiegando se l'azione mirata all'oggetto è riuscita o meno (sono possibili anche altri tipi di stato, come "differito")
Priorità: ultimo ma non meno importante, ogni evento registrato dovrebbe avere un'indicazione di quanto sia importante. Sebbene sia impossibile creare una scala uniforme per il noleggio degli eventi in base all'importanza poiché organizzazioni diverse avranno priorità diverse (ad esempio, gli eventi che incidono sulla disponibilità rispetto alla riservatezza delle informazioni potrebbero essere letti in modo diverso)
Pertanto, un utile messaggio di registro di controllo dell'applicazione potrebbe assomigliare a questo:
31/12/2010 10:00:01 GMT+7 priorità=3, sistema=server principale, modulo=autenticazione, sorgente=127.0.0.1, utente=anton, azione=login, oggetto=database_PHI, stato=non riuscito, motivo="password errata"
A proposito, nota che un altro campo è stato aggiunto al messaggio di log di esempio sopra per spiegare il motivo dell'errore. Si noti inoltre che gli esempi precedenti non sono in XML: come accennato in precedenza, la leggibilità umana è una proprietà utile da avere nei log e i computer possono gestire le coppie nome=valore altrettanto bene che con XML. I messaggi basati su XML Health Level Seven (HL7) possono essere facilmente convertiti in testo, per le applicazioni che possono accedere a HL7.
Abbiamo anche menzionato in precedenza che la possibilità di centralizzare facilmente i log è essenziale per l'analisi dei log distribuiti su più sistemi o su più componenti applicativi di un'applicazione distribuita. Sebbene syslog sia stato il re della centralizzazione dei log grazie alla sua facile consegna UDP, i moderni framework applicativi multipiattaforma come un modello di chiamata per pubblicazione/sottoscrizione per la consegna dei log, simili a quelli utilizzati nelle moderne versioni di Windows. In questo caso lo strumento di monitoraggio della sicurezza può richiedere un abbonamento per un particolare tipo di evento registrato e ricevere tutti i registri rilevanti quasi in tempo reale, se necessario.
Conclusioni
Oltre a questa conclusione basilare - è necessario registrare l’accesso ai dati sanitari sensibili - dobbiamo ricordare ai nostri lettori che l’importanza della registrazione non potrà che aumentare, insieme alla crescente complessità delle applicazioni. In particolare, la necessità di analizzare il comportamento delle applicazioni e il movimento delle informazioni sensibili attraverso applicazioni distribuite e basate su cloud ci impone di tenere finalmente sotto controllo la registrazione delle applicazioni.
Gli architetti e gli implementatori del software devono "ottenere" la registrazione: NON esiste altro modo poiché la registrazione dell'infrastruttura da dispositivi di rete e sistemi operativi non è sufficiente per rilevare e indagare sulle minacce a livello di applicazione per le ePHI. Il team di sicurezza, responsabile in ultima analisi della revisione dei registri, dovrà guidare gli sviluppatori verso una registrazione utile ed efficace che possa essere utilizzata sia per il monitoraggio che per le attività investigative.
Certamente, gli standard di registrazione come MITRE CEE (cee.mitre.org) aiuteranno, ma potrebbero volerci alcuni anni prima che si sviluppino e la loro adozione aumenti. In attesa di uno standard globale, un'organizzazione dovrebbe creare rapidamente e quindi utilizzare il proprio standard di registrazione delle applicazioni per le applicazioni. La conformità HIPAA rappresenta una grande motivazione per creare e adottare tali standard di registrazione.
Notizie del settore
L'hacking di Pirate Bay mette alla luce il bottino degli utenti
Le debolezze della sicurezza nel popolarissimo sito di condivisione file thepiratebay.org hanno messo alla luce nomi utente, e-mail e indirizzi Internet di oltre 4 milioni di utenti di Pirate Bay... Un hacker argentino di nome Ch Russo ha detto che lui e due dei suoi soci hanno scoperto molteplici vulnerabilità di SQL injection che li hanno fatti entrare nel database degli utenti del sito.
Zeus è tornato con la corsa allo spam a tema terroristico
E-mail cariche di trojan che affermano di offrire informazioni ufficiali sul terrorismo hanno colpito le caselle di posta... Le e-mail sono falsificate per sembrare provenienti dal Dipartimento per la sicurezza interna degli Stati Uniti , Pentagono o Amministrazione per la sicurezza dei trasporti. Gli utenti sono incoraggiati a fare clic su due collegamenti che presumibilmente portano a rapporti, ma che in realtà sono file ZIP contenenti l'insidioso trojan Zeus, o Zbot.
Risorsa correlata: Webinar: Scopri come l'implementazione del controllo delle modifiche nella tua azienda può aiutarti a gestire le sfide critiche per la sicurezza, tra cui BOTnet e gli attacchi zero-day.
Un amministratore di database riceve 12 mesi per aver violato il suo datore di lavoro
Un ex amministratore di database per la GEXA Energy di Houston è stato condannato a 12 mesi di prigione e a una multa di 100.000 dollari per aver violato la rete del suo ex datore di lavoro. Ha avuto accesso da remoto alla rete GEXA Energy senza autorizzazione, ha compromesso la disponibilità dei dati e ha copiato un file di database contenente informazioni personali. GEXA Energy stima che le azioni di Kim abbiano comportato una perdita di almeno $100.000.
Lo sapevi? Le violazioni della sicurezza da parte di addetti ai lavori sono spesso le più difficili da scoprire, ma causano i danni maggiori e sono quelle più costose da riparare. EventTracker aiuta a monitorare tutte le attività degli utenti e degli amministratori, rilevando automaticamente le violazioni delle norme e i comportamenti insoliti o sospetti