LA GUIDA

Data protection: quali prassi adottare per la protezione e il controllo dei dati

I dati digitali sono soggetti a più di un tipo di minaccia, prime tra tutte lo spear phishing e il ransomware. Inoltre, i crescenti requisiti normativi come quelli della Direttiva NIS e del GDPR, accrescono la sfida della data protection. Ecco le prassi da adottare per la protezione e il controllo dei dati

08 Giu 2022
V
Alessia Valentini

Giornalista, Cybersecurity Consultant e Advisor

La protezione dei dati digitali è soggetta a più di un tipo di minaccia: la prima fra tutte è quella legata alle vulnerabilità delle persone che cadono vittime di spear phishing (attacco mirato alla persona per raggiro o truffa ai suoi danni o a quelli dell’organizzazione di appartenenza n.d.r.). Subito a seguire i ransomware la cui devastante serie di conseguenze può bloccare l’operatività di una organizzazione.

Non da meno, sono pericolose le criticità legate a furto, sottrazione e/o perdita di credenziali utente o amministrative per l’accesso ad applicazioni e dati aziendali.

Non sono da sottovalutare anche tutte le casistiche legate ad attaccanti interni, cosiddetti insiders, che per motivi diversi possono voler arrecare un danno all’azienda. Similmente agli insiders, possono esistere fornitori che nella catena di fornitura (supply chain) condividono accessi a risorse aziendali e che, se soggetti a incidente informatico, possono trasformarsi in un veicolo di infezione a loro volta verso l’organizzazione loro cliente.

Infine, i crescenti requisiti normativi, in particolare quelli nell’Unione Europea (Direttiva NIS, GDPR), accrescono la sfida della data protection, richiedendo una gestione adeguata al livello di valutazione del rischio ed un set di misure di protezione che deve essere legato all’efficace delle misure di prevenzione degli incidenti e non impostato a misure prefissate come negli impianti normativi precedenti al Regolamento per la protezione dei dati.

Giuseppe Misale, direttore commerciale e Marketing di Multipartner in questo senso spiega che: “molte aziende gestiscono dati considerati “sensibili” (sia di tipo personale sia di tipo aziendale) ma per lavoro devono condividerli nella supply chain con clienti e fornitori oppure come nel caso dei ricercatori che studiano brevetti industriali. In questi casi la protezione dei dati rappresenta la protezione della proprietà intellettuale. Le organizzazioni vogliono in generale evitare l’esfiltrazione di dati strategici o personali, ma vogliono continuare a condividere dati. La perdita di dati da attacchi informatici è critica in tutti i settori di mercato, anche se scenari del tipo sopraccitato sono frequenti nelle aziende farmaceutiche, in ambito sanitario ed anche per tutte quelle aziende che sviluppano codice. Non da meno vi sono anche esfiltrazioni di metadati aziendali che se modificati in modo malevolo, possono portare un danno di reputazione. I metadati sono insieme di informazioni sui dati veri e propri. I metadati aziendali sono tipi di informazioni scaturite dal trattamento digitale, ma riconducibili con certezza ad una determinata azienda”.

Le prassi di sicurezza che non dovrebbero mai mancare

La data protection “secondo il GDPR” deve essere ugualmente applicata alle tre caratteristiche dell’informazione ovvero riservatezza, integrità e disponibilità (RID), seguendo un approccio basato sul rischio: maggiore è il rischio, più rigorose sono le misure che il titolare del trattamento o il responsabile del trattamento deve adottare per gestire il rischio. In generale le misure di protezione dati sono applicabili a seconda se il dato è “at rest” ovvero se è staticamente mantenuto in un sistema digitale, o se è “in transit” cioè se viene comunicato da un punto all’altro di un sistema di comunicazione.

Per i dati “at rest” è necessario poter garantire la sicurezza a livello degli endpoint, dei server che elaborano i dati, in ogni supporto dati esterno (chiavette, Dischi esterni etc) e a livello di monitor per evitare la visualizzazione in chiaro dei dati. Tuttavia, anche a livello applicativo sono necessari accorgimenti per i DataBase (DB) coinvolti nella gestione dati prevedendo utilizzo di crittografia e data masking ma anche paseudonimizzazione.

Per i dati “in transit” è necessario invece garantire canali di comunicazione criptati e sicuri che possano evitare i cosiddetti attacchi Man In The Middle (MITM), Naturalmente legati alla data protection sono essenziali le prassi di backup sicuro, di Business Continuity e di Disaster Recovery.

