La Privacy nella Farmacia 2.0

Negli ultimi anni, le farmacie hanno ampliato la gamma di servizi offerti ai cittadini, evolvendo da semplici punti di dispensazione di farmaci a veri e propri presidi sanitari di prossimità. Questa trasformazione ha portato a una maggiore gestione di dati personali anche appartenenti a categorie particolari, imponendo ai farmacisti il dovere di rispettare rigorosamente la normativa sulla protezione dei dati personali, in particolare il Regolamento Generale sulla Protezione dei Dati (GDPR), il Codice Privacy novellato (D.Lgs 196/2002 aggiornato dal D.Lgs 101/20218) e le linee guida nazionali.



L’Importanza del GDPR nella Gestione dei Dati Sanitari

Il GDPR ha introdotto principi chiave che i farmacisti devono seguire nella gestione dei dati personali, tra cui:

  • Liceità, correttezza e trasparenza: I dati devono essere raccolti con il consenso esplicito dell’interessato e trattati in modo chiaro, ma solo nei casi in cui tale consenso è necessario, oppure in base ad altra base giuridica come stabilito dal GDPR (ad esempio non per la dispensazione di farmaci dietro presentazione di ricetta medica). Il tutto supportato da adeguata informativa all’interessato.
  • Limitazione delle finalità: Le informazioni devono essere utilizzate esclusivamente per gli scopi dichiarati, come la fornitura di servizi sanitari o la gestione delle prescrizioni mediche e non per finalità di marketing.
  • Minimizzazione dei dati: Devono essere raccolti solo i dati strettamente necessari per l’erogazione del servizio (ad esempio nella raccolta punti per ottenere sconti o per le carte fedeltà).
  • Integrità e riservatezza: Devono essere adottate misure tecniche e organizzative per garantire la sicurezza dei dati ed evitare accessi non autorizzati.

Nuovi Servizi Farmaceutici

L’introduzione di servizi innovativi, come la telemedicina, la prenotazione online di farmaci e la consulenza tramite strumenti digitali (whatsapp, e-mail, sito web), ha reso ancora più cruciale il rispetto della normativa sulla protezione dei dati.

Questi servizi spesso richiedono l’acquisizione e la conservazione di informazioni sanitarie sensibili, aumentando il rischio di violazioni della privacy. Ad esempio, piattaforme web che offrono il ritiro di farmaci su prenotazione o servizi di consulto devono garantire che i dati siano trasmessi e conservati in modo sicuro, evitando la condivisione non autorizzata con terze parti.

Obblighi dei Farmacisti nella Protezione dei Dati

I farmacisti hanno la responsabilità di garantire la conformità alle normative vigenti attraverso:

  • Formazione continua: Aggiornarsi costantemente sulla normativa (GDPR, Codice Privacy, Linee Guida EDPB, Provvedimenti del Garante Privacy nazionale) e sulle migliori pratiche per la protezione dei dati.
  • Adozione di misure di sicurezza: Implementare sistemi di protezione informatica per evitare attacchi hacker e accessi non autorizzati.
  • Gestione dei consensi: Assicurarsi che i pazienti siano pienamente informati su come vengono trattati i loro dati e ottenere il consenso esplicito quando necessario, in particolare nei servizi di telemedicina.
  • Registrazione e tracciabilità: Mantenere documentazione sulle procedure adottate per la protezione dei dati e garantire la tracciabilità di ogni operazione effettuata.

Il rispetto della normativa sulla protezione dei dati non è solo un obbligo legale, ma anche un elemento fondamentale per tutelare la fiducia dei pazienti nei confronti delle farmacie. La crescente digitalizzazione dei servizi richiede un approccio consapevole e responsabile nella gestione dei dati personali, per garantire la sicurezza e la riservatezza delle informazioni sanitarie. I farmacisti devono quindi adottare tutte le misure necessarie per proteggere la privacy dei loro clienti e operare nel pieno rispetto della normativa vigente.

Il rischio nella gestione dei nuovi servizi

Oggi le farmacie italiane offrono una vasta gamma di servizi, tra cui la dispensazione di farmaci con e senza ricetta, la telemedicina (ECG a distanza, Holter pressorio e Holter sanguigno), la prenotazione online di farmaci, l’accettazione di campioni biologici per lo svolgimento di esami di laboratorio e il ritiro dei referti di esami di laboratorio, la misurazione della pressione, test diagnostici rapidi (emocromo, profilo lipidico, ecc.), vaccinazioni e servizi di assistenza personalizzata per i pazienti cronici, analisi della pelle e del capello, nonché vendita di prodotti on-line (e-commerce).

Nel rapporto fra farmacia e fornitore di servizi, i ruoli soggettivi in materia di privacy possono variare in base alle attività svolte. La farmacia, generalmente, agisce come Titolare del trattamento dei dati personali, in quanto determina le finalità e i mezzi del trattamento. Il fornitore di servizi, invece, può assumere il ruolo di Responsabile del trattamento quando tratta i dati per conto della farmacia, seguendo le istruzioni ricevute. Spesso, tuttavia, è il fornitore stesso che determina mezzi e finalità del trattamento dei dati personali, poiché gestisce la parte fondamentale del processo di erogazione del servizio: si pensi ai servizi di telemedicina come l’ECG o l’esecuzione di esami di laboratorio a seguito di campioni prelevati in farmacia.

È fondamentale che tra le parti venga stipulato un accordo chiaro per garantire la conformità al Regolamento UE 679/2019 (GDPR) e la protezione dei dati personali dei pazienti. Tale accordo per i servizi dove è il fornitore a determinare mezzi (ad esempio strumenti informatici) e finalità del trattamento (ad esempio esecuzione di esami di laboratorio) deve riportare esplicitamente la nomina della Farmacia a Responsabile del Trattamento e investire il fornitore del ruolo di Titolare. Diversamente la Farmacia sarà esposta a rischi di sanzione e risarcimento danni in caso di violazioni di dati perpetrate nei sistemi del fornitore.

In particolare, per quanto riguarda i servizi svolti per conto di ASL o del Servizio Sanitario Nazionale (SSN) le farmacie agiscono come Responsabili del Trattamento. Negli ultimi anni, oltre ai servizi più propriamente sanitari, hanno iniziato a svolgere anche servizi come l’attivazione dello SPID (per conto di Lepida nella Regione Emilia-Romagna) e del Fascicolo Sanitario.

Altro aspetto critico è l’esecuzione di esami sanguigni con apparecchiature automatiche (in autoanalisi), oggetto di recenti polemiche sulla qualità degli esiti a seguito di un’inchiesta di Milena Gabbanelli sulla base di uno studio effettuato dalla National Library of Medicine. Spesso le farmacie non hanno consapevolezza di quali dati vengono raccolti e conservati dal software e se il fornitore dell’apparecchiatura ha accesso ai dati dei referti, mentre il Regolamento UE 679/2016 richiede un’informativa chiara da fornire al paziente con garanzia del rispetto di tutti i suoi diritti.

Le stesse criticità sono presenti nell’erogazione di servizi di analisi varie (analisi della pelle, analisi del capello, densitometria, intolleranze alimentari, ecc.), spesso proposti in partnership con il fornitore dell’apparecchiatura di analisi o del kit di raccolta campioni con analisi svolta dal laboratorio del fornitore. Per questi servizi il fornitore dovrebbe fornire al farmacista un servizio con trattamento di dati personali privacy-by-design, ma sovente così non è, facendo ricadere sulla farmacia l’onere di fornire al paziente un’informativa privacy con richiesta di consenso adeguata e di disciplinare il rapporto con il fornitore che sovente è poco collaborativo dal punto di vista della gestione dei dati personali.

Anche le diffuse carte fedeltà (fidelity card) delle farmacie sono spesso gestite in modo non conforme ai requisiti normativi con informative carenti o addirittura assenti e conservazione dei dati personali del cliente oltre quanto indicato dal Garante Privacy.

Proprio in virtù dell’enorme mole di dati personali che le farmacie trattano, devono adottare una serie di misure di sicurezza per proteggere i dati personali dei propri clienti. Tra queste rientrano l’uso di software aggiornati e certificati per la gestione dei dati, l’adozione di sistemi di autenticazione a più fattori per limitare l’accesso non autorizzato, la crittografia delle informazioni sensibili, la formazione continua del personale sulle best practice in materia di protezione dei dati e la stipula di accordi di riservatezza con eventuali fornitori di servizi esterni. Inoltre, è fondamentale effettuare controlli periodici e audit per verificare la conformità alle normative vigenti e garantire la sicurezza delle informazioni trattate.

Infine, i siti web delle farmacie non sono più dei siti solo di presentazione a scopo pubblicitario, ma sono diventati – in alcuni casi – veri e propri portali web – talvolta anche associati ad app per dispitivi mobili – dove si possono prenotare i servizi sopra indicati, prenotare farmaci trasmettendo anche la ricetta medica o addirittura acquistare prodotti attraverso siti di e-commerce. Adottare questi strumenti, magari associati a servizi di digital marketing come l’invio di newsletter promozionali, amplia enormemente gli adempimenti privacy della farmacia e il parco dei fornitori coinvolti nel trattamento dei dati personali che spesso non forniscono adeguato supporto nell’implementare servizi conformi alla normativa privacy.

Oggi, con i le nuove minacce provenienti da internet, come i ransomware, il phishing e gli attacchi mirati di hacker che cercano non solo di cifrare, rendendoli inaccessibili, i dati della vittima, ma anche di esfiltrarli, rendendo maggiormente efficace la c.d. “double extortion”: «se vuoi accedere nuovamente ai tuoi dati devi pagare il riscatto, ma se non lo paghi posso pubblicare sul web i dati personali dei tuoi clienti… ».

Contro queste minacce, e con un perimetro nel quale operano i sistemi informatici molto esteso, non basta più dichiarare di avere l’antivirus, le password e di fare il backup per garantirsi l’immunità rispetto alle eventuali sanzioni del Garante Privacy. È necessario dimostrare di aver attuato misure di sicurezza adeguate a seguito di una valutazione dei rischi.

Per dimostrare di aver adempiuto ai requisiti del GDPR non basta aver redatto il registro dei trattamenti, ma è necessario anche documentare la valutazione dei rischi (da aggiornare periodicamente), le misure di sicurezza tecniche ed organizzative adottate, gli accordi per la protezione dati con i fornitori/partner come responsabili del trattamento, le istruzioni al personale sull’utilizzo dei sistemi informatici e così via.

Purtroppo oggi è facile trovare farmacie che non sono in grado di dimostrare di aver adottato adeguate misure di sicurezza perché tali misure non sono documentate e sono note solo a qualche consulente informatico che le ha implementate senza avere un idoneo contratto per la gestione sistemistica dei sistemi della farmacia ed una nomina di Amministratore di Sistema.

I rischi che si corrono ignorando questa normativa sono importanti: oltre alle eventuali sanzioni del Garante per la Protezione dei Dati Personali (fino al 4% del fatturato annuo nei casi più gravi), un attacco ransomware potrebbe bloccare l’attività della farmacia per diversi giorni (con annesso rischio reputazionale) e l’eventuale violazione della riservatezza dei dati personali dei clienti potrebbe comportare richieste di risarcimento del danno molto onerose.

Ecco qui https://www.teleperformanceitalia.it/attacchi-informatici-hacker-rubano-gli-account-delle-farmacie-con-i-bot/?utm_source=chatgpt.com un esempio di attacchi hacker registrate contro farmacie.




La ISO 27005 per la gestione del rischio nella sicurezza delle informazioni

La norma ISO/IEC 27005:2022 fornisce linee guida per la gestione dei rischi legati alla sicurezza delle informazioni, alla cybersecurity e alla protezione della privacy. In questo articolo esamineremo i principali elementi trattati dalla norma, disponibile solo in lingua inglese.

La norma ISO/IEC 27005:2022, pubblicata nell’ottobre 2022, introduce diverse modifiche rispetto all’edizione precedente del 2018. I principali cambiamenti possono essere riassunti come segue:

  1. Allineamento con altre norme: Il testo è stato aggiornato per essere coerente con la ISO/IEC 27001:2022 e la ISO 31000:2018, garantendo una maggiore armonizzazione tra gli standard relativi alla gestione della sicurezza delle informazioni e del rischio.
  2. Introduzione degli scenari di rischio: Sono stati introdotti i concetti relativi agli scenari di rischio, che aiutano a comprendere meglio le potenziali minacce e le loro conseguenze attraverso la definizione di sequenze o combinazioni di eventi che possono portare a risultati indesiderati.
  3. Approccio basato sugli eventi: Oltre al tradizionale approccio basato sugli asset, la nuova edizione introduce l’approccio basato sugli eventi per l’identificazione dei rischi. Questo metodo si concentra sull’analisi di eventi e conseguenze, spesso derivanti dalle preoccupazioni della direzione o dai requisiti organizzativi, offrendo una prospettiva più strategica nella gestione del rischio.
  4. Revisione della struttura e dei contenuti: La norma è stata riorganizzata, passando da 12 clausole e 6 appendici nell’edizione 2018 a 10 clausole e un’appendice nella versione 2022. Questa ristrutturazione mira a migliorare la chiarezza e l’usabilità del documento. citeturn0search0

Queste modifiche riflettono l’evoluzione delle pratiche di gestione del rischio nel campo della sicurezza delle informazioni, offrendo alle organizzazioni strumenti aggiornati per affrontare le sfide emergenti in questo ambito.



Introduzione

La norma è progettata per assistere le organizzazioni nel soddisfare i requisiti della ISO/IEC 27001, in particolare per quanto riguarda la valutazione e il trattamento dei rischi per la sicurezza delle informazioni. È applicabile a tutte le organizzazioni, indipendentemente dal tipo, dalla dimensione o dal settore.

La norma sottolinea l’importanza di mantenere informazioni documentate riguardanti il processo di valutazione dei rischi, così come il processo di trattamento dei rischi risultati non accettabili.

La ISO 27005 del 2022 fornisce linee guida per la valutazione dei rischi ai fini della ISO 27001 per il sistema di gestione della sicurezza delle informazioni

Viene definito il contesto esterno come l’ambiente in cui l’organizzazione opera, che può includere fattori sociali, culturali, legali e tecnologici. Questo contesto è fondamentale per identificare e valutare i rischi.

La norma è stata allineata con la ISO/IEC 27001:2022 e la ISO 31000:2018, garantendo coerenza terminologica e strutturale. Sono stati introdotti concetti come gli scenari di rischio e un approccio basato sugli eventi per l’identificazione dei rischi.

La norma è organizzata in modo da facilitare la comprensione e l’applicazione delle linee guida, con un focus su come le organizzazioni possono implementare efficacemente le pratiche di gestione dei rischi.

In sintesi, ISO/IEC 27005:2022 offre un quadro completo per la gestione dei rischi di sicurezza delle informazioni, aiutando le organizzazioni a proteggere i propri dati e a mantenere la fiducia degli stakeholder.

Come deve essere condotta la valutazione dei rischi per la sicurezza delle informazioni?

Secondo la norma ISO/IEC 27005:2022 “Information security, cybersecurity and privacy protection — Guidance on managing information security risks” (Sicurezza delle informazioni, cybersecurity e protezione della privacy – Guida alla gestione dei rischi per la sicurezza delle informazioni), la valutazione dei rischi per la sicurezza delle informazioni deve essere condotta seguendo un processo strutturato che comprende diverse fasi. Ecco i principali passaggi da seguire:

  1. Identificazione dei rischi: Questa fase prevede la ricerca, il riconoscimento e la descrizione dei rischi. È importante considerare sia le minacce che le vulnerabilità che possono influenzare la sicurezza delle informazioni.
  2. Analisi dei rischi: In questa fase, si analizzano i rischi identificati per comprendere i tipi di rischio e determinare il loro livello. L’analisi dei rischi implica la valutazione delle cause e delle fonti di rischio, la probabilità che si verifichi un evento specifico e la gravità delle conseguenze associate.
  3. Valutazione dei rischi: Questa fase consiste nel confrontare i risultati dell’analisi dei rischi con i criteri di rischio stabiliti per determinare se il rischio e/o la sua significatività sono accettabili. Si deve anche prioritizzare i rischi analizzati per il trattamento. In base a questo confronto, si può decidere se è necessario un trattamento del rischio.
  4. Definizione del contesto: È fondamentale stabilire il contesto della valutazione dei rischi, che include la descrizione dello scopo e dell’ambito, nonché le questioni interne ed esterne che influenzano la valutazione stessa.
  5. Allineamento con la gestione dei rischi organizzativa: L’approccio alla gestione dei rischi per la sicurezza delle informazioni deve essere allineato con l’approccio generale alla gestione dei rischi dell’organizzazione, in modo che i rischi di sicurezza delle informazioni possano essere confrontati con altri rischi organizzativi.
  6. Utilizzo di metodi e strumenti: La valutazione dei rischi dovrebbe basarsi su metodi e strumenti progettati in modo da garantire risultati coerenti, validi e riproducibili. L’output della valutazione deve essere comparabile nel tempo per monitorare eventuali variazioni nel livello di rischio.

