Per adeguarsi al GDPR ed evitare violazioni dei dati personali, per le aziende è utile abbracciare processi di security by design e by default e adottare processi di Incident Response. In particolare, l’adozione dei server NTP (Network Time Protocol) aiuta a evitare i problemi legati alla mancata sincronizzazione oraria delle macchine. Serve dunque che le imprese intraprendano un cammino che le porti non solo a proteggere i dati, ma anche a valutare gli impatti sugli interessati in caso di un trattamento scorretto.
Indice degli argomenti
I dati nell’epoca di Industry 4.0
I Big Data e l’utilizzo sempre più diffuso di sistemi distribuiti legati all’Internet of Things (IoT) e a Industry 4.0 introducono non solo complessità tecnologica ed organizzativa con impatto sulla sicurezza delle informazioni ma rendono anche difficoltoso il conformarsi alle recenti norme europee che pongono particolare attenzione alla gestione delle violazioni di sicurezza (cosidetto network o data breach).
La quantità di dati che possono interagire fra loro è un fattore assolutamente critico che deve essere gestito. L’attenzione mondiale in questo momento è incentrata su tutte quelle tecnologie SW/HW legate a Big Data (ad esempio, distributed data handling/storage, scalability and parallel computing). È chiaro dunque a tutti l’importanza che questi dati forniscono, ma non è forse chiaro a tutti quali effetti catastrofici possono essere causati da un loro utilizzato errato o improprio. Serve dunque la massima attenzione alla loro gestione e messa in sicurezza (data integrity).
I problemi di sincronizzazione del tempo
Queste nuove tecnologie nascono con il primario obiettivo di monitorare, controllare e, se necessario, intervenire sul funzionamento di un determinato apparato produttivo o funzionalità ritenuta critica al proprio business. L’efficienza di questo processo non è legata alla sola acquisizione del dato (come il log). Oggi diventa fondamentale anche la capacità di analisi e correlazione che queste informazioni possono fornire. Si pensi a quei sistemi di preventive e predictive maintenance che sono in grado di minimizzare l’evento di fault (di varia natura) fornendo con sufficiente anticipo la probabilità che questo possa realmente avvenire in un determinato momento.
L’utilizzo di sistemi distribuiti e quindi la loro dislocazione spesso non limitata al territorio nazionale, può essere fonte di problematiche di sicurezza. Ogni dispositivo di fatto genera degli eventi. Per registrare l’istante in cui un evento è accaduto, ogni dispositivo è dotato di un orologio interno. L’evento può essere conseguenza di situazioni generate da altri sistemi o essere esso stesso l’evento scatenante di altri eventi.
L’orologio interno, potrebbe, se non adeguatamente sincronizzato con gli orologi degli altri dispositivi, registrate eventi avvenuti successivamente con date antecedenti all’evento generatore, rendendo di fatto molto difficile risalire alla corretta cronologia. Per tale motivo, alcuni dispositivi, come ad esempio gli storage contenenti informazioni anche molto sensibili, necessitano dell’utilizzo di sistemi di sincronizzazione evoluti che permettano di conformare gli orari.
A seconda dei casi, la precisione richiesta può essere del centesimo di secondo. La mancanza di sincronizzazione degli orologi potrebbe generare problemi quali ad esempio l’impossibilità di esecuzione di alcuni programmi o di accedere a risorse di rete condivise, errori di validità dei certificati utilizzati dai siti web, impostazione della data di invio di una mail di molto antecedente a quella effettiva, limitare in modo considerevole le analisi di dati.
Le conseguenze di queste anomalie possono anche essere importanti. Si possono avere perdite economiche per le aziende o impatti sui diritti e le libertà degli interessati. Tali impatti potrebbero avere conseguenze trascurabili come la perdita di tempo nel ripetere alcune formalità o multe imposte erroneamente, oppure più significative come la perdita di prova nel contesto di un contenzioso o il mancato accesso ad infrastrutture vitali.
Il formato dell’ora
Oltre alla sincronizzazione degli orologi ed all’accuratezza della sincronizzazione stessa, è importante anche il formato con cui l’informazione del tempo è registrata dal sistema. Come citato nel documento NIST SP 800-92 “Guide to computer security log management”, un sistema potrebbe generare dei log in cui l’ora dell’evento è indicato in formato a 12 ore (timestamp) mentre un altro sistema potrebbe essere indicato in formato 24 ore (Event Time), con l’opzione fuso orario memorizzato in diverse notazioni, ad esempio in un campo diverso classificato come Fuso orario.
Per ovviare ai problemi di formato, è possibile emettere delle regole tecniche interne all’organizzazione o adottare quelle emesse da enti esterni. Un esempio di quest’ultima tipologia di regole sono quelle emesse per il servizio di PEC, per cui sono espresse chiaramente le modalità per la generazione dei “riferimenti temporali” e del “formato data/ora utente”. Un’altra attività tipica che viene eseguita prima di procedere alla memorizzazione di dati su sistemi di “Event Correlation”, per ovviare ai problemi di orario o comunque di formato in genere, è la normalizzazione di tutte le informazioni inviate dalle diverse sorgenti.
La normalizzazione delle informazioni
Ogni sorgente genera i dati in un formato avente un determinato tracciato record. Nella normalizzazione ogni campo del tracciato record ricevuto in input, viene convertito in un nuovo tracciato che permette la memorizzazione dei dati in modo coerente. Un esempio tipico di normalizzazione è quella che avviene appunto sulle date ed ha come obiettivo quello di memorizzarle in un unico formato comparabile, in quanto afferenti ad eventi avvenuti nello stesso arco temporale.
La normalizzazione delle date permette quindi di semplificare le attività di analisi e reportistica, soprattutto quando le fonti di dati sono generate da sistemi aventi diversi fusi orari. È bene precisare che a seconda della quantità di dati da normalizzare, questa attività potrebbe anche essere molto dispendiosa sia in termini di risorse che di tempi di elaborazione. Avere tempi di normalizzazione lunghi così come disporre di orologi desincronizzati, non permette di ottenere i dati necessari per l’individuazione di eventuali anomalie e quindi non permettono di intervenire tempestivamente.
Il processo di Incident Response
Una violazione di dati personali, ad esempio, come citato nel Considerando 85 del GDPR “può, se non affrontata in modo adeguato e tempestivo, provocare danni fisici, materiali o immateriali alle persone fisiche”. Diventa pertanto fondamentale per le aziende dotarsi di un processo di Incident Response, che come descritto nel documento NIST SP 800-61r2 “Computer security incidente handling guide” deve prevedere diverse fasi: Preparation, Detection & Analysis, Containment, Eradication, & Recovery, Post-Incident Activity.
La fase più importante è quella di Preparation. In questa fase si predispongono tutte quelle attività tecnico-organizzative adeguate a far fronte ad un incidente quali ad esempio la predisposizione di documentazione, attività di Training & Education, presidi tecnici (ad esempio, sistemi di Intrusion Detection Prevention System (IDPS), Security Information and Event Management (SIEM), Antivirus Antispam, system network and application logging) ed organizzativi (Security Operation Center – SOC, Network Operation Center – NOC, Incident Response Team – IRT). Diventa mandatorio in questa fase assicurarsi che tutti i sistemi che vengono gestiti abbiano gli orari sincronizzati.
L’utilità dei server NTP
Il metodo migliore per ottenere questo risultato è, ove possibile, l’utilizzo di tecnologie di sincronizzazione come i server NTP (Network Time Protocol), che permettono di sincronizzare periodicamente l’orario dell’orologio del sistema con quello degli altri server in internet, assicurando di fatto di non incorrere in incoerenze di orari. Riveste fondamentale importanza verificare di aver configurato correttamente il servizio NTP. Alcuni sistemi operativi, in particolare se utilizzati su macchine virtuali, potrebbero avere problemi nel mantenere gli orologi in sincronia pertanto potrebbero richiedere specifiche modifiche a livello di kernel o opzioni di configurazione particolari dell’NTP.
Oltre a configurare l’NTP su tutti i dispositivi che lo supportano, è consigliabile impostare il medesimo server NTP e decidere un formato data (GMT offset o fuso orario) coerente in tutta l’organizzazione. È importante assicurarsi che i server NTP permettano ai client di connettersi per sincronizzarsi ma ignorino qualsiasi aggiornamento o altra informazione sugli orari da sistemi diverse dalle fonti di clock peer e upstream, cioè le fonti configurare come “di default o ufficiali”.
È inoltre opportuno attivare un monitoraggio del servizio NTP, in modo da essere sicuri che tale servizio stia funzionando correttamente. Tale monitoraggio potrebbe essere fatto confrontando un orologio locale con più server NTP tenendo memorizzato l’offset medio. Sui sistemi critici anche discostamenti di una frazione di secondo dovrebbero essere segnalati mediante opportuna allarmistica mentre per i sistemi meno sensibili dovrebbero essere segnalati discostamenti dell’ordine dei secondi o solo in caso l’orologio non risulti funzionante per un determinato periodo.
La configurazione corretta
Una corretta configurazione dell’NTP è necessaria, non solo per avere gli orari corretti, ma anche per evitare che esso stesso diventi una minaccia. Il servizio NTP, così come altri servizi, ha la potenzialità di “reflection and amplification”, che gli attaccanti potrebbero sfruttare per potenziare gli attacchi DDoS (Distribuited Denial of Service).
Una volta configurato correttamente l’NTP ed aver concluso le attività di “Preparation”, si procede alla fase di Incident Response successiva, quella di “Detection & Analysis” il cui scopo è la rilevazione, segnalazione, analisi e classificazione di un evento. È in questa fase che le informazioni prodotte dai vari dispositivi o applicativi, vengono raccolte ed analizzate. L’utilizzo erroneo dell’NTP renderebbe di fatto non efficaci tutte le azioni previste, in particolare le attività di analisi degli eventi e la relativa registrazione diventerebbe incredibilmente complessa. Tale complessità avrebbe ripercussioni significative anche nelle fasi successive di “Containment, Eradication, & Recovery” in cui si sarebbe dovuto provvedere al contenimento dell’evento e ripristino dei sistemi.
Analogamente anche le attività di indagini e raccolta di evidenze, che si affiancano alla gestione ordinaria degli incidenti, verrebbero compromesse. Ad esempio, non sarebbe possibile creare una cronologia degli eventi che hanno avuto luogo durante la violazione.
Conclusioni
In conclusione, è consigliabile dotarsi, non solo di sistemi tecnologici che ci permettano di individuare le violazioni nel rispetto dei tempi previsti dalle normative vigenti, ma di processi di Security & Privacy by design/by default che prendano in considerazione la predisposizione di un “Incident Response Plan” che consideri tutti gli aspetti, compresi quelli derivati dall’utilizzo di nuove tecnologie sempre più pervasive sia geograficamente che nella vita di tutti i giorni.
Questi processi introducono nelle aziende un cambiamento culturale, improntato non solo sulla protezione dei dati ma anche sulla valutazione degli impatti sugli interessati che un determinato trattamento, se non correttamente gestito, può avere.
Applicato al trattamento di dati personali, questo cambiamento, dimostra di fatto il rispetto del principio di accountability previsto dal GDPR in quanto vengono adottate politiche e misure di sicurezza che permettono di dimostrare, che è stato tenuto conto della natura, del campo di applicazione, del contesto nonché dei rischi di varia probabilità e gravità per i diritti e le libertà delle persone fisiche e quindi si è in grado di dimostrare che il trattamento dei dati personali è stato effettuato conformemente al Regolamento stesso.