Laura Atzeni, PM progetti speciali di Multipartner, spiega che in tema di data protection: “è preferibile utilizzare sia l’anonimizzazione che la crittografia quando il dato è “at rest”, mentre quando il dato si trova “in transit” consiglio di adottare un livello di crittografia come il TLS 1.3. Le architetture abilitanti delle soluzioni che gestiscono dati dovrebbe essere pensate in alta affidabilità, in favore della business continuity e del disaster recovery, senza dimenticare prassi di autenticazione a due fattori con fattori diversi fra loro, la configurazione degli accessi basati su ruoli (Role based Access Controls – RBAC) e la pianificazione e test di back up. Ma se queste sono misure tecniche necessarie è doveroso anche ricordare che la sicurezza risiede al 99% sull’atteggiamento delle persone; quindi, si dovrebbe insegnare e far crescere le competenze di sicurezza nell’azienda. Ancora oggi esistono abitudini deprecabili che possono aumentare i rischi”.

Luca D’alessandro, Responsabile R&D di Multipartner aggiunge che: “Tecnicamente una piattaforma di gestione dati che offra caratteristiche di data protection deve garantire sicurezza coniugata a prestazioni operative e ad una affidabilità ridondata, con un uptime almeno del 99,9%. Operativamente i dati seppur condivisi e costantemente scambiati devono poter essere protetti da attacchi di tipo MTTM o da quelle situazioni di attacco riconducibili a DDoS che puntano a interrompere il servizio a partire dall’infrastruttura abilitante. Questo ha effetto sulla caratteristica di disponibilità del dato, mentre per la componente di Integrità sono necessari controlli di sicurezza che oltre al controllo, traccino i dati facendo emergere interventi di alterazione. Infine, per le soluzioni offerte in Cloud suggerisco di richiedere sempre al Cloud Provider dove sia localizzata la server farm di riferimento, in relazione al tema della sovranità digitale sui dati, legata alla maggior protezione dei dati in EU”.

In tutti i casi in cui una azienda deve garantire la data protection dei propri dati, ma non sa da dove iniziare, la roadmap più appropriata passa per la valutazione delle esigenze di business relative alla gestione ed elaborazione dei dati, coniugata ad una valutazione di rischio.

Sulla base di queste analisi si determina un effort di risorse tecnologiche potenziali per abbassare il rischio, il corrispettivo di spesa economica da affrontare (da comparare al budget disponibile) e l’entità delle competenze interne all’azienda, per capire se sia preferibile sviluppar in casa, oppure utilizzare un provider fidato e la sua soluzione.

Laura Atzeni suggerisce di scegliere un provider che sia almeno qualificato AGID perché, aggiunge: “anche se AGID qualifica i fornitori Cloud per i servizi alla PA, il valore del Provider resta tale anche per erogare servizi a qualsiasi altra azienda. La nostra azienda si è qualificata Cloud Service Provider e come Saas Provider dal 2019”.

Strumenti di protezione dei dati: un esempio

Alla lecita domanda legata a come procedere nel caso in cui una azienda voglia implementare soluzioni di data protection ma abbia già applicativi diversi installati secondo una architettura a silos, è possibile rispondere suggerendo di adottare anche in questo caso una roadmap che inizi da un assesment interno sulle tecnologie e le competenze esistenti in azienda per poi determinare l’obiettivo finale e il gap da colmare coniugato nuovamente a temi di effort (tempi e costi).

“Quale che sia il risultato della scelta, se usare un applicativo Saas in cloud o sviluppare in azienda”, chiarisce Luca D’alessandro: “ogni organizzazione deve curare l’educazione non solo dei dipendenti, ma anche degli sviluppatori, per creare codice sicuro seguendo linee guida come quelle della Owasp Top 10. Anche noi abbiamo seguito questi accorgimenti di programmazione sicura per la nostra piattaforma di gestione documentale ed in particolare per proteggere l’integrità del dato è stata aggiunta una filigrana dinamica (watermark) e una filigrana steganografica che raccoglie info sui dati per il controllo e tracciamento. Per la componente di riservatezza dei dati si adotta uno strato di protezione mediante crittografia forte a chiave simmetrica per la cifratura dei file e uno schema di gestione a chiave pubblica per l’accesso alle chiavi di cifratura (ENIGMA). Invece la disponibilità del dato è affidata all’architettura abilitante che è implementata in modo ridondato”.

Qualsiasi soluzione di un fornitore esterno deve garantire all’organizzazione di non essere essa stessa un elemento vulnerabile agli attacchi, ovvero evitare di diventare una estensione della superficie di attacco. Nei casi di soluzioni SaaS (Software as a Service) sono i Cloud provider che si occupano di parte della protezione infrastrutturale, ma il codice abilitante dovrebbe essere soggetto ad audit sia interni sia di terzi parti (audit in black box e white box), a periodici controlli periodici ma cadenzati di VA/PT sul codice e sull’infrastruttura, come anche a patching continuo.

Luca D’alessandro suggerisce di verificare anche l’adozione di algoritmi di detection di cryptolocker, nelle fasi di caricamento dati e di chiedere se l’infrastruttura abilitante sia sotto monitoraggio per prevenire attacchi configurazione e movimenti laterali attivando predeterminate soglie di allerta che possa scatenare dei warning di avvertimento.

Contributo editoriale sviluppato in collaborazione con Multipartner

@RIPRODUZIONE RISERVATA

Articolo 1 di 5