In sintesi, la valutazione dei rischi per la sicurezza delle informazioni secondo la ISO/IEC 27005:2022 è un processo sistematico che richiede attenzione a vari aspetti, dalla identificazione e analisi dei rischi fino alla loro valutazione e allineamento con la gestione dei rischi complessiva dell’organizzazione.

Quali sono, secondo questa normativa, le principali minacce alla sicurezza delle informazioni da considerare?

Per la norma ISO/IEC 27005:2022, le minacce alla sicurezza delle informazioni possono variare a seconda del contesto e delle specifiche circostanze in cui opera un’organizzazione. Tuttavia, ci sono alcune categorie generali di minacce che le organizzazioni dovrebbero considerare durante il processo di valutazione dei rischi. Ecco alcune delle principali minacce:

  1. Minacce interne: Queste possono includere dipendenti o collaboratori che, intenzionalmente o accidentalmente, compromettono la sicurezza delle informazioni. Ciò può includere la divulgazione non autorizzata di informazioni sensibili o l’uso improprio delle risorse aziendali.
  2. Minacce esterne: Queste comprendono attacchi provenienti da fonti esterne all’organizzazione, come hacker, gruppi di cybercriminali o concorrenti. Gli attacchi informatici, perpetrati attraverso malware, phishing e ransomware, rientrano in questa categoria.
  3. Errori umani: Gli errori commessi da dipendenti o collaboratori, come la configurazione errata di sistemi o la gestione inadeguata delle credenziali, possono rappresentare una minaccia significativa per la sicurezza delle informazioni.
  4. Disastri naturali: Eventi come terremoti, inondazioni, incendi o altre calamità naturali possono danneggiare le infrastrutture e compromettere la sicurezza delle informazioni.
  5. Guasti tecnologici: Malfunzionamenti hardware o software, guasti di rete o interruzioni di servizio possono influenzare la disponibilità e l’integrità delle informazioni.
  6. Minacce legate alla supply chain: Le vulnerabilità o i rischi associati ai fornitori e ai partner commerciali possono rappresentare una minaccia per la sicurezza delle informazioni, specialmente se questi hanno accesso ai sistemi o ai dati sensibili dell’organizzazione.
  7. Minacce alla privacy: La raccolta, l’archiviazione e la gestione inadeguata delle informazioni personali possono portare a violazioni della normativa privacy (es. GDPR) e a conseguenze legali.

  1. Attacchi alla reputazione: Minacce che mirano a danneggiare la reputazione dell’organizzazione, come la diffusione di informazioni false o la pubblicazione di dati compromettenti.

Queste categorie di minacce devono essere considerate durante il processo di identificazione e analisi dei rischi, in modo che l’organizzazione possa sviluppare strategie adeguate per mitigare i rischi associati,.

Quali sono le più comuni vulnerabilità?

Secondo la norma ISO/IEC 27005:2022, le vulnerabilità sono debolezze nei sistemi, processi o controlli che possono essere sfruttati da minacce per compromettere la sicurezza delle informazioni. Ecco alcune delle vulnerabilità più comuni che le organizzazioni dovrebbero considerare:

Vulnerabilità Hardware

  1. Insufficiente manutenzione/fallimenti nell’installazione: Problemi legati alla manutenzione inadeguata o all’installazione errata di dispositivi hardware.
  2. Sensibilità a condizioni ambientali: Vulnerabilità legate a umidità, polvere o variazioni di temperatura che possono danneggiare l’hardware.
  3. Mancanza di controllo delle modifiche di configurazione: Assenza di procedure per gestire le modifiche alle configurazioni hardware.

Vulnerabilità Software

  1. Vizi e difetti noti nel software: Utilizzo di software con vulnerabilità già identificate e documentate.
  2. Insufficiente testing del software: Mancanza di test adeguati a identificare e correggere i difetti prima del rilascio.
  3. Gestione inadeguata delle password: Pratiche deboli nella gestione delle password, come l’uso di password deboli o la mancanza di meccanismi di autenticazione robusti.

Vulnerabilità di Rete

  1. Linee di comunicazione non protette: Trasmissione di dati sensibili su reti non sicure.
  2. Architettura di rete insicura: Progettazione della rete che non considera adeguatamente la sicurezza, creando punti deboli.
  3. Punti unici di guasto: Componenti critici della rete che, se compromessi, possono causare l’interruzione del servizio.

Vulnerabilità Organizzative

  1. Mancanza di politiche di sicurezza: Assenza di politiche chiare e documentate per la gestione della sicurezza delle informazioni.
  2. Formazione inadeguata del personale: Dipendenti non adeguatamente formati sui rischi di sicurezza e sulle pratiche di protezione delle informazioni.
  3. Procedure di reporting inefficaci: Mancanza di procedure per segnalare e gestire le vulnerabilità e le violazioni della sicurezza.

Vulnerabilità Fisiche

  1. Accesso non controllato alle strutture: Mancanza di controlli fisici per limitare l’accesso a aree sensibili.
  2. Mancanza di politiche di “clear desk” e “clear screen: Assenza di politiche per garantire che le informazioni sensibili non siano visibili o accessibili quando non sono in uso.

Queste vulnerabilità possono essere sfruttate da minacce per compromettere la sicurezza delle informazioni e devono essere identificate e gestite attraverso un processo di valutazione dei rischi.

Come si può calcolare l’indice di rischio per la sicurezza delle informazioni secondo questa norma?

Secondo la norma ISO/IEC 27005:2022, il calcolo dell’indice di rischio per la sicurezza delle informazioni si basa su un processo di valutazione dei rischi che considera diversi fattori, tra cui la probabilità di un evento di rischio e le conseguenze ad esso associate. Ecco i passaggi generali per calcolare l’indice di rischio:

1. Identificazione dei Rischi

1. Identificare i rischi potenziali associati alle minacce e alle vulnerabilità presenti nell’organizzazione. Ciò può includere eventi come attacchi informatici, errori umani, guasti tecnologici, ecc.

2. Valutazione della Probabilità (Verosimiglianza)

Determinare la probabilità che ciascun rischio si verifichi. Questo può essere fatto utilizzando scale qualitative (bassa, media, alta) o quantitative (percentuali o frequenze).

3. Valutazione delle Conseguenze (Gravità dell’impatto)

Valutare le conseguenze di ciascun rischio in caso di realizzazione. Le conseguenze possono essere classificate in termini di impatto su:

  • Riservatezza
  • Integrità
  • Disponibilità

Anche in questo caso, si possono utilizzare scale qualitative o quantitative.

4. Calcolo dell’Indice di Rischio

L’indice di rischio può essere calcolato utilizzando una formula che combina la probabilità e le conseguenze. Una formula comune è:

{Indice di Rischio} = {Probabilità} x {Impatto}

Questo indice fornisce una misura del rischio associato a ciascun evento identificato.

5. Classificazione dei Rischi

I rischi possono essere classificati in base all’indice di rischio calcolato, consentendo di prioritizzare le azioni di mitigazione. Ad esempio, i rischi con un indice di rischio elevato dovrebbero essere trattati con maggiore urgenza rispetto a quelli con un indice più basso.

6. Definizione di Strategie di Mitigazione

Sulla base della classificazione dei rischi, l’organizzazione può sviluppare strategie di mitigazione per ridurre la probabilità o l’impatto dei rischi identificati.

7. Monitoraggio e Riesame

È importante monitorare continuamente i rischi e riesaminare l’indice di rischio, poiché le minacce, le vulnerabilità e il contesto dell’organizzazione possono cambiare nel tempo.

Questi passaggi forniscono un approccio sistematico per calcolare e gestire i rischi per la sicurezza delle informazioni, come delineato nella norma ISO/IEC 27005: 2022. Il medesimo approccio può essere utilizzato per effettuare un Risk Assessment per la Direttiva NIS 2, vista l’analogia delle tematiche, garantendo così la riferibilità ad una metodologia di uno standard internazionale ISO.

La norma fornisce qualche esempio di matrice dei rischi?

La norma ISO/IEC 27005:2022 fornisce esempi di matrici dei rischio, che possono essere utilizzate per rappresentare graficamente la valutazione dei rischi in base a probabilità e conseguenze/impatti. Queste matrici aiutano le organizzazioni a visualizzare e classificare i rischi in modo chiaro e comprensibile.

Esempi di Matrice dei Rischi

1. Matrice Qualitativa:

 Una matrice qualitativa può utilizzare scale di classificazione come “Molto Alta”, “Alta”, “Media”, “Bassa” per la probabilità e le conseguenze. Ad esempio, una matrice potrebbe apparire come segue:

Probabilità Conseguenze Molto Alta Alta Media Bassa
Catastrofico    Molto Alta Alta Alta Media
Critico                   Molto Alta Alta Media Bassa
Significativo             Alta Media Bassa Bassa
Minore                    Media Bassa Bassa Molto Bassa

2. Matrice Quantitativa:

Una matrice quantitativa può utilizzare valori numerici per rappresentare la probabilità e l’impatto. Ad esempio, si potrebbe utilizzare una scala da 1 a 5 per entrambe le dimensioni, dove 1 rappresenta il rischio più basso e 5 il rischio più alto. La matrice potrebbe apparire come segue:

Probabilità Conseguenze 1 (Bassa) 2 (Media) 3 (Alta) 4 (Molto Alta) 5 (Critica) |
1 (Minore)                1 2 3 4 5
2 (Significativo)         2 4 6 8 10
3 (Critico)               3 6 9 12 15
4 (Catastrofico)        4 8 12 16 20

Utilizzo della Matrice dei Rischio

Le matrici dei rischio possono essere utilizzate per:

  • Visualizzare la distribuzione dei rischi: Aiutano a identificare quali rischi richiedono attenzione immediata.
    • Supportare le decisioni: Forniscono un quadro chiaro per le decisioni relative alla gestione dei rischi.

    • Comunicare i rischi: Facilitano la comunicazione dei rischi a tutte le parti interessate.

È importante che le scale utilizzate nella matrice siano ben definite e comprese da tutte le parti interessate. Le descrizioni qualitative devono essere chiare e non ambigue, e le categorie non devono sovrapporsi.

Quali sono i livelli di probabilità e gravità/impatto ed i criteri per la loro determinazione secondo questa norma?

scrabble letters spelling risk on a wooden table
Photo by Markus Winkler on Pexels.com

Nella norma ISO/IEC 27005:2022, i livelli di probabilità e gravità/impatto abbiamo visto che sono definiti attraverso scale qualitative e quantitative e i criteri per la loro determinazione devono essere stabiliti per garantire una valutazione coerente e significativa dei rischi.

Livelli di Probabilità

I livelli di probabilità possono essere espressi in termini qualitativi o quantitativi. Ecco un esempio di scala qualitativa:

Probabilità:

  • Quasi certa: Evento che si prevede si verifichi frequentemente.
  • Molto probabile: Evento che si prevede si verifichi frequentemente, ma non sempre.
  • Probabile: Evento che ha una buona possibilità di verificarsi.
  • Poco probabile: Evento che ha una bassa possibilità di verificarsi.
  • Improbabile: Evento che è poco probabile che si verifichi.

Livelli di Gravità/Impatto

I livelli di gravità o impatto delle conseguenze possono essere definiti come segue:

Gravità delle Conseguenze:

  • Catastrofico: Conseguenze gravi che possono compromettere gravemente l’organizzazione.
  • Critico: Conseguenze significative che possono influenzare gravemente le operazioni/i processi di business.
  • Serio: Conseguenze che possono causare danni notevoli, ma non critici.
  • Significativo: Conseguenze che possono causare disagi minori.
  • Minore: Conseguenze trascurabili che non influenzano le operazioni.

Criteri per la Determinazione dei Livelli

I criteri per determinare i livelli di probabilità e gravità includono:

  • Analisi Storica: Considerare eventi passati e incidenti di sicurezza che si sono verificati all’interno e all’esterno dell’organizzazione.
  • Valutazione delle Vulnerabilità: Identificare le vulnerabilità esistenti e il loro potenziale impatto.
  • Scenari di Rischio: Creare scenari di rischio che combinano probabilità e conseguenze per valutare il livello di rischio complessivo.
  • Contesto Organizzativo: Considerare il contesto specifico dell’organizzazione, inclusi i suoi obiettivi, le risorse e l’ambiente operativo.
  • Consenso delle Parti Interessate: Assicurarsi che le definizioni e le scale siano comprese e accettate da tutte le parti interessate coinvolte nel processo di gestione del rischio.

  1. Analisi Storica: Considerare eventi passati e incidenti di sicurezza che si sono verificati all’interno e all’esterno dell’organizzazione.
  2. Valutazione delle Vulnerabilità: Identificare le vulnerabilità esistenti e il loro potenziale impatto.
  3. Scenari di Rischio: Creare scenari di rischio che combinano probabilità e conseguenze per valutare il livello di rischio complessivo.
  4. Contesto Organizzativo: Considerare il contesto specifico dell’organizzazione, inclusi i suoi obiettivi, le risorse e l’ambiente operativo.
  5. Consenso delle Parti Interessate: Assicurarsi che le definizioni e le scale siano comprese e accettate da tutte le parti interessate coinvolte nel processo di gestione del rischio.

Esempi pratici

Nell’Appendice A la norma ISO 27005 fornisce esempi di tecniche a supporto del processo di valutazione dei rischi.

La norma presenta tabelle che possono essere utilizzate per rappresentare visivamente i livelli di probabilità e gravità, come ad esempio:

  • Tabella A.3: Esempio di approccio qualitativo ai criteri di rischio, che combina probabilità e conseguenze per determinare il livello di rischio.
  • Tabella A.2 e A.4: Esempi di scale di probabilità che possono essere utilizzate per rappresentare la probabilità di eventi di rischio in termini probabilistici o frequenziali.

Questi livelli e criteri sono fondamentali per aiutare le organizzazioni a prendere decisioni informate sulla gestione dei rischi e a stabilire priorità per le azioni di mitigazione.

Inoltre, sono illustrate Tecniche pratiche per identificare valutare i componenti di rischio per la sicurezza delle informazioni quali:

  • Componenti legati al passato: eventi e incidenti di sicurezza (sia all’interno dell’organizzazione che all’esterno), fonti di rischio, vulnerabilità sfruttate, conseguenze misurate.
  • Componenti legati al futuro: minacce; vulnerabilità; conseguenze; scenari di rischio.



La Direttiva NIS 2 e il Decreto di recepimento in Italia: un nuovo capitolo per la Sicurezza delle Reti e dei Sistemi Informativi

Il panorama della sicurezza informatica in Europa sta vivendo una fase di trasformazione importante, con l’introduzione della Direttiva NIS 2 (Direttiva (UE) 2022/2555 del Parlamento Europeo e del Consiglio), che aggiorna la precedente Direttiva NIS (Network and Information Security) del 2016. A supporto di tale aggiornamento, l’Italia ha recepito (tra i primi Paesi UE) la direttiva europea attraverso il Decreto Legislativo 138/2024, approvato il 4 settembre 2024, che stabilisce nuovi obblighi per le organizzazioni italiane in materia di cybersecurity e gestione dei rischi.I

n questo articolo, esploreremo i principali punti della Direttiva NIS 2 e del Decreto di recepimento, analizzando le novità, gli impatti per le aziende e gli enti pubblici, e le sfide future in un contesto sempre più digitalizzato e vulnerabile a minacce cibernetiche.

La Direttiva NIS 2: obiettivi e novità

La Direttiva NIS 2 è parte di un più ampio sforzo dell’Unione Europea per rafforzare la sicurezza informatica e contrastare i rischi legati alle infrastrutture digitali, che sono diventate essenziali per il funzionamento delle economie moderne. Tra gli obiettivi principali della NIS 2 ci sono:

  1. Aumentare il livello di protezione delle infrastrutture critiche: La Direttiva mira a garantire che tutte le organizzazioni che gestiscono infrastrutture critiche (settori come energia, trasporti, sanità, acqua, comunicazioni elettroniche) siano più preparate ad affrontare attacchi cibernetici e a limitare l’impatto di eventuali incidenti di sicurezza.
  2. Estensione della portata delle norme: La Direttiva NIS 2 amplia il campo di applicazione rispetto alla versione precedente. Non solo le entità pubbliche e le aziende più grandi sono coinvolte, ma anche i fornitori di servizi essenziali e altre organizzazioni considerate ad alto rischio (ad esempio, piattaforme di e-commerce, fornitori di servizi cloud e aziende tecnologiche).
  3. Miglioramento della cooperazione tra Stati membri: Una parte cruciale della NIS 2 è la creazione di un meccanismo di cooperazione più robusto tra gli Stati membri dell’UE. Questo implica la condivisione di informazioni sulle minacce, la gestione degli incidenti e lo sviluppo di linee guida comuni in materia di sicurezza informatica.
  4. Obbligo di gestione dei rischi e notifica degli incidenti: Le aziende devono implementare misure di sicurezza adeguate e notificare tempestivamente le violazioni della sicurezza alle autorità competenti. Inoltre, devono adottare politiche di gestione dei rischi informatici per prevenire attacchi.

  1. Sanzioni più severe: La Direttiva prevede l’introduzione di pene pecuniarie in caso di mancato adempimento degli obblighi di sicurezza, con multe che possono arrivare fino al 2% del fatturato annuale globale delle aziende coinvolte.

Il Decreto Legislativo 138/2024: Il recepimento della NIS 2 in Italia

Con la pubblicazione del Decreto Legislativo 138/2024 il 4 settembre 2024, l’Italia ha recepito la Direttiva NIS 2 nell’ordinamento nazionale, introducendo modifiche significative al quadro giuridico e regolatorio per la sicurezza delle reti e dei sistemi informativi. Alcuni degli aspetti più rilevanti includono:

  1. Ampliamento del concetto di “Entità Essenziali“: In linea con le disposizioni della NIS 2, il Decreto Italiano amplia il novero delle entità soggette agli obblighi di sicurezza. Non solo i settori tradizionali (energia, trasporti, sanità) ma anche nuovi settori come i fornitori di servizi digitali, le piattaforme di e-commerce, i servizi cloud e le infrastrutture critiche IT rientrano nella normativa.
  2. Notifica tempestiva degli incidenti di sicurezza: Le aziende e gli enti pubblici devono comunicare eventuali incidenti di sicurezza che possano avere un impatto significativo sui servizi essenziali entro 24 ore dall’accaduto. Ciò include attacchi informatici, vulnerabilità critiche e qualsiasi altro evento che minacci l’integrità dei sistemi.
  3. Politiche di Gestione dei Rischi: L’adozione di un piano di gestione dei rischi diventa obbligatoria. Il piano deve contenere misure preventive per ridurre al minimo la probabilità di attacchi, nonché strategie di risposta e recupero in caso di incidenti di sicurezza.
  4. Sanzioni e controllo: Il Decreto stabilisce un quadro sanzionatorio chiaro per le violazioni, che può arrivare a multe significative e altre misure correttive, in linea con le disposizioni europee. L’Autorità per la Cybersicurezza, che coordina gli sforzi nazionali, è anche incaricata di monitorare e fare rispettare la normativa.

Implicazioni per le Aziende e gli Enti Pubblici in Italia

L’entrata in vigore della Direttiva NIS 2 e del D.Lgs 138/2024 comporta un cambiamento significativo per molte realtà aziendali e pubbliche. Le organizzazioni devono ora adottare una strategia di cybersecurity che non si limiti a proteggere i dati sensibili, ma che abbracci una visione complessiva della sicurezza, con misure preventive, piani di risposta agli incidenti e una costante attività di monitoraggio.

Le PMI, che fino ad oggi erano meno coinvolte nella normativa, ora potrebbero essere chiamate a rispettare nuovi obblighi, soprattutto se operano in settori considerati “essenziali” o ad alto rischio. Questo significa che anche le piccole e medie imprese devono investire in soluzioni di cybersecurity avanzate, implementare formazione adeguata per i propri dipendenti e rivedere periodicamente la sicurezza dei propri sistemi.

Inoltre, la cooperazione tra enti pubblici e privati diventa fondamentale per affrontare le minacce informatiche globali. La creazione di canali di comunicazione per la condivisione delle informazioni sulle vulnerabilità e sugli attacchi è un aspetto cruciale che contribuirà a migliorare la resilienza dell’intero sistema digitale europeo.

I settori coinvolti

La Direttiva (UE) 2022/2555 interessa diversi settori chiave, che sono considerati essenziali per il funzionamento della società e dell’economia. Il D.Lgs 138/2024 riporta algli Allegati I e 2, rispettivamente, “i settori ad alta criticità” ed “altri settori critici”.

Tra i settori principali coperti dalle misure di cibersicurezza previste nella direttiva, troviamo:

1. Energia: Include le infrastrutture e i servizi legati alla produzione, distribuzione e fornitura di energia, come elettricità, gas e petrolio.

2. Trasporti: Comprende i servizi di trasporto aereo, marittimo e terrestre, nonché le infrastrutture associate.

3. Sanità: Riguarda le strutture sanitarie, i fornitori di servizi sanitari e le tecnologie dell’informazione utilizzate nel settore sanitario.

4. Acqua: Include la fornitura e la gestione delle risorse idriche, comprese le infrastrutture per la potabilizzazione e la distribuzione dell’acqua.

5. Infrastrutture digitali: Comprende i fornitori di servizi di comunicazione elettronica e i servizi di hosting, nonché le piattaforme digitali.

6. Settore finanziario: Riguarda le istituzioni finanziarie, come banche e compagnie assicurative, che gestiscono dati sensibili e transazioni economiche.

7. Servizi essenziali: Include anche altri servizi che sono fondamentali per il funzionamento della società, come i servizi di emergenza e le infrastrutture critiche.

La direttiva mira a garantire che questi settori adottino misure adeguate per proteggere le loro infrastrutture e servizi da minacce informatiche, contribuendo così a una maggiore resilienza cibernetica in tutta l’Unione Europea.

Il coinvolgimento di numerose aziende in questi settori critici porterà, a cascata, anche il coinvolgimento della catena di fornitura, con richieste contrattuali severe sulla sicurezza informatica.

Le misure di sicurezza richieste

La Direttiva (UE) 2022/2555 impone diverse misure di sicurezza alle aziende coinvolte, al fine di garantire un elevato livello di cibersicurezza. Le principali misure di sicurezza includono:

  1. Politiche di analisi dei rischi: Le aziende devono sviluppare e mantenere politiche per identificare e valutare i rischi associati alla sicurezza informatica.
  2. Strategie per la gestione degli incidenti: È necessario avere piani e procedure in atto per gestire e rispondere agli incidenti di sicurezza informatica. Le aziende sono anche obbligate a notificare alle autorità competenti qualsiasi incidente significativo di sicurezza informatica che possa avere un impatto sui servizi essenziali o sui dati sensibili. La notifica deve avvenire entro un termine specificato dalla direttiva.
  3. Piani di continuità operativa: Le aziende devono prepararsi a garantire la continuità dei servizi anche in caso di incidenti di sicurezza.
  4. Sicurezza della catena di approvvigionamento: Le misure devono estendersi anche ai fornitori e ai partner, assicurando che la sicurezza sia mantenuta lungo tutta la catena di approvvigionamento.
  5. Gestione della Sicurezza del Software: Le aziende dovranno adottare procedure per garantire la sicurezza dell’acquisizione, dello sviluppo e della manutenzione dei sistemi informatici e di rete, compresa la gestione e la divulgazione delle vulnerabilità ed i relativi aggiornamenti.
  6. Pratiche di igiene informatica: È fondamentale adottare buone pratiche di igiene informatica per prevenire attacchi e vulnerabilità.
  7. Misure tecniche, operative e organizzative: Le misure devono essere adeguate e proporzionate ai rischi identificati, mirando a proteggere i sistemi informatici e di rete da attacchi e a minimizzare l’impatto degli incidenti. Queste misure possono includere la crittografia, il controllo degli accessi, la protezione dei dati e la formazione del personale.
  8. Valutazione della conformità: Le aziende devono essere pronte a sottoporsi a valutazione della conformità per valutare l’efficacia delle misure di sicurezza intraprese e garantire che rispettino gli obblighi di sicurezza stabiliti dalla direttiva. Ciò può includere audit e controlli da parte di fornitori specializzati (es. Penetration Test e Vulnerability Assessment) delle autorità competenti.

Queste misure sono progettate per garantire che le aziende adottino un approccio proattivo alla sicurezza informatica, contribuendo così a una maggiore resilienza e protezione contro le minacce cibernetiche.

Le misure di sicurezza sono simili ai controlli previsti dalla nota ISO 27001 per i sistemi di gestione della sicurezza delle informazioni, ma quali sono le differenze? Chi è già certificato ISO 27001 o sta per farlo è già conforme alla NIS 2? Occorre fare alcune precisazioni.

Da un lato i controlli ISO 27001 (e linea guida ISO 27002) coprono uno spettro più ampio della sicurezza delle informazioni, dall’altro alcune misure di sicurezza richieste dalla NIS 2 sono più specifiche (es. gestione e notifica degli incidenti).

La NIS 2 è più orientata alla Cybersecurity ed alla protezione delle informazioni sensibili per il funzionamento delle infrastrutture critiche, mentre il campo di applicazione di un SGSI ISO 27001 può spaziare in diversi ambiti e, pertanto, potrebbe avere un perimetro più esteso di quello della NIS 2. Attenzione però che data breach di attività e servizi fuori dal perimetro della NIS 2 non possano coinvolgere attività e servizi critici entro il perimetro NIS 2.

La procedura di registrazione al portale ACN

La registrazione al portale ACN èobbligatoria entro il 28 febbraio 2025, in mancanza l’azienda, se rientra tra i soggetti nell’ambito della Direttiva, è soggetta a sanzione.

Informazioni necessarie per la registrazione

La registrazione si compone di tre fasi: il censimento del punto di contatto, la sua associazione al soggetto NIS e la compilazione della dichiarazione.

  1. Per la fase di censimento del punto di contatto, sarà necessario verificare o fornire i seguenti dati:

    1. nome e cognome;
    2. luogo e data di nascita;
    3. codice fiscale;
    4. cittadinanza;
    5. Paese di residenza e, ove richiesto, di domicilio;
    6. indirizzo di posta elettronica ordinaria, preferibilmente individuale, nonché di servizio, aziendale o professionale;
    7. ove disponibile, un indirizzo di posta elettronica certificata, preferibilmente individuale, nonché di servizio, aziendale o professionale;
    8. numero di telefono, preferibilmente individuale, nonché di servizio, aziendale o professionale;
    9. ove disponibile, un numero alternativo di telefono, preferibilmente individuale di servizio, aziendale o professionale.

  2. Per la fase di associazione del punto di contatto al soggetto NIS, sarà necessario disporre del codice fiscale di quest’ultimo. Inoltre, qualora il Punto di contatto non sia il rappresentante legale del soggetto o un suo procuratore generale censito sul registro delle imprese, sarà necessario caricare il titolo giuridico che lo delega a operare per conto del soggetto.
  3. Per la fase di compilazione della dichiarazione, sarà necessario disporre:

    1. dell’elenco dei codici ATECO che caratterizzano le attività svolte e i servizi erogati dal soggetto, con particolare riferimento all’ambito di applicazione del decreto NIS;
    2. delle normative europee settoriali citate dal decreto NIS per delimitarne l’ambito di applicazione che si applicano al soggetto;
    3. del numero di dipendenti, il fatturato e il bilancio del soggetto. Qualora il soggetto non sia una impresa autonoma, il numero di dipendenti, il fatturato e il bilancio del soggetto calcolato ai sensi della raccomandazione 2003/361/CE, con particolare riguardo all’articolo 6, paragrafo 2, dell’allegato alla raccomandazione medesima;
    4. l’elenco delle tipologie di soggetto di cui agli allegati I, II, III e IV, a cui è riconducibile il soggetto (ovvero soggetto appartenente a settori ad alta criticità, altri settori critici, P.A.,…) ;
    5. l’autovalutazione del soggetto quale essenziale, importante o fuori ambito, sulla base di quanto previsto dagli articoli 3 e 6 del decreto NIS.

Per i soggetti che non sono imprese autonome (ovvero hanno imprese collegate, associate e/o fanno parte di un gruppo di imprese), in fase di registrazione sarà inoltre necessario fornire le informazioni indicate nel seguito.

Per i Gruppi di imprese che si devono registrare

Con riferimento alla designazione del punto di contatto, al fine di non imporre radicali cambiamenti nel governo della sicurezza informatica, i soggetti che fanno parte di un gruppo di imprese ai sensi dell’articolo 1, comma 1, lettera u), della Determinazione 38565/2024, possono designare quale punto di contatto il dipendente di un’altra impresa che rientra nell’ambito di applicazione del decreto NIS e che fa parte del medesimo gruppo di imprese.

Pertanto, ad esempio:

  1. nei gruppi di imprese nei quali il governo della sicurezza informatica è decentralizzato, i soggetti che fanno parte del gruppo possono designare ognuno un proprio dipendente quale punto di contatto;
  2. nei gruppi di imprese nei quali il governo della sicurezza informatica è centralizzata, i soggetti che fanno parte del gruppo possono tutti designare quale punto di contatto un dipendente della struttura del gruppo che governa la sicurezza informatica, oppure designare ognuno un proprio dipendente quale punto di contatto che si coordinerà con la struttura del gruppo che governa la sicurezza informatica.

Qualora la stessa persona fisica sia designata quale punto di contatto per tutti o una parte dei soggetti NIS del gruppo di imprese, occorrerà ripetere la fase di associazione e registrazione per ogni soggetto NIS.

Inoltre, con riferimento alla registrazione di soggetti che non sono imprese autonome ai sensi dell’articolo 1, comma 1, lettera t) della Determinazione 38565/2024, sarà necessario fornire le seguenti ulteriori informazioni rispetto a quanto illustrato in precedenza:

  1. il codice fiscale e la ragione sociale della capogruppo, qualora il soggetto appartenga a un gruppo e non sia la capogruppo;
  2. il codice fiscale e la ragione sociale di tutte le imprese collegate, ai sensi della Determinazione 38565/2024, articolo 1, comma 1, lettera s), che soddisfano almeno uno dei criteri di cui all’articolo 3, comma 10, del decreto legislativo 138/2024 (decreto NIS) nei confronti del soggetto medesimo;
  3. il codice fiscale e la ragione sociale di tutte le imprese collegate che, per quanto noto, siano a loro volta soggetti NIS, ai sensi della Determinazione 38565/2024, articolo 1, comma 1, lettera s), nei confronti dei quali il soggetto medesimo soddisfa almeno uno dei criteri di cui all’articolo 3, comma 10, del decreto legislativo 138/2024 (decreto NIS);
  4. il numero di dipendenti, il fatturato e il bilancio del soggetto calcolato ai sensi della raccomandazione 2003/361/CE, con particolare riguardo all’articolo 6, paragrafo 2, dell’allegato alla raccomandazione medesima.

Infine, con riferimento a quest’ultimo punto, qualora tale soggetto ritenga sproporzionata l’applicazione dell’articolo 6, paragrafo 2, dell’allegato alla raccomandazione 2003/361/CE, sarà necessario fornire anche:

  1. il numero di dipendenti, il fatturato e il bilancio del soggetto calcolato ai sensi della raccomandazione 2003/361/CE, senza tenere conto di quanto previsto dall’articolo 6, paragrafo 2, dell’allegato alla raccomandazione medesima;
  2. la valutazione del grado di indipendenza (totale parziale o assente) dei sistemi informativi e di rete NIS dell’organizzazione dai sistemi informativi e di rete delle imprese collegate. Con attività e servizi NIS si intendono le attività e i servizi per i quali l’organizzazione rientra nell’ambito di applicazione del decreto NIS. Con sistemi informativi e di rete NIS, si intendono i sistemi informativi e di rete che abilitano attività e servizi NIS;
  3. la valutazione del grado di indipendenza (totale parziale o assente) delle attività e dei servizi NIS dell’organizzazione NIS dalle attività e dai servizi delle imprese collegate;
  4. la risposta (si, in parte, no) alle domande seguenti:

    1. I sistemi informativi e di rete delle imprese collegate concorrono ai sistemi informativi e di rete NIS dell’organizzazione?
    2. Le attività e i servizi di imprese collegate concorrono alle attività e servizi NIS dell’organizzazione?
    3. Le imprese collegate sono essenziali nella catena di approvvigionamento, anche digitale, dell’organizzazione?

Criteri per designare il punto di contatto

Il Punto di contatto è il rappresentante legale o un suo procuratore generale oppure un dipendente delegato del soggetto.

In quest’ultimo caso, nel corso della registrazione, il punto di contatto dovrà caricare il titolo giuridico che lo delega a operare per conto del soggetto nel contesto NIS. Come titolo giuridico è sufficiente una delega del rappresentante legale che può essere ad-hoc (modello suggerito) o anche una delega pre-esistente più ampia.

Per le pubbliche amministrazioni è possibile designare quale punto di contatto il dipendente di un’altra pubblica amministrazione che rientra nell’ambito di applicazione del decreto NIS.

Analogamente, i soggetti che fanno parte di un gruppo di imprese possono designare quale punto di contatto il dipendente di un’altra impresa che rientra nell’ambito di applicazione del decreto NIS e che fa parte del medesimo gruppo di imprese.

Il punto di contatto ha il compito di curare l’attuazione delle disposizioni del decreto NIS per conto del soggetto stesso, a partire dalla registrazione, e interloquisce, per conto del soggetto NIS, con l’Autorità nazionale competente NIS.

Conclusioni

La Direttiva NIS 2 e il Decreto Legislativo 138/2024 rappresentano un passo importante nella protezione delle infrastrutture digitali e nella lotta contro il crimine informatico. Con l’adozione di misure più rigorose e la creazione di un sistema di cooperazione tra Stati membri, l’UE sta cercando di creare un ambiente digitale più sicuro e resistente.

Per diverse aziende l’interpretazione dell’ambito di applicazione, ovvero se sono obbligate o meno all’applicazione della NIS 2, non è semplice; si auspica chiarimenti da parte di ACN, molto attiva sull’argomento (si veda https://www.acn.gov.it/portale/faq/cloud).

Per le aziende italiane, la sfida non è solo adeguarsi alle nuove normative, ma farlo in modo proattivo, rafforzando la sicurezza informatica e costruendo una cultura della protezione che diventi parte integrante delle loro operazioni quotidiane.

Investire in cybersecurity non è più un’opzione: è una necessità imprescindibile per proteggere i dati, la privacy e la reputazione di ciascuna organizzazione. Con il Decreto 138/2024, l’Italia compie un passo decisivo verso una maggiore protezione delle sue reti e sistemi informativi, rafforzando la fiducia nel sistema digitale europeo.




L’intelligenza artificiale, fra etica, privacy e applicazioni per le imprese

Sicuramente l’Intelligenza Artificiale è uno (se non il primo) degli argomenti più in vogha e dibattuti di questi ultimi mesi.

blue bright lights
Photo by Pixabay on Pexels.com

Dall’uscita di ChatGPT, seguita da Microsoft Copilot e Google Bard, in poi si è dibattuto su diversi aspetti dell’IA: aspetti etici, di privacy, perdita di posti di lavoro, strumento utile per le imprese e così via.

Proprio per questo la Commissione Europea è voluta intervenire in gran fretta emanando il c.d. “AI Act” di cui si parla molto in questi giorni.

L’AI non è una novità degli ultimi anni, ma il passaggio epocale si è avuto con il passaggio all’AI generativa che si differenzia da altre applicazioni di AI. Ma cos’è l’IA generativa?

L’intelligenza artificiale generativa (AI generativa) è una categoria di intelligenza artificiale (IA) che si concentra sulla creazione di dati o contenuti, come immagini, musica, testo, o altri tipi di informazioni, invece che sull’analisi o sull’interpretazione di dati esistenti.

Ci sono diverse modalità attraverso le quali l’IA generativa può operare:

  1. Reti neurali generative (GANs): Le reti neurali generative sono uno dei metodi più diffusi per l’IA generativa. Le GANs sono composte da due reti neurali: il generatore e il discriminatore. Il generatore crea nuovi dati, mentre il discriminatore cerca di distinguere i dati generati da quelli reali. Le due reti vengono addestrate insieme in modo che il generatore possa migliorare continuamente nella creazione di dati realistici.
  2. Reti neurali ricorrenti (RNNs) e reti neurali trasformative (TNNs): Questi tipi di reti sono utilizzate per generare sequenze di dati, come testo o musica. Le RNNs sono particolarmente efficaci nel generare dati sequenziali poiché possono tenere conto del contesto temporale. Le TNNs, d’altra parte, utilizzano trasformatori per elaborare sequenze di dati in parallelo, rendendo il processo più efficiente.
  3. Altri approcci: Ci sono anche altri approcci all’IA generativa che utilizzano tecniche diverse, come le reti neurali Bayesiane o i modelli di Markov nascosti.

Le principali differenze tra l’IA generativa e altre tipologie di intelligenza artificiale, come l’IA basata su regole o l’IA di apprendimento supervisionato, risiedono nel loro scopo e nella modalità di funzionamento:

  1. Scopo: L’IA generativa si concentra sulla creazione di nuovi dati o contenuti, mentre altre forme di IA possono essere utilizzate per compiti come la classificazione, la previsione o l’ottimizzazione.
  2. Modalità di funzionamento: Mentre altre forme di IA spesso lavorano con dati esistenti per estrarre informazioni o fare previsioni, l’IA generativa crea nuovi dati dall’interno del sistema, spesso senza dipendere direttamente dai dati di addestramento.

In sintesi, l’IA generativa è un ramo dell’intelligenza artificiale che si occupa della creazione di nuovi dati o contenuti, utilizzando una varietà di tecniche e approcci, come le reti neurali generative o le reti neurali ricorrenti. Le sue principali differenze risiedono nel suo scopo e nella modalità di funzionamento rispetto ad altre forme di IA.

Ma quali sono le applicazioni dell’intelligenza artificiale che possono essere utili per le imprese?

Le applicazioni dell’intelligenza artificiale (IA) per le imprese sono molteplici e sempre più diffuse in diversi settori. Alcuni esempi includono:

  1. Automatizzazione dei processi: L’IA può automatizzare una vasta gamma di processi aziendali, riducendo il carico di lavoro manuale e migliorando l’efficienza. Questo può includere l’automatizzazione dei processi di produzione, gestione delle scorte, fatturazione, supporto clienti e molto altro.
  2. Analisi dei dati: L’IA può analizzare grandi quantità di dati aziendali per estrarre insight significativi e informazioni utili per prendere decisioni informate. Questo può includere l’analisi predittiva per prevedere tendenze di mercato, la segmentazione dei clienti per personalizzare le offerte, l’individuazione di anomalie per la sicurezza informatica e molto altro.
  3. Servizi clienti intelligenti: L’IA può essere utilizzata per migliorare l’esperienza del cliente attraverso chatbot intelligenti che forniscono supporto immediato e personalizzato, sistemi di raccomandazione per suggerire prodotti o servizi pertinenti e analisi dei sentimenti per comprendere meglio le esigenze e le opinioni dei clienti.
  4. Manutenzione predittiva: L’IA può essere impiegata per prevedere guasti o problemi di manutenzione in anticipo, consentendo alle imprese di effettuare interventi preventivi e ridurre i costi di manutenzione e i tempi di inattività.
  5. Ottimizzazione delle risorse: L’IA può ottimizzare l’utilizzo delle risorse aziendali, come la gestione delle flotte di veicoli, l’allocazione delle risorse umane e la pianificazione della produzione, per massimizzare l’efficienza e ridurre i costi operativi.
  6. Personalizzazione dei servizi: L’IA può aiutare le imprese a offrire servizi altamente personalizzati ai propri clienti, utilizzando algoritmi di apprendimento automatico per adattare le offerte in base alle preferenze individuali e al comportamento passato dei clienti.
  7. Sicurezza informatica: L’IA può migliorare la sicurezza informatica attraverso sistemi di rilevamento delle minacce basati sull’apprendimento automatico che identificano e rispondono in tempo reale alle potenziali minacce alla sicurezza dei dati aziendali.
  8. Produzione di contenuti: Produzione di contenuti: L’IA può generare contenuti scritti, come post per siti web o pubblicità personalizzate.
  9. Ottimizzazione delle operazioni di inventario: L’IA aiuta a gestire gli stock in modo efficiente

Questi sono solo alcuni esempi delle molte applicazioni dell’IA per le imprese. In generale, l’IA può essere utilizzata per migliorare l’efficienza operativa, ottimizzare le decisioni aziendali, migliorare l’esperienza del cliente e creare nuove opportunità di business.

Dai di addestramento dell’AI

Questo, però, solo in teoria, perché l’IA deve essere addestrata con informazioni reali e, come avviene per altri processi di elaborazione computerizzata di dati, il risultato di un algoritmo deterministico produce dati che dipendono dall’input e si può ricordare il principio “garbage ingarbage out”. Ovvero se i dati in input sono una schifezza, i dati in output lo saranno altrettanto!

Ho sentito parlare di grandi opportunità per le imprese di utilizzare i dati in loro possesso attraverso l’intelligenza artificiale, ma molte imprese, soprattutto le medio-piccole, non hanno dati validi da analizzare. Questo perché anche molti progetti della c.d. Industria 4.0 sono stati unicamente finalizzati ad acquistare macchinari ed apparecchiature varie con sgravi fiscali, ma l’interconnessione e la raccolta dati è stata solo virtuale, ovvero non si sono impiegati software per la raccolta e la gestione dei dati provenienti dalle macchine. Dunque, molte aziende hanno acquistato macchinari moderni, in grado di acquisire deti sulla produzione, sui fermi macchina, sulla qualità dei prodotti e molto altro, ma non hanno investito nell’integrazione con sistemi MES, schedulatori, sistemi di Business Intelligence in grado di sfruttare i dati che le macchine potevano acquisire.

In queste situazioni l’IA non serve a nulla, bisogna fare un passo indietro e ricominciare daccapo con la raccolta dati.

La qualità dei risultati ottenuti dall’Intelligenza Artificiale dipende, pertanto, sia dalla programmazione dello strumento – realizzata dai tecnici che progettano e realizzano sistemi di IA – , sia dall’entità e dalla qualità dei dati per l’addestramento. Ecco, quindi, che diventa sempre più importante avere il controllo sui dati.

Rischi operativi

Possiamo citare diversi casi di IA oggi fallimentare: i chatbot ed alcuni sistemi di previsione delle esigenze dei clienti che ti propongono offerte di acquisto in base alle tue preferenze.

I chatbot che dovrebbero fornire assistenza ai clienti in realtà fanno spesso perdere tempo al cliente perché nella stragrande maggioranza dei casi non risolvono i problemi del cliente che sarà quasi sempre costretto a contattare un essere umano (possibilmente competente, magari anche che capisca bene la nostra lingua, ma questo è un altro discorso…) dopo aver accumulato una buona quantità di frustrazioni ed essersi indispettito per il rapporto intercorso con il chatbot.

Tra l’altro recentemente si è verificato un caso in cui una Compagnia di Assicurazione si è vista dover risarcire un cliente dei costi sostenuti per un’errata risposta di un chatbot sull’applicazione di uno sconto. Se aggiungiamo a questi rischi operativi anche i rischi privacy (che vedremo dopo), allora dovremmo riflettere bene prima di “ingaggiare” un chatbot per rispondere ai clienti. Si risparmieranno risorse, ma il livello di insoddisfazione del cliente crescerà sicuramente.

Anche sulla validità dei suggerimenti di acquisto proposti dall’AI ci sarebbe molto da obiettare e il passaggio da algoritmi deterministici poco efficaci e applicazioni dell’AI nel marketing digitale dovrebbe portare un valore aggiunto tangibile.

Altre ipotesi di applicazione dell’AI sono presenti nel campo della sanità. Facciamo un esempio.

L’AI potrebbe analizzare una mole considerevole di dati di esami diagnostici e prevedere una diagnosi per un paziente, se non addirittura una cura. Potrebbe essere sicuramente utile sfruttare il lavoro dell’IA per ipotizzare una diagnosi, ma poi la decisione la deve prendere un medico competente e deve anche assumersene le responsabilità. Riguardo alla cura il problema potrebbe non essere tutto sulle previsioni dell’IA, ma sui dati di addestramento, i dati in input. Per fare un esempio ormai noto a tutti, di fronte ad un caso di Covid-19 l’IA potrebbe suggerire una cura secondo i c.d. “protocolli ufficiali”, ovvero “tachipirina e vigile attesa”, tanto per intenderci. Ma molti medici – in forza di diversi studi – ritengono che tale cura sia non adeguata. Per cui torniamo sempre alla responsabilità del medico sulla decisione da prendere, senza potersi rivalere sull’IA in caso di errore.

Stesso discorso potrebbe essere fatto per la scelta di un farmaco: incrociando i dati del paziente, la diagnosi e i farmaci disponibili per la cura l’IA potrebbe suggerire il farmaco più adatto, ma parliamo sempre di un ausilio al medico, che potrebbe aiutarlo anche a non commettere errori (ad esempio valutando i possibili effetti avversi), ma non un esonero di responsabilità.

Passando ad altri impieghi dell’AI si è molto discusso delle possibili applicazioni – anche semplicemente di ChatGPT e dei suoi “cugini” – per generare testo su determinati argomenti e sulla possibilità che un tale impiego provochi l’eliminazione di posti di lavoro.

Evidentemente CHatGPT può essere utilizzato per redigere un articolo o un post di un Blog, per riassumere un testo o un libro noto ed anche per predisporre un questionario con un certo numero di domande con risposta multipla di cui una sola corretta su un determinato argomento non troppo specifico.

In tutti questi casi, per un utilizzo professionale (ovvero ad es. non per svolgere i compiti di scuola), è comunque necessaria una supervisione di una persona esperta dell’argomento per evitare di lasciar passare errori di contenuto.  Anche la semplice sintesi di un documento normativo effettuata da un tool di AI potrebbe evidenziare rischi di interpretazione errata di alcuni passi fondamentali.

Infine, bisogna considerare che l’IA (ad es. Chat GPT) non esprime pareri, dunque se un autore volesse analizzare un argomento fornendo il proprio punto di vista, dovrebbe comunque rielaborare la risposta di ChatGPT, Copilot, Bard o altre IA.

Molto utile si prospetta l’impiego dell’IA per sviluppare codice, ma anche qui vedremo in seguito che esistono dei rischi di sicurezza, dunque la revisione e test approfonditi di un programmatore esperto è fortemente consigliata.

Rischi Privacy

Ci sono due tipi di rischi sulla protezione dei dati personali legati all’IA:

  • I dati raccolti dagli utenti che chiedono informazioni all’IA potrebbero non essere utilizzati con finalità lecite (con il consenso dell’utente dove richiesto) e tutto questo insieme di dati raccolti, se non anonimizzato, potrebbe – in caso di violazione degli archivi (data breach) – apportare danni significativi agli utenti stessi, in modo indefinito, perché non sappiamo quali domande pone e quali informazioni fornisce un utente all’IA. Ad es. un chatbot di una Banca o di una Assicurazione potrebbe raccogliere dati sensibili (dati relativi alla salute, dati finanziari, credenziali di accesso, ecc.);
  • Se un determinato processo è governato dall’IA esso potrebbe portare a decisioni che comportano rischi per i diritti e le libertà dell’interessato. Anche qui gli esempi sono molteplici: dall’errata diagnosi di una malattia di un paziente, all’assegnazione o non assegnazione di un lavoro a un candidato, alla mancata erogazione di un premio, ecc.

Non voglio qui trattare rischi dovuti ad un uso illecito dell’IA, salvo quanto riportato a proposito dell’IT Security; naturalmente come qualsiasi strumento – fisico o informatico – anche l’IA se usata per scopi criminali può arrecare danni alle persone, sia fisici che morali, compresi quelli disciplinati dalla normativa privacy (GDPR in UE).

Sicurezza informatica

Un discorso a parte va fatto sulla sicurezza informatica.

Da un lato l’AI aiuta le difese dagli attacchi hacker per riconoscere in tempo reale un attacco, un’intrusione nascosta nei sistemi, un tentativo di phishing e molto altro; dall’altro l’IA è uno strumento a disposizione anche dei criminali informatici per preparare virus, e-mail di phishing e altro in tempi più ridotti-

La sicurezza informatica dell’applicazione di IA è fondamentale per evitare risultati inattesi e potenzialmente dannosi per l’utente dell’applicazione di IA, qualunque essa sia.

L’opportunità di sfruttare l’IA per sviluppare codice sorgente (software) presenta anche la possibilità, per l’IA manomessa, di inserire codice malevolo in grado di infettare i computer che eseguiranno il programma software oppure di inserire vulnerabilità che poi potranno essere sfruttate dai criminali informatici per  introdursi nel sistema dell’utente.

Aspetti etici

Dunque, l’AI potrebbe agevolare e velocizzare molte attività, ma la supervisione ed il controllo di umani competenti è sempre necessario, sia nella progettazione del modello e dell’applicazione di IA, sia nella verifica dei risultati. Proprio perché i risultati dell’AI non dipendono da algoritmi deterministici, come devono essere testati i risultati di una comune applicazione software, a maggior ragione devono essere verificati i risultati di un’applicazione di AI prima di impiegarli per qualsiasi scopo, anche se nella maggiornaza dei casi l’IA ci fornirà un servizio migliore di qualsiasi essere umano, soprattutto in termini di tempo.

Non mi sembra ci siano tante differenze rispetto ad altre novità ed invenzioni tecnologiche del passato: dalle macchine automatiche per la produzione industriale ai programmi di elaborazione elettronica dei dati che hanno evitato di compiere azioni manuali, dalle e-mail al cloud computer, dalle auto elettriche al BIM. Tutte le innovazioni hanno portato alla scomparsa di posti di lavoro ed alla creazione di altri.

Chiaramente l’uso dello strumento deve rispettare le regole dell’etica ed in questo dovrebbero venire in aiuto le leggi che si sta cercando di introdurre, dall’AI Act in poi.

Come molti degli strumenti ed innovazioni che sono state introdotte negli ultimi decenni,  anche l’AI può essere utilizzata per compiere attività illecite, reati e provocare danni – morali e materiali –  a persone e cose, ma non per questo deve essere vietata od ostacolata. In fondo anche un coltello da cucina o un’automobile possono essere impiegati per uccidere persone!

L’AI cancellerà posti di lavoro? Ne creerà di altri? Una risposta positiva ad entrambe queste domande non deve preoccupare. In fondo ci sono già diverse decisioni e regolamentazioni, introdotte almeno a livello europeo, che potrebbero creare effetti economici negativi per alcune imprese e lavoratori e positivi per altre: gli obblighi introdotti dal legislatore UE sull’immatricolazione di sole auto elettriche e l’eliminazione delle caldaie a gas sono solo alcuni esempi significativi che impatteranno il mondo del lavoro forse più dell’introduzione dell’AI.




La sicurezza del sito web: le regole per realizzare un sito conforme

La sicurezza di un sito web è fondamentale per proteggere i dati e le informazioni degli utenti e dei gestori.

Sappiamo (dalla ISO 27001 e dal GDPR in primis) che la sicurezza va declinata nelle sue proprietà: Riservatezza, Integrità e Disponibilità. Dunque, non solo è importante garantire la riservatezza dei dati, ma anche la loro integrità (esattezza, correttezza) e la loro disponibilità in tempi idonei laddove attraverso il sito web si fornisce un servizio a clienti effettivi e potenziali. Inoltre, l’indisponibilità del sito web a causa di un attacco hacker (attacco DDOS, defacement del sito web) comporta un grave rischio reputazionale per il suo proprietario.



L’impresa deve dunque assicurarsi che il gestore del sito lo mantenga adeguatamente protetto, perché la sicurezza di un sito web è fondamentale per proteggere i dati personali e le informazioni degli utenti e dell’impresa proprietaria del sito. Tuttavia, esistono diverse vulnerabilità che possono compromettere la sicurezza di un sito web e renderlo esposto agli attacchi informatici. Alcune di queste vulnerabilità sono:

  • L’iniezione di codice, che consiste nell’inserire dei comandi o delle query malevoli nel sito web, sfruttando le sue interfacce di input. Questo può portare a modificare, cancellare o rubare i dati del sito web o ad eseguire azioni indesiderate.
  • Il cross-site scripting (XSS), che consiste nell’inserire dei codici JavaScript nel sito web, sfruttando le sue pagine web dinamiche. Questo può portare a manipolare il contenuto del sito web o a rubare le informazioni degli utenti, come i cookie o le credenziali di accesso.
  • Il cross-site request forgery (CSRF), che consiste nell’indurre gli utenti a eseguire delle richieste non autorizzate al sito web, sfruttando la loro sessione attiva. Questo può portare a modificare le impostazioni del sito web o a effettuare delle operazioni dannose, come il trasferimento di denaro o l’invio di e-mail spam.
  • Il furto di identità, che consiste nell’ottenere le informazioni personali degli utenti, come il nome, l’e-mail, il numero di telefono o i dati bancari. Questo può portare a utilizzare queste informazioni per scopi fraudolenti, come l’accesso ai loro account online o l’effettuazione di acquisti non autorizzati.

Per prevenire queste vulnerabilità e rendere il sito web più sicuro, esistono diverse misure di sicurezza che possono essere adottate. Alcune di queste misure sono le seguenti:

  • Utilizzare un protocollo HTTPS per criptare le comunicazioni tra il sito web e i visitatori. Questo impedisce che i dati possano essere intercettati o modificati da terze parti malintenzionate. Inoltre, i siti “non https” vengono considerati come pericolosi dai browser e dagli antivirus e indicizzati con priorità bassa da Google, per cui risultano meno accessibili.
  • Mantenere aggiornato il software del sito web, compresi i temi, i plugin e il sistema di gestione dei contenuti (CMS quali WordPress, Joomla od altri). Questo riduce il rischio di vulnerabilità e bug che potrebbero essere sfruttati dagli hacker.
  • Impostare delle regole di accesso al sito web, come l’utilizzo di password forti, l’autenticazione a due fattori e il blocco degli indirizzi IP sospetti. Questo limita le possibilità di accesso non autorizzato al sito web e ai suoi dati.
  • Effettuare dei backup regolari del sito web e dei suoi dati, in modo da poter ripristinare il tutto in caso di danni o perdite. Questo garantisce la continuità del servizio e la salvaguardia delle informazioni.
  • Monitorare il traffico e le attività sul sito web, per individuare eventuali anomalie o tentativi di intrusione. Questo permette di intervenire tempestivamente in caso di problemi e di prevenire ulteriori danni.

Queste sono solo alcune delle misure di sicurezza che possono essere adottate per rendere un sito web più sicuro. Ogni sito web ha delle esigenze specifiche e richiede una valutazione personalizzata delle minacce che incombono su di esso, delle sue vulnerabilità e delle sue soluzioni. Per questo, è consigliabile affidarsi a dei professionisti del settore, che possano offrire una consulenza qualificata e un supporto tecnico adeguato.

Talvolta, infatti, le web agency sono molto preparate sulle tecniche di digital marketing e di pubblicità on-line, ma lo sono meno gli sviluppatori del sito web dal punto di vista della sicurezza.

In questo ambito, poi, si inserisce il rispetto del GDPR. Il General Data Protection Regulation (GDPR) è la normativa europea che stabilisce le regole sulla protezione dei dati personali dei cittadini dell’Unione Europea. Il GDPR (Regolamento UE 2016/679) ha un impatto diretto sulla gestione dei dati personali dei visitatori del sito web. Infatti, se il sito web che raccoglie dati personali dei visitatori, è importante che rispetti il GDPR. Ecco alcune delle caratteristiche che il sito web dovrebbe avere per essere conforme al GDPR:

  1. Politica sulla privacy: Il sito web deve avere una privacy policy facilmente accessibile e comprensibile per i visitatori. La politica sulla privacy dovrebbe spiegare come i dati personali verranno raccolti, elaborati e utilizzati. Inoltre, dovrebbe essere indicato chi è il titolare del trattamento dei dati personali e come i visitatori possono esercitare i loro diritti di protezione dei dati.
  2. Cookie banner e Cookie policy: in conformità alle disposizioni relative ai cookie e tecnologie similari il sito deve presentare, all’apertura, un c.d. banner che permette di accettare o rifiutare, oppure personalizzare, la gestione dei cookie non necessari (cookie tecnici), richiamando la cookie policy (spesso inclusa nella privacy policy generale). Tale funzionalità può essere efficacemente attuata tramite appositi plugin dei CMS, progettati allo scopo.
  3. Consenso informato: I visitatori del sito web devono essere informati in modo chiaro e trasparente sui dati personali che verranno raccolti e su come verranno utilizzati. Inoltre, i visitatori devono essere invitati ad accettare o rifiutare l’utilizzo dei loro dati personali in modo esplicito e inequivocabile. Questo processo di consenso – necessario se i dati raccolti verranno utilizzati per finalità di marketing – dovrebbe essere documentato in modo che si possa dimostrare di aver ottenuto il consenso informato dei visitatori. Anche i moduli di contatto, form nei quali l’utente compila alcuni dati personali e formula una richiesta, dovranno comprendere un riferimento all’informativa privacy con un flag di spunta che attesta, almeno formalmente, che l’utente ha letto e compreso tale informativa.
  4. Protezione dei dati: Il sito web deve garantire la sicurezza e la protezione dei dati personali dei visitatori. Ciò significa che deve utilizzare misure di sicurezza tecniche e organizzative per proteggere i dati personali da accessi non autorizzati, perdite o danni. Inoltre, si dovrebbe implementare un piano di gestione dei dati personali che preveda la cancellazione dei dati personali una volta che non sono più necessari.
  5. Diritti degli interessati: I visitatori del sito web hanno diritti specifici in relazione ai loro dati personali. Questi diritti includono il diritto di accesso, il diritto di rettifica, il diritto all’oblio, il diritto di limitazione del trattamento, il diritto alla portabilità dei dati e il diritto di opposizione. Il sito web dovrebbe fornire ai visitatori un modo semplice ed efficace per esercitare questi diritti.
  6. Responsabile del trattamento dei dati: Il proprietario del sito web dovrebbe nominare un responsabile del trattamento dei dati personali nella figura del fornitore della gestione del sito (normalmente la web agency). Questo soggetto dovrebbe essere responsabile di garantire che il tuo sito web rispetti le regole del GDPR e dovrebbe essere in grado di rispondere alle istanze dei visitatori sulla gestione dei dati personali. Si ricorda che anche siti dinamici semplici, realizzati con CMS quali WordPress, memorizzano in un database del sito i dati di coloro che si iscrivono alla newsletter o compilano form di richiesta contatto. Dunque, chi gestisce il sito ha accesso ai dati personali memorizzati nel database del sito.
  7. Trasferimento dati extraUE: i dati personali memorizzati nel sito potrebbero essere ospitati in un servizio cloud collocato al di fuori dello Spazio Economico Europeo e dunque soggetto a decisioni di adeguatezza della UE oppure ad altri meccanismi atti  a garantire la conformità dei trattamenti di dati svolti fuori UE. Anche se la recente decisione della Commissione Europea (Data Protection Framework USA-UE) dovrebbe regolarizzare l’esportazione di dati personali negli Stati Uniti, occorre comunque tenere in considerazione questo aspetto, anche in considerazione dell’utilizzo di plugin specifici.

In sintesi, per essere conforme al GDPR, il sito web deve rispettare le regole sulla protezione dei dati personali dei visitatori. Ciò significa che occorre garantire la trasparenza nella raccolta e nel trattamento dei dati personali, la sicurezza dei dati e il rispetto dei diritti degli interessati. Se il sito web rispetta queste regole, i visitatori avranno maggiore fiducia nella gestione dei loro dati personali e il proprietario del sito potrà evitare pesanti sanzioni.

Normalmente i soggetti che entrano in gioco nella progettazione, sviluppo e gestione del sito web sono i seguenti:

  • Impresa committente che vuole realizzare un nuovo sito web, proprietaria del dominio internet;
  • Web Agency che gestisce le attività di digital marketing;
  • Sviluppatori software del sito
  • Cloud Service Provider che ospita il sito (hosting)

La prima risulta titolare del trattamento, gli altri nella maggior parte delle situazioni sono Responsabili del Trattamento e devono avere un apposito atto ai sensi dell’art. 28 del Reg. UE 679/2016 che li vincola al titolare del trattamento. Questo aspetto deve essere visto da entrambe i punti di vista: del committente e del fornitore. Da un lato il committente dovrà predisporre un contratto coerente con i requisiti del Regolamento UE 679/2016 e che fornisca sufficienti garanzie al proprietario del sito che ne risponde nei confronti della legge, dall’altro il fornitore potrà proporre il proprio contratto a tutti i propri clienti per semplificare la gestione e regolarizzare il rapporto definendo compiti e responsabilità di ciascuno. Per quest’attività spesso è opportuno rivolgersi ad un consulente legale affiancato da un esperto delle tecnologie utilizzate.

Chiaramente se attraverso il sito web si vendono prodotti (e-commerce) le cose si complicano e le responsabilità aumentano, per non parlare dei siti di e-commerce per la vendita di farmaci, parafarmici, cosmetici ed altri prodotti che possono far presumere uno stato di salute dell’acquirente.

L’azienda titolare del dominio è direttamente responsabile di eventuali violazioni del sito (data breach) che possono comportare conseguenze negative ai diritti e alle libertà delle persone che hanno i propri dati memorizzati nel sito, ma spesso da un lato è spinta dalla web agency che vorrebbe attuare azioni di marketing non rispettose della normativa privacy, dall’altro non riesce a controllare l’efficacia delle misure di sicurezza del sito web.

Spesso capita che l’impresa committente non si preoccupi della corretta gestione dei consensi raccolti per l’invio delle newsletter, delle c.d. “fidelity card” o di altri concorsi a premi gestiti attraversò il sito web ed eventuali app per mobile collegate ad esso e nemmeno dei corretti tempi di conservazione dei dati degli utenti nelle diverse situazioni.

Dal punto di vista del fornitore del sito è invece opportuno puntualizzare che cosa ne farà l’azienda del sito web e chi sarà responsabile della predisposizione delle informative privacy.

In conclusione, i rischi per l’impresa che commissiona la realizzazione e gestione di un sito web sono molteplici, ma anche il ruolo del fornitore deve essere correttamente inquadrato, infatti diverso è il caso di chi progetta, realizza e mantiene il sito – azioni di marketing digitale annesse – e quello del fornitore che realizza il sito, lo avvia presso un cloud provider qualsiasi e poi lo consegna all’impresa che dovrà mantenere tutto secondo normativa privacy.




Le nuove ISO 27001 e ISO 27002

security logo
Photo by Pixabay on Pexels.com

In quest’articolo andremo a commentare le nuove revisioni delle due più importanti norme della famiglia ISO 27k, avvenute nel corso del 2022:

  • ISO/IEC 27001:2022 – Information security, cybersecurity and privacy protection — Information security management systems — Requirements
  • ISO IEC 27002:2022 Information security, cybersecurity and privacy protection — Information security controls

La seconda è stata anche pubblicata dall’UNI con il prefisso UNI CEI EN alcuni mesi fa, ma di fatto l’Ente di Normazione Italiano si è astenuto dal tradurre le 170 pagine di norma, limitandosi alla traduzione del titolo (“Sicurezza delle informazioni, cybersecurity e protezione della privacy – Controlli di sicurezza delle informazioni”) e poco più, lasciando molti delusi visto che la precedente versione era stata tradotta. Ora ci si aspetta la pubblicazione della UNI CEI EN ISO 27001 con traduzione in italiano che dovrebbe costare pochi sforzi viste le limitate differenze rispetto alla versione precedente e le similitudini con altre norme con struttura HLS. Aspettative che non dovrebbero andare eluse visto che la ISO 27001 è anche una norma certificabile.



Le modifiche alla ISO 27001, oltre al recepimento dei “corriggendum” della precedente versione della norma e l’allineamento alla struttura HLS delle altre norme sui sistemi di gestione, sono veramente minime. I cambiamenti che hanno un impatto sui sistemi di gestione della sicurezza delle informazioni (SGSI) sono sostanzialmente:

  • Definire quali requisiti delle parti interessate saranno affrontate nel SGSI (punto 4.2)
  • Esplicitazione dei processi necessari al sistema di gestione (punto 4.4)
  •  Pianificazione dei cambiamenti – al punto 6.3, completamente nuovo – in piena analogia con le altre norme sui sistemi di gestione
  • Al punto 7.4 deve essere stabilito “come si deve comunicare”, ma i sottopunti d) ed e) precedenti eliminati non dicevano cose tanto diverse
  • I riferimenti ai controlli di sicurezza al punto 6.1.3 e nell’Annex A.

Proprio quest’ultimo è il cambiamento più significativo della norma in quanto stabilisce che l’elenco dei controlli dell’Annex A (e della ISO 27002) sono solo una possibile lista di controlli di sicurezza sulla quale basare il SGSI e la Dichiarazione di Applicabilità (S.o.A.).

Poiché, salvo alcune realtà particolari, non credo che la gran parte delle organizzazioni si rivolga a framework diversi da quello proposto dalla ISO 27002, direi che è proprio questa norma che apporta modifiche sostanziali al SGSI.

Dunque, i controlli della ISO 27001, che sono diventati 93 (dai 114 precedenti) restano i capisaldi della SoA e per ognuno di essi si dovrà esplicitare le eventuali motivazioni di non applicabilità e le motivazioni di applicabilità (requisiti cogenti, requisiti contrattuali o di business, esigenza derivante dalla valutazione del rischio…).

La ISO 27002, oltre ad essere stata modificata – in parte – nei contenuti dei controlli di sicurezza, è anche stata completamente cambiata nella sua struttura che risulta semplificata.

Ora, infatti, i controlli sono suddivisi in 4 (macro) temi:

  • controlli organizzativi (37 controlli);
  • controlli sulle persone (8 controlli);
  • controlli fisici (14 controlli);
  • controlli tecnologici (34 controlli)-

Anche se la maggior parte dei controlli sono classificati come “organizzativi”, fra di essi vi sono molti controlli di forte caratterizzazione tecnologica ed ICT, ad esempio:

  • A.5.7    Threat intelligence (Monitoraggio delle minacce)
  • A.5.11  Return of assets (Restituzione degli asset)
  • A.5.15  Access control (Controllo degli accessi)
  • A.5.16  Identity management (Gestione delle identità)
  • A.5.17  Authentication information (Informazioni di autenticazione)
  • A.5.21  Managing information security in the information and communication technology (ICT) supply-chain (Sicurezza delle informazioni nella filiera di fornitura ICT)
  • A.5.23  Information security for use of cloud services (Sicurezza delle informazioni per l’uso dei servizi cloud)
  • ….

Appare evidente che non solo alcuni controlli riguardano, nella stragrande maggioranza di casi, “oggetti” ICT (A.5.11: per lo più si restituiscono dispositivi elettronici, A.5.17: stiamo parlando di username e password…), ma alcuni riguardano proprio solamente informazioni in formato digitale (A.5.23). Evidentemente l’Ente normatore (ovvero il Gruppo di lavoro che ha preparato la norma) ha inteso enfatizzare la componente “gestionale” di tali controlli.

Per analogia con le “misure di sicurezza tecniche ed organizzative” richieste dal GDPR si dovrebbe – ad esempio – comprendere il “controllo degli accessi (logici)” fra le misure di sicurezza organizzative e così via.

Al di là della numerosità dei controlli nelle 4 tematiche, è interessante la suddivisione dei controlli tenendo chiaramente separati i controlli relativi alla sicurezza fisica ed ambientale, dai controlli che mettono al centro il fattore umano, dai controlli organizzativi a quelli legati alla sicurezza informatica.

Dal pinto di vista contenutistico i cambiamenti nei controlli possono essere così riassunti

  • 11 nuovi controlli
  • 35 invariati
  • 24 accorpati da controlli esistenti
  • 58 aggiornati.

In realtà se andiamo a leggere con attenzione i 93-11= 82 controlli che non sono “nuovi” troviamo molte novità, non solo dovute ad aggiornamenti tecnologici e dello stato dell’arte della cybersecurity e della data protection. Pertanto, in fase di transizione dei SGSI esistenti occorre fare molta attenzione anche ai controlli i cui contenuti non sono apparentemente variati.

Altre novità interessanti della norma riguardano la terminologia e l’introduzione degli attributi.

La norma, infatti, riporta un ampio spettro di termini, definizioni e glossario di abbreviazioni che integrano i contenuti della ISO 27000. Peccato che sia mancata la traduzione nella nostra lingua.

Ma la novità forse più rilevante è stata l’introduzione di una serie di attributi associati ad ogni controllo, una sorta di tag o metadati che caratterizzano i controlli stessi.

Ogni controllo viene caratterizzato, infatti, dai seguenti attributi:

  • Tipo di Controllo: Preventivo, di Monitoraggio (detective) o Correttivo
  • Proprietà: Riservatezza, Integrità, Disponibilità
  • Cybersecurity concepts: Identify, Protect, Detect, Respond, Recover
  • Operational capabilities: Governance, Asset management, Information protection, Human resource security, Physical security, System and network security, Application security, Secure configuration, Identity and access management, Threat and vulnerability management,         Continuity, Supplier relationships security, Legal and compliance, Information security event management, Information security assurance
  • Security domains: Governance and Ecosystem, Protection, Defense, Resilience.

Quindi, a parte le Proprietà dei Controlli (Confidentiality, Integrity e Availability in inglese) che costituiscono una mezza novità in quanto le stesse proprietà della Sicurezza delle Informazioni sono note da tempo, ma non erano state ufficialmente associate ai controlli, gli altri attributi costituiscono una grossa novità della norma al fine di classificare/categorizzare i controlli.

A fini puramente statistici possiamo notare che i controlli sono classificati in 83 Preventivi, 13 di Monitoraggio (Detective) e 14 Correttivi, da cui appare chiaro che ogni controllo può essere classificato in più di un solo tipo. Emerge anche il fatto che prevale l’ottica di prevenzione degli incidenti e delle violazioni di sicurezza. Ci si aspetterebbe che i controlli preventivi siano focalizzati alla riduzione della probabilità che una minaccia si concretizzi in un rischio di sicurezza delle informazioni, ad esempio attraverso l’eliminazione di vulnerabilità. Per i controlli classificati come Detective (o di monitoraggio) ci si aspetterebbe un indicatore di monitoraggio dell’efficacia delle misure di sicurezza adottate.

Più equilibrio c’è sulle proprietà dei controlli (R I D) dove si hanno 87 controlli che impattano la Riservatezza, 84 l’Integrità, 85 la Disponibilità: dunque sono pochi i controlli che non mirano a tutelare tutte e tre le Proprietà di sicurezza dell’informazione.

Curiosamente l’attributo Physical Security del gruppo di attributi “Operational capabilitiescomprende 16 controlli di cui 2 non appartenenti al tema dei “controlli fisici”: “Procedure operative documentate” e “Lavoro da remoto”. Naturalmente ciò si giustifica per il fatto che devono essere presenti procedure documentate sui controlli fisici e che il lavoro da remoto (lavoro agile e/o smartworking) comprende aspetti che riguardano i controlli fisici (dove svolgo il lavoro da remoto? Come proteggo la postazione di lavoro da accessi fisici non autorizzati?).

macbook pro on brown wooden table
Photo by Kevin Paster on Pexels.com

Lasciando da parte queste statistiche sulla classificazione dei controlli nei vari attributi, la cui importanza ed utilità probabilmente si evidenzierà nelle fasi applicative della norma, veniamo ad esaminare alcuni aspetti pratici.

Cosa deve fare un’organizzazione certificata ISO 27001 per migrare alla nuova versione della norma?

Come anticipato le modifiche alla ISO 27001 sono davvero poco significative e il grosso del lavoro riguarderà i controlli dell’Annex A ovvero della ISO 27002:2022.

Sono reperibili, anche nella norma ISO 27002:2022 stessa, delle tabelle di conversione tra i vecchi controlli (114) ai nuovi controlli (93). Alcuni esperti consigliano di partire da qui per “convertire” la vecchia S.o.A. nella nuova S.o.A., cercando di coprire i nuovi controlli.

Questo approccio è valido nella maggior parte dei casi e ci permette di fare una gap analysis che comunque sarà richiesta anche dagli enti di certificazione nell’eventuale audit di sorveglianza 2024 laddove l’organizzazione non sia già pronta per la migrazione alla nuova norma.

È comunque opportuno valutare se non sia il caso di ristrutturare completamente il sistema di gestione della sicurezza delle informazioni, partendo dalla valutazione dei rischi. Questo requisito, infatti, è stato rielaborato dalla norma ISO 27005:2022 che ora considera due diversi approcci e molti esperti ritengono che modelli di risk assessment diversi da quello proposto dalla linea guida ISO 27005 siano migliori, perché più snelli e più facilmente applicabili nelle nostre imprese.

Dunque, si potrebbe passare dall’approccio classico, basato su asset – minacce – vulnerabilità – probabilità – gravità, ad un approccio basato sugli scenari o solo sulle vulnerabilità, intese come assenza o inefficacia dei controlli. Al proposito si segnala la disponibilità del tool gratuito VERA di Cesare Gallotti per la valutazione dei rischi ISO 27001:2022.

Dopo la valutazione dei rischi occorre riprogettare la S.o.A., evidentemente riconsiderando solamente i documenti che descrivono l’implementazione dei vari controlli di sicurezza.

Se le policy di sicurezza e le istruzioni operative relative ai controlli erano legate alla vecchia nomenclatura dei controlli sarebbe opportuno modificare la struttura del SGSI.

Se esiste un Manuale del Sistema di Gestione (che magari copre anche altre normative, ISO 9001, ISO 14001…)  si potrebbe partire da esso per richiamare i documenti di secondo livello del SGSI, ovvero le policy o le procedure. Esse dovrebbero riportare la descrizione dei processi e delle policy di sicurezza nei vari ambiti (controlli relativi alle persone, controlli di sicurezza fisica, controllo degli accessi logici, protezione dal malware, continuità operativa, gestione relazioni con i fornitori, ecc.), comprendenti le responsabilità ed i principi generali di scurezza delle informazioni.

Tali procedure potrebbero poi richiamare delle istruzioni operative di dettaglio che descrivono le modalità operative di attuazione dei controlli, richiamando eventuali documenti di consultazione, database o prospetti consultabili da sistema informatico (applicativi, funzioni del sistema operativo, tabelle Excel o Word, ecc.).

Procedure/policy ed istruzioni operative dovrebbero poi essere richiamate nella Dichiarazione di Applicabilità (SoA) in corrispondenza dei vari controlli.

Non è efficiente predisporre una procedura o una istruzione per ogni controllo della ISO 27002, ma determinate procedure potrebbero comprendere più controlli assimilabili ad una medesima attività.

Chiaramente esisteranno documenti prodotti ed aggiornati periodicamente che dovranno rispondere ad uno o più controlli nella SoA, ad es. il Business Continuity Plan.

Una struttura con dettagli crescenti a partire dal vertice della cosiddetta “Piramide della Documentazione”, nota nei sistemi qualità da alcuni lustri, costituito dal Manuale del Sistema di Gestione, favoriscono anche una classificazione dei documenti del SGSI. Infatti Manuale e Procedure/Policy avranno un livello di astrazione tale da poterli trasmettere anche all’esterno a clienti e partner che lo richiedono, mentre le istruzioni operative ed i documenti ad essa allegati o richiamati – quali ad esempio l’elenco degli asset informatici, la mappa della rete, l’elenco degli utenti con le relative autorizzazioni, le configurazioni ICT, ecc. – dovrebbero essere classificati come documenti riservati, accessibili, anche internamente, ad un numero limitato di persone.

Naturalmente, come avviene per qualunque sistema di gestione ed a maggior ragione per i SGSI, la struttura modulare della documentazione deve essere progettata in modo che le modifiche più frequenti ai documenti riguardino un piccolo insieme di documenti a livello più basso nella Piramide della Documentazione, in quanto si tratta dei documenti di maggior dettaglio.

Per quelle organizzazioni che dispongono anche di una certificazione ISO 27017 e/o ISO 27018 la cattiva notizia è che i controlli di queste normative saranno allineati successivamente alla ISO 27002:2022, dunque, in attesa che ciò avvenga, bisogna cercare di barcamenarsi alla meglio fra nuovi e vecchi controlli e ciò non sarà poco complicato.

Infine, per chi si approccia con questa nuova versione della norma alla progettazione di un nuovo SGSI il consiglio è quello di non farsi condizionare dall’approccio minimalista della documentazione dei sistemi qualità ISO 9001 di questi tempi: nel SGSI ISO 27001 è necessario documentare molto di più, soprattutto gli aspetti di dettaglio; non solo perché sono richiesti dagli Organismi di Certificazione, ma anche perché per una gestione interna efficace ed efficiente solo mantenendo un elevato livello di documentazione delle attività operative – soprattutto quelle in ambito ICT – si riesce a mantenere il controllo delle stesse a fronte di cambiamenti di tecnologie e di persone e a garantire l’accountability del sistema, anche lato privacy (il GDPR docet).




Responsabile della Conservazione Digitale

Molte imprese si sono trovate a dover nominare il Responsabile della Conservazione (RdC) per ottemperare ai requisiti delle nuove Linee Guida AgiD sulla conservazione dei documenti digitali. Tale adempimento non riveste, infatti, solo le Pubbliche Amministrazioni, ma tutte le imprese che utilizzano sistemi di conservazione “a norma” (archiviazione sostitutiva), compresi i sistemi di fatturazione elettronica, ormai divenuti obbligatori per tutte le organizzazioni.



Chi è il Responsabile della Conservazione?

Il Responsabile della Conservazione Digitale è una figura chiave nell’ambito della conservazione e gestione dei documenti digitali, in particolare per quanto riguarda le pubbliche amministrazioni. Secondo l’Agenzia per l’Italia Digitale (AgID), il Responsabile della Conservazione Digitale (Responsabile della Conservazione) ha il compito di garantire che i documenti digitali prodotti o conservati dall’ente siano adeguatamente gestiti e conservati nel rispetto delle norme e delle linee guida stabilite a livello nazionale.

Il Responsabile della Conservazione deve essere un professionista con conoscenze specifiche nel campo della conservazione digitale e delle tecnologie informatiche, in grado di gestire le complessità tecniche e normative legate alla gestione dei documenti digitali. Deve essere in grado di pianificare, coordinare e controllare tutte le attività relative alla conservazione digitale, garantendo che siano rispettati i criteri di completezza, integrità, accessibilità e leggibilità dei documenti.

Il Responsabile della Conservazione è anche responsabile di garantire la conformità alle norme in materia di privacy e protezione dei dati personali, di assicurare la corretta gestione dei sistemi di conservazione digitale e di gestire la sicurezza delle informazioni digitali.

Inoltre, il Responsabile della Conservazione deve essere in grado di collaborare con altre figure professionali all’interno dell’ente, come l’archivista o il responsabile dell’informatica, per garantire la massima efficienza e integrità delle attività di conservazione digitale.

In sintesi, il Responsabile della Conservazione Digitale è un professionista chiave per la conservazione e gestione dei documenti digitali delle pubbliche amministrazioni, con il compito di garantire che i documenti siano conservati in modo sicuro, completo e accessibile, in conformità con le norme e le linee guida stabilite.

Il Responsabile del Servizio di Conservazione è una figura chiave nell’ambito della conservazione e gestione dei documenti digitali delle pubbliche amministrazioni. Secondo l’Agenzia per l’Italia Digitale (AgID), il Responsabile del Servizio di Conservazione (RSC) è responsabile della definizione, implementazione e gestione delle politiche e delle attività relative alla conservazione digitale all’interno dell’ente.

Chi è il Responsabile del Servizio di Conservazione?

Il RSC deve essere un professionista con competenze specifiche nel campo della conservazione digitale e delle tecnologie informatiche, in grado di pianificare, coordinare e controllare tutte le attività relative alla conservazione digitale. Deve anche essere in grado di garantire la conformità alle norme in materia di privacy e protezione dei dati personali, e di gestire la sicurezza delle informazioni digitali.

Il Responsabile del Servizio di Conservazione è anche responsabile di assicurare la completezza, l’integrità, l’accessibilità e la leggibilità dei documenti digitali conservati, e di collaborare con altre figure professionali all’interno dell’ente per garantire la massima efficienza e integrità delle attività di conservazione digitale.

Inoltre, il Responsabile del Servizio di Conservazione deve essere in grado di monitorare e valutare costantemente le attività di conservazione digitale e di adottare le misure necessarie per garantire che i documenti digitali siano conservati in modo sicuro e che siano rispettati i criteri stabiliti dalle norme e dalle linee guida.

In sintesi, il Responsabile del Servizio di Conservazione è un professionista chiave per la conservazione e gestione dei documenti digitali delle pubbliche amministrazioni, con il compito di pianificare, coordinare e gestire le attività di conservazione digitale in modo da garantire che i documenti siano conservati in modo sicuro, completo e accessibile, e che siano rispettati i criteri stabiliti dalle norme e dalle linee guida.

Secondo la normativa italiana, tutte le pubbliche amministrazioni devono nominare un Responsabile del Servizio di Conservazione (RSC) per la gestione dei documenti digitali. Questo include enti locali, regioni, amministrazioni centrali, enti pubblici non economici e altre organizzazioni pubbliche.

Inoltre, anche alcune organizzazioni private che gestiscono informazioni sensibili o documenti di interesse pubblico possono essere tenute a nominare un Responsabile del Servizio di Conservazione.

La nomina del Responsabile del Servizio di Conservazione deve essere effettuata con un atto formale da parte dell’organizzazione interessata e deve essere pubblicata sul sito web dell’ente. Il RSC deve essere un professionista con competenze specifiche nel campo della conservazione digitale e delle tecnologie informatiche, in grado di garantire la corretta gestione dei documenti digitali dell’ente.

Il Responsabile del Servizio di Conservazione (RSC) deve possedere alcuni requisiti specifici per garantire una gestione corretta e conforme alle norme dei documenti digitali delle pubbliche amministrazioni.

Questi requisiti includono:

  1. Competenze specifiche nel campo della conservazione digitale e delle tecnologie informatiche.
  2. Conoscenza delle norme e delle linee guida in materia di conservazione digitale, privacy e protezione dei dati personali.
  3. Capacità di pianificare, coordinare e gestire le attività di conservazione digitale, garantendo la sicurezza, la completezza e l’accessibilità dei documenti digitali conservati.
  4. Conoscenza delle tecnologie e delle soluzioni utilizzate per la conservazione digitale, inclusi sistemi di gestione dei documenti digitali e di archiviazione.
  5. Capacità di monitorare e valutare costantemente le attività di conservazione digitale e di adottare le misure necessarie per garantire la massima efficienza e integrità.

Inoltre, è importante che il Responsabile del Servizio di Conservazione abbia una buona conoscenza della lingua italiana e delle norme sulle pubbliche amministrazioni, in modo da garantire la comprensione e l’applicazione delle norme e delle linee guida in materia di conservazione digitale.

In sintesi, il Responsabile del Servizio di Conservazione deve essere un professionista con competenze specifiche nel campo della conservazione digitale e delle tecnologie informatiche, in grado di garantire la corretta gestione dei documenti digitali dell’ente e di rispettare le norme in materia di privacy e protezione dei dati personali.

Invece il Responsabile della Conservazione, figura interna all’organizzazione, deve possedere i seguenti requisiti:

  1. Competenze specifiche nel campo della conservazione digitale e delle tecnologie informatiche.
  2. Conoscenza delle norme e delle linee guida in materia di conservazione digitale, privacy e protezione dei dati personali.
  3. Capacità di pianificare, coordinare e gestire le attività di conservazione digitale, garantendo la sicurezza, la completezza e l’accessibilità dei documenti digitali conservati.
  4. Conoscenza delle tecnologie e delle soluzioni utilizzate per la conservazione digitale, inclusi sistemi di gestione dei documenti digitali e di archiviazione.
  5. Capacità di monitorare e valutare costantemente le attività di conservazione digitale e di adottare le misure necessarie per garantire la massima efficienza e integrità.

Inoltre, è importante che il Responsabile della Conservazione abbia una buona conoscenza della lingua italiana e delle norme sulle pubbliche amministrazioni, in modo da garantire la comprensione e l’applicazione delle norme e delle linee guida in materia di conservazione digitale.

In sintesi, il Responsabile della Conservazione Digitale deve essere un professionista con competenze specifiche nel campo della conservazione digitale e delle tecnologie informatiche, in grado di garantire la corretta gestione dei documenti digitali dell’ente e di rispettare le norme in materia di privacy e protezione dei dati personali.

Ma non tutti i responsabili di funzione o direttori di funzione o area possono ricoprire il ruolo di RdC.

Infatti, secondo l’AgiD (Agenzia per l’Italia Digitale), i seguenti responsabili di funzione interne all’organizzazione non possono ricoprire il ruolo di Responsabile della Conservazione Digitale:

  1. Il responsabile del trattamento dei dati personali, poiché questa figura ha responsabilità diverse in materia di privacy e protezione dei dati personali.
  2. Il responsabile della sicurezza del sistema informatico, poiché questa figura ha la responsabilità di garantire la sicurezza del sistema informatico e non quella della conservazione digitale.
  3. Il responsabile del sistema informativo, poiché questa figura ha la responsabilità di gestire il sistema informativo dell’ente e non la conservazione digitale dei documenti digitali.

In sintesi, il Responsabile della Conservazione Digitale deve essere una figura distinta e indipendente da altri responsabili di funzione interne all’ente, in grado di garantire la corretta gestione dei documenti digitali in conformità alle norme in materia di conservazione digitale e di privacy.

Il Manuale della Conservazione

Uno dei compiti non delegabili del RdC è la redazione del Manuale della Conservazione.

Il Manuale della Conservazione Digitale è un documento che definisce le procedure, le politiche e le linee guida per la corretta gestione dei documenti digitali conservati da un’organizzazione. Il manuale è un supporto importante per il Responsabile della Conservazione Digitale (Responsabile della Conservazione) nell’esercizio delle proprie funzioni e nella realizzazione delle attività di conservazione digitale.

Il manuale della conservazione digitale comprende:

  1. Le politiche e le linee guida per la gestione dei documenti digitali, inclusi il processo di acquisizione, catalogazione, conservazione e accesso.
  2. Le procedure per la verifica dell’integrità e la verifica periodica dei documenti digitali conservati.
  3. Le procedure per la gestione delle modifiche e degli eventuali danni ai documenti digitali.
  4. Le linee guida per la sicurezza dei documenti digitali, inclusi i requisiti per la protezione dei dati personali e la protezione dei documenti digitali da eventuali perdite o danneggiamenti.

In sintesi, il manuale della conservazione digitale è uno strumento fondamentale per garantire la corretta gestione dei documenti digitali conservati da un’organizzazione, in conformità alle norme e alle linee guida in materia di conservazione digitale e privacy.




Valutazione del rischio per la sicurezza delle informazioni vs. valutazione del rischio privacy

Tischio per le informazioni

In un precedente articolo abbiamo trattato della valutazione del rischio privacy per adempiere ai requisiti del GDPR (Regolamento UE 2016/679 sulla protezione dei dati personali), ma chi ha o deve implementare un sistema di gestione per la sicurezza delle informazioni come deve considerare la valutazione dei rischi sui trattamenti di dati personali? Tale valutazione è implicita nella valutazione dei rischi sulla sicurezza delle informazioni, ovvero è un “di cui” di essa? Oppure, come sostengono alcuni esperti di privacy, è tutta un’altra cosa e va considerata separatamente? Cerchiamo di chiarire questi aspetti.



Cos’è il rischio per la sicurezza delle informazioni?

Partiamo dalla valutazione del rischio per la sicurezza delle informazioni, ovvero essenzialmente per i sistemi di gestione certificati ISO 27001.

Prima di parlare di valutazione del rischio dovremmo soffermarci sulla terminologia: sicurezza delle informazioni non è “sicurezza informatica” e non è “cybersecurity”. Tralasciamo le discussioni sul termine cybersecurity (in italiano “sicurezza cibernetica”?) che per taluni equivale alla sicurezza informatica, per altri è la protezione delle informazioni digitali da attacchi informatici (non da incidenti naturali!), per altri ancora ha a che fare con la sicurezza degli appartai IT e OT…

La sicurezza informatica è un sottoinsieme della sicurezza delle informazioni? Dunque, la valutazione del rischio ICT è una parte della valutazione del rischio per la sicurezza delle informazioni?

Non è proprio così, ma quasi: la sicurezza informatica riguarda gli apparati ICT che normalmente trattano informazioni digitali. Ora un problema tecnico, dovuto ad un attacco informatico deliberato oppure ad un evento accidentale, comporta anche un rischio per la sicurezza delle informazioni? In teoria non è sempre così perché un attacco informatico ad una infrastruttura critica (ad es. un acquedotto o una rete elettrica) generalmente non comporta conseguenze sulla sicurezza delle informazioni, ovvero sulla sua declinazione in riservatezza, integrità e disponibilità. Perciò non costituisce un rischio per la sicurezza delle informazioni? Ma le apparecchiature informatiche e le infrastrutture ICT cosa trattano? Non trattano byte, ovvero informazioni? Facciamo un esempio su un fatto accaduto di recente: il blocco del traffico aereo alcuni giorni fa negli Stati Uniti è stato provocato da un incidente informatico, pare fosse colpa di un file “corrotto” (ma anche se fosse stato un attacco di hacker Russi, cosa che non ci diranno mai, la sostanza non cambierebbe): ebbene è considerato un incidente sulla sicurezza delle informazioni, ovvero si è concretizzato un rischio sulla sicurezza delle informazioni? Apparentemente no perché le conseguenze sono state il blocco dei voli con disagi per i passeggeri, maggiori costi per Compagnie Aeree e passeggeri e così via. Ma la causa di tutto questo non è stata la mancanza di informazioni (= mancata disponibilità di informazioni) sulla sicurezza dei voli che ha fatto prudentemente mantenere a terra molti aeromobili?

Ovviamente tutto dipende dal contesto in cui si trova l’organizzazione che deve valutare i rischi e qual è il campo di applicazione del sistema di gestione ISO 27001 che, nel caso, ci chiede la valutazione del rischio.

Il viceversa – ovvero che la sicurezza informatica non copra tutta la sicurezza delle informazioni – è dimostrabile in modo più semplice: le informazioni su supporto cartaceo devono essere protette e la loro protezione generalmente non riguarda la sicurezza informatica.

La valutazione del rischio sulla sicurezza delle informazioni

Fatta questa premessa andiamo ad esaminare cosa ci dice la teoria e la letteratura sul risk assessment per l’information security, ovvero per il SGSI ISO 27001.

In principio fu la vecchia versione della ISO 27005 a guidare queste valutazioni del rischio sulla sicurezza delle informazioni. In sintesi, questa norma ci diceva di partire dal censimento degli asset dell’organizzazione, di andare a vedere quali informazioni essi trattano (information asset) e, quindi, fare una valutazione del valore degli asset riguardo alle caratteristiche di sicurezza, ovvero riservatezza, integrità e disponibilità.

Poi occorreva identificare le minacce alla sicurezza delle informazioni (gli attacchi hacker, gli incendi, gli errori di configurazione dei sistemi, ecc.) e le vulnerabilità presenti negli asset (sistemi non aggiornati, assenza di protezione fisica del CED, mancanza di consapevolezza del personale, ecc.).

Una combinazione di questi elementi, ovvero una minaccia che sfrutta una vulnerabilità per far concretizzare un rischio su un determinato asset veniva ponderata in base alla probabilità di accadimento (in realtà viene usato il termine verosimiglianza) x la gravità delle conseguenze/danno potenziale x il valore dell’asset, al fine di ottenere un determinato livello di rischio quali-quantitativo.

Oggi l’ultima versione della medesima norma prende in considerazione due approcci:

  • Approccio basato sugli eventi: i rischi possono essere identificati attraverso le considerazioni della Direzione e il contesto dell’organizzazione. Questo permette di concentrare gli sforzi sui rischi più critici, senza disperdersi nella valutazione di numerosi rischi che poi giudicherò minori e non degni di essere considerati con azioni di trattamento.
  • Approccio basato sugli asset: i rischi possono essere identificati attraverso l’ispezione di asset, minacce e vulnerabilità. È quello già previsto dalla precedente edizione della ISO 27005.

Altri metodi di valutazione del rischio possono essere utilizzati, classificati in genere in metodi quantitativi (basati su un calcolo più o meno “preciso” del rischio, a fronte di valutazioni della probabilità matematica di accadimento dell’evento negativo e di valutazione quantitativa del danno, ad es. in termini economici) e qualitativi (il valore del rischio: “Alto”, “Medio”, “Basso”, ecc. non è espresso in valori assoluti, ma rappresenta solo un metodo di confronto fra i vari rischi).

In generale questi metodi qualitativi, secondo alcuni esperti, portano sempre ad un calcolo del rischio basato sulla formula:

r(m, a, v) ∝ p(m) ⋅ i(m, a) ⋅ g(v)

dove r rappresenta la funzione “rischio” che dipende da m= minacce, a= asset, v= vulnerabilità in modo proporzionale alla probabilità di accadimento della minaccia, all’I=impatto della minaccia sull’asset e alla g=gravità della vulnerabilità.

Un approccio completamente diverso, proposto da altri esperti, non prende in considerazione le minacce, ma parte dalle vulnerabilità presenti per determinare i rischi concreti che dovranno essere valutati attraverso la classica formula Rischio =Possibilità di accadimento x Gravità del danno o delle conseguenze provocate dal concretizzarsi del rischio.

Le fasi successive del processo di valutazione dei rischi, dopo la loro identificazione, sono sempre le stesse: analisi dei rischi, ponderazione dei rischi, scelta delle opzioni di trattamento, determinazioni dei controlli/contromisure necessari, confronto con i controlli dell’Annex A della ISO 27001 e definizione della Dichiarazione di Applicabilità (S.o.A.).

Tra i modelli disponibili per il calcolo del rischio sulla sicurezza delle informazioni secondo la ISO 27001 segnaliamo il tool VERA di Cesare Gallotti (https://www.cesaregallotti.it/Pubblicazioni.html ) che prevede l’identificazione di una serie di Minacce/Rischi per le quali sono attribuiti una probabilità di accadimento ed un impatto fino a costituire il c.d. “rischio puro” o “rischio intrinseco”. Quindi vengono stabilite le vulnerabilità che non sono altro che l’inversamente proporzionale ai controlli, ovvero all’efficacia degli stessi. Combinando il rischio intrinseco con le vulnerabilità/controlli si ottiene il valore del rischio calcolato sulla sicurezza delle informazioni. Tale modello comprende anche una parte legata alla privacy (comunque cogente anche in ambito SGSI) nella quale si valutano i soli rischi (minacce) attinenti alla privacy e le relative conseguenze.

Altri esperti definiscono il “rischio inerente” come il rischio derivante dalla combinazione di probabilità/possibilità di accadimento dell’evento e dalla gravità delle conseguenze. Applicando i controlli di sicurezza, ovvero le contromisure (le misure di sicurezza tecniche ed organizzative in termini privacy) si ottiene il “rischio residuo”, che dovrà poi essere confrontato con i criteri di accettabilità per stabilirne le opzioni di trattamento.

Altri schemi e standard prevedono valutazioni dei rischi sulla sicurezza ICT, che oggi costituisce parte preponderante della sicurezza delle informazioni. Gli approcci possono essere leggermente diversi, ma sostanzialmente non si discostano dalla seguente metodologia-

  1. Identifico le minacce che incombono sui sistemi e sui dati (es. virus ransomware o, più in dettaglio le tecniche che rendono possibile un attacco ransomware: phishing, social engineering, attacchi di forza bruta a siti web per la ricerca di credenziali di accesso, ecc.)
  2. Identifico gli eventi che, se si concretizza la minaccia, possono costituire un rischio per i miei dati
  3. Valuto le misure di mitigazione che sono state implementate per fronteggiare il rischio.
  4. Valuto la probabilità di accadimento dell’evento.
  5. Valuto l’impatto che comporta tale rischio per i dati e tutto quel che ne consegue.
  6. Calcolo il valore del rischio (residuo).
  7. Definisco le azioni di trattamento del rischio (accettare il rischio oppure adottare ulteriori misure di prevenzione o protezione per ridurre il rischio o addirittura eliminarlo.

La valutazione del rischio privacy

Quando si valuta il rischio relativo alla privacy, è possibile identificare minacce specifiche per la privacy. Tra di esse vi sono:

  • rappresentazione scorretta, se i dati relativi a una persona sono errati, oppure presentati o elaborati in modo non corretto possono provocare danni all’interessato; questa minaccia può anche riguardare i risultati della profilazione di una persona (che, ad esempio, potrebbe essere esclusa da programmi sanitari o economici), eventualmente anche con strumenti basati sull’intelligenza artificiale;
  • distorsione, ossia l’interpretazione volutamente o inavvertitamente scorretta dei dati, con potenziali impatti negativi sulla singola persona; questa minaccia è, in pratica, quella del pettegolezzo e della maldicenza, che può portare al biasimo, alla stigmatizzazione, all’isolamento e anche alla perdita di libertà di una persona;
  • sorveglianza, attraverso l’uso dei dati, soprattutto in ambito informatico; è necessario riconoscere la differenza tra logging (ossia la raccolta di dati per assicurare la sicurezza delle persone e della proprietà) e la sorveglianza (che porta, anche se non sempre per scelta deliberata, a discriminazione, perdita di fiducia, autonomia o libertà, danni fisici o materiali);
  • blocco alla conoscenza dei dati trattati, ossia segretezza in merito al fatto che i dati personali sono trattati e alle modalità con cui lo sono; questo può portare all’uso dei dati personali iniquo e, per le singole persone fisiche, alla mancanza di autodeterminazione, alla perdita di fiducia e a perdite economiche;

In pratica le minacce per la privacy potrebbero essere diverse da quelle per la sicurezza delle informazioni, o meglio alcune (la maggioranza) coincidono, altre sono differenti. Ma se consideriamo che l’informazione è anche un dato personale e che la stessa ISO 27001 comprende un controllo denominato “Privacy e protezione dei dati personali” (controllo A.18.1.4 della versione 2013 della ISO 27001-27002) capiamo bene che – nella valutazione del rischio per la sicurezza delle informazioni – dobbiamo considerare anche gli impatti che una determinata violazione di dati personali può avere sui diritti e le libertà dell’interessato e non solo sul business dell’organizzazione.

Dunque un medesimo evento rischioso, ad esempio un data breach sul portale web dell’azienda oppure un ransomware che non comporta un’esfiltrazione di dati (anche personali), ma “soltanto” un blocco dei sistemi per un paio di giorni, potrebbe portare ad una valutazione e, quindi, ad un indice (livello) di rischio differente semplicemente perché – a parità di probabilità di verificarsi dell’evento – l’impatto sui diritti e le libertà dell’interessato, piuttosto che sul business dell’organizzazione, può essere sensibilmente diverso.

Quindi la valutazione dei rischi potrebbe essere unica a patto di considerare i differenti effetti a fronte del verificarsi di medesimi eventi.

Naturalmente ogni organizzazione avrà i suoi parametri e le sue specificità: dal punto di vista dell’interessato: un conto è un blocco dei sistemi informativi per un paio d giorni di un Ospedale ed un conto è il medesimo blocco per un’azienda manifatturiera dove probabilmente il fatto di non poter accedere ai dati dei dipendenti per un paio di giorni non costituirebbe un gran problema (salvo che non sia il giorno di pagamento degli stipendi…).

Tuttavia, alcuni esperti della materia privacy potrebbero obiettare: ma per il GDPR devo valutare i rischi sui trattamenti di dati personali, quindi considerare i rischi per ogni trattamento! Allora bisognerebbe riprendere il concetto di “Asset” dove i dati personali (dei dipendenti, dei clienti, ecc.) costituiscono un “asset informativo” con un certo valore, dato dalla combinazione delle diverse caratteristiche di sicurezza (Riservatezza, Integrità e Disponibilità).

Spesso, però, si può semplificare considerando il caso peggiore (worst case), ovvero dato un determinato evento rischioso (ad es. un data breach sul portale web) consideriamo lo scenario peggiore per tutti i trattamenti di dati personali. Allora per i trattamenti dei dati personali dei dipendenti avrò un determinato impatto, mentre per i dati personali dei clienti avrò un impatto di tipo e valore diverso: nel nostro caso di esempio per l’Ospedale il rischio maggiore sarebbe sui dati dei pazienti e dei relativi trattamenti (es. prenotazioni, refertazione visite ed esami, ecc.), mentre per l’azienda manifatturiera il rischio più elevato sarà sui trattamenti dei dati dei dipendenti (elaborazione paghe, ecc.).

Evidentemente la valutazione del rischio privacy per ogni singolo trattamento di dati personali che abbiamo inserito nel Registro delle Attività di Trattamento (ai sensi dell’art. 30 del GDPR) potrebbe risultare parecchio oneroso e non giustificato per una medio-piccola organizzazione. È comunque sempre opportuno raggruppare più trattamenti sui quali incombono i medesimi fattori di rischio. Ad esempio in un’organizzazione che gestisce tutti i dati in formato digitale attraverso file di Office conservati in un file Server ed un unico applicativo gestionale è perfettamente inutile replicare le medesime minacce ed eventi di rischio legati all’IT su diversi trattamenti. Eventuali vulnerabilità o misure di sicurezza non completamente efficaci legate al controllo degli accessi degli utenti, agli strumenti anti-malware, ai backup o alla (scarsa) consapevolezza del personale impattano su tutti i trattamenti di dati personali e basterà considerare solo il caso peggiore, ovvero l’impatto di gravità più alta su tutti i trattamenti per “risolvere” il problema della valutazione del rischio privacy. Infatti, ai fini della protezione dei dati personali, il trattamento del rischio che andremo ad attuare sarà finalizzato a prevenire il rischio (abbassare la probabilità che la minaccia si concretizzi) oppure a proteggere il dato dall’evento che non può essere completamente evitato (ridurre la gravità dell’impatto), dunque miglioreremo la protezione dei dati personali su tutti i trattamenti effettuati.

In conclusione il problema non è pensare di coprire anche la valutazione del rischio privacy attraverso una valutazione più ampia sulla sicurezza delle informazioni, ma fare quest’ultima valutazione in modo incompleto, senza considerare nel modo corretto i rischi associati alla protezione dei dati personali.

Come spesso accade, se si fanno le cose per bene si può fare (quasi) tutto.




La certificazione SSAE 18 per i servizi in outsourcing

Oggi le imprese tendono ad esternalizzare molti processi ed attività secondarie al fine di ottimizzarne i costi e la qualità del servizio risultante che, se svolto da personale specializzato, è spesso superiore a quello ottenibile impiegando il personale interno.

Alcune di queste attività – ad esempio la gestione delle paghe e del personale, l’acquisizione di documenti e dati in formato digitale e la relativa archiviazione sostitutiva, la gestione contabile e fiscale, i servizi informatici, ecc. – prevedono la gestione di informazioni critiche del punto di vista della riservatezza e degli aspetti legali e di compliance ad essi correlati.



Per questo motivo alcune aziende internazionali – multinazionali o grandi gruppi con sedi all’estero, in particolare negli Stati Uniti – richiedono, alle loro filiali o consociate italiane, evidenza della buona gestione dei servizi affidati in outsourcing.

Per le aziende soggette a tale standard la Sezione 404 del Sarbanes-Oxley Act (SOX) richiede che i fornitori di servizi in outsourcing siano provvisti di una particolare certificazione, il Report SSAE 18, per garantire che controlli e processi interni siano appropriati alla gestione delle informazioni dei propri clienti.

La crescente richiesta di servizi in outsourcing pone, quindi, l’esigenza da parte delle organizzazioni che forniscono tali servizi delle tipologie sopra elencate (payroll, contabilità, gestione documentale, ecc.) di fornire ai propri clienti e ad altri soggetti un rapporto di revisione completo sui sistemi di controllo e sui processi, al fine di assicurare che i servizi erogati alla clientela siano sicuri e conformi a uno standard riconosciuto.

La certificazione SSAE no. 18 è il nuovo standard per effettuare la reportistica sui controlli nelle aziende di servizi – sostituendo le precedenti SSAE no. 16 e SAS no. 70 – e risponde alla domanda crescente di disporre di regole conformi a standard internazionali riconosciuti in tutto il mondo, migliorativi rispetto ad una semplice certificazione ISO 9001 o ad una ISO 27001. Le modifiche apportate dal nuovo standard richiedono alle aziende di prendere maggiore controllo e proprietà dei propri controlli interni, relativamente all’identificazione e alla classificazione del rischio e alla gestione appropriata delle relazioni con i fornitori di terze parti.

Il report SSAE 18 (Statement on Standards for Attestation Engagements no. 18) viene rilasciato da auditor indipendenti qualificati dall’AICPA (dall’American Institute of Certified Public Accountants) dopo un articolato processo di analisi dei processi interni, confronto degli stessi con un’apposita matrice di controlli che produrrà una gap analysis la quale costituirà il punto di partenza per portare, attraverso l’introduzione di idonei controlli ed apposita documentazione procedurale, alle verifiche di efficacia dei controlli implementati atti a garantire l’adeguatezza degli stessi e delle informazioni processate.

Il report SSAE 18 costituisce un’esaustiva fotografia del funzionamento dell’organizzazione di servizi e dei controlli implementati per garantire non solo la conformità del servizio, ma anche la sicurezza nella gestione dei dati elaborati.

Il processo che porta alla certificazione SSAE 18 comprende una dettagliata mappatura dei processi organizzativi e dei flussi informativi che permette di effettuare la mappatura degli obiettivi di controllo, delle criticità e dei rischi, finalizzata alla valutazione dei rischi (risk assessment), imprescindibile punto di partenza per qualsiasi sistema di controllo interno.

Sebbene questo schema SSAE 18 ricalchi per alcuni elementi la certificazione ISO 9001 e la certificazione ISO 27001, esso presenta una valenza particolare in determinati settori e costituisce il logico completamento in un percorso di miglioramento e di qualificazione dell’organizzazione di servizi nei confronti del cliente.

Tale certificazione, si ribadisce, è rivolta in particolare alle seguenti organizzazioni di servizi:

  • Servizi di gestione paghe del personale
  • Acquisizione dati e documenti in formato digitale
  • Conservazione sostitutiva
  • Servizi contabili e fiscali
  • Servizi di assistenza e sviluppo software



TISAX: la sicurezza delle informazioni nell’automotive

La normativa IATF 16949 prevede alcuni requisiti che riguardano la sicurezza delle informazioni dell’organizzazione automotive ed infatti le Sanctioned Interpretation riguardano anche la sicurezza delle informazioni gestite. Ricordiamo che una Sanctioned Interpretation modifica l’interpretazione di una regola o di un requisito della IATF 16949 e diventa essa stessa la base di una non conformità.



In particolare, alcune di esse riguardano ai punti seguenti:

6.1.2.3 PIANI DI EMERGENZA

L’organizzazione deve:

a) – b) (…)

c) preparare piani di emergenza per la continuità della fornitura in caso si verifichino: guasti di apparecchiature chiave (vedere anche sezione 8.5.6.1.1), interruzione dei prodotti, processi e servizi di fornitura esterna, disastri naturali, incendi, interruzione di servizi, attacco informatico ai sistemi informativi, mancanza di manodopera o problemi alle infrastrutture.

S.I.: “Le organizzazioni devono affrontare la possibilità di un attacco informatico che potrebbe interrompere le proprie attività produttive e logistiche, inclusi i ransomware. Le organizzazioni devono assicurarsi di essere preparate in caso di attacco informatico.”

7.1.3.1 PIANIFICAZIONE DELLO STABILIMENTO, DEI MEZZI E DELLE APPARECCHIATURE

…l’organizzazione deve… implementare la protezione informatica delle apparecchiature e dei sistemi di supporto della produzione

S.I.: “La sicurezza informatica non si limita alle funzioni di supporto e alle aree degli uffici che utilizzano i computer. Anche la produzione utilizza controlli e attrezzature computerizzati potenzialmente a rischio in caso di attacchi informatici. L’aggiunta di questo requisito guida verso l’implementazione delle protezioni necessarie per garantire il continuo funzionamento e l’ininterrotta produzione, al fine di soddisfare le esigenze dei clienti”

Le suddette prescrizioni restano generiche e non entrano molto nel merito di una disciplina molto articolata e complessa come quella della sicurezza delle informazioni in generale e della sicurezza informatica in particolare.

Per questa ragione è uscito lo standard TISAX® (Trusted Information Security Assessment eXchange), che rappresenta uno schema a fronte del quale le aziende automotive più importanti (OEM, Tier 1) richiedono l’assessment ai loro fornitori in quanto essi trattano informazioni critiche dal punto di vista della Riservatezza, dell’Integrità e della Disponibilità delle stesse.

È facile immaginare che alcune informazioni scambiate nella catena di fornitura automotive, richiedono una certa protezione. Si tratta di: dati di prodotti e di componenti (specifiche tecniche, documenti progettuali e disegni dimensionali, dati di validazione file PPAP/APQP, dati di collaudo e omologazione), dati aziendali fondamentali per il business (schede processi, programmi di produzione, software di produzione e manutenzione, informazioni personali, strategie aziendali, dati di marketing e di vendita), dati collegati ai rapporti tra fornitori e clienti del settore (offerte, contratti, ordini di componenti, fatture, piani di consegne, dati e informazioni su clienti e fornitori), dati su veicoli (anomalie, guasti, richieste di assistenza, …).

TISAX è un meccanismo di valutazione e di scambio dei risultati di un assessment fra le organizzazioni della catena di fornitura automotive, nato per iniziativa del VDA tedesco – attualmente responsabile dello schema – e che si sta affermando come una declinazione degli standard di sicurezza delle informazioni (ISO 27001 su tutti, ma anche SPICE ISO 15504 per il software automotive) nel settore automotive.

Il sistema TISAX si basa su:

  1. Una registrazione dell’azienda al TISAX®
  2. La scelta di un organismo (audit provider) che effettua audit secondo questo schema
  3. L’esecuzione dell’assessment da parte dell’organismo indipendente
  4. La condivisione dei risultati dell’assessment con i partecipanti al TISAX e l’accesso ai dati degli altri partecipanti.

I partecipanti registrati al TISAX possono anche essere OEM che si ritengono partecipanti “passivi” in quanto non effettuano un assessment, ma invitano i loro fornitori a farlo per poi accedere ai risultati dell’assessment stesso.

L’intero meccanismo è monitorato dall’ENX, associazione no profit che svolge un ruolo simile ad un Ente di Accreditamento.

L’audit o assessment TISAX porta ad ottenere una “Label” mediante un processo che è del tutto simile a quello delle certificazioni dei sistemi di gestione.

L’assessment TISAX ha uno scopo, un ambito di applicazione per il quale viene valutato dall’audit provider (esiste lo scopo di tipo Standard, Narrow ed Extended).  L’ambito di applicazione di una valutazione TISAX, però, non può essere determinato dall’organizzazione, ma deve necessariamente comprendere tutti i processi e le risorse coinvolte nel trattamento di informazioni afferenti all’industria automobilistica.

Dallo scopo derivano gli obiettivi dell’assessment che permettono di ottenere una “Label” di un determinato tipo (Livello di Maturità da 0 = Incomplete a 5 = Optimizing).

La documentazione (tutta in lingiua inglese o tedesca) resa disponibile per questo schema è ampia e comprende un TISAX Handbook dettagliato, un TISAX Simplified Group Assessment e soprattutto una check-list per l’autovalutazione. Tutti i documenti aggiornati sono reperibile al link https://portal.enx.com/en-US/TISAX/downloads/.

Anche l’audit non è di un unico tipo: esiste l’audit di livello 1 (AL 1) che essenzialmente è una autovalutazione dell’organizzazione, quello di livello 2 (AL 2) che consiste in una verifica di quanto indicato dall’azienda nel questionario di valutazione, condotta prevalentemente da remoto, infine l’audit di livello 3 (AL 3) è più completo ed approfondito, dunque più severo per l’organizzazione.

Probabilmente molte organizzazioni a cui è stato richiesto dai loro clienti un assessment TISAX non sanno rispondere alle domande della check-list di autovalutazione, oppure risponderebbero in modo errato senza una consulenza competente in grado di guidarli verso l’audit/assessment TISAX senza rischiare di fare un buco nell’acqua.

blue silver black car engine
Photo by Pixabay on Pexels.com

La check-list per l’assessment TISAX propone, per ciascun punto di controllo, uno o più obiettivi di controllo ai quali sono associati requisiti obbligatori (must), requisiti auspicabili (should), requisiti aggiuntivi necessari laddove è richiesto un elevato livello di protezione delle informazioni e, tra le altre informazioni, il riferimento al requisito ISO 27001 dell’appendice A (equivalente al controllo ISO 27002) corrispondente.

I controlli sono suddivisi in tre aree: Information security, Prototype protection e Data protection.

I risultati degli obiettivi di controllo sono poi riepilogati nella scheda dei risultati (Result) che produrrà la valutazione complessiva e genererà un grafico Radar complessivo per evidenziare i livelli di maturità per i diversi punti di controllo, oltre a grafici radar per singola area.

Sono infine riportati alcuni esempi, anche di KPI significativi per monitorare l’adeguatezza della gestione della sicurezza delle informazioni in ambito automotive.

La copertura dei controlli ISO 27001 Appendice A – ISO 27002 è solo parziale, ma l’obiettivo è far raggiungere anche ad aziende medio-piccole che operano nel settore automotive un livello di maturità accettabile sulla sicurezza delle informazioni, senza pretendere di ottenere l’ardua ed onerosa certificazione ISO 27001.

Tuttavia, un’azienda del settore manifatturiero che opera in questo settore spesso non ha risorse IT interne adeguate per gestire un progetto di adeguamento al TISAX e l’infrastruttura tecnologica implementata potrebbe non fornire adeguate garanzie dal punto di vista della sicurezza.

Occorre dunque effettuare una sorta di gap analysis per capire qual è lo stato attuale dell’organizzazione rispetto alla sicurezza delle informazioni, per capire quali azioni occorre mettere in campo per poter raggiungere il livello di maturità richiesto e la conseguente Label TISAX. Credo che alcune organizzazioni, però, si attiveranno subito con l’iscrizione al TISAX per avviare il processo, senza sapere cosa li aspetta.

I costi per l’ottenimento di una determinata Label TISAX variano in funzione del numero dei siti e degli scopi, ma sono comunque ripartiti nei seguenti:

  • Costo di registrazione al TISAX (a partire da € 405)
  • Costi per l’audit da parte di un Audit Provider (dipendono dal livello di audit e sono ricorrenti per rinnovare la Label ogni 3 anni, ma non sono previsti audit di sorveglianza)
  • Costi per l’eventuale consulenza finalizzata al raggiungimento del livello di maturità richiesto
  • Costi del personale interno per seguire il progetto (personale IT, qualità, direzione, risorse umane, …)
  • Speseper adeguamento di hardware e software
  • Costi per eventuale assistenza sistemistica esterna.