IT vs OT vs Sicurezza: convivenza possibile?

Qualche settimana fa ho partecipato ad un interessante evento per CISO. Al di la dell’argomento (per altro estremamente interessante) la cosa simpatica è stata poter discorrere senza vincoli o freni. A tavola (e te pareva che non ne approfittavo per mangiare gratis 🙂 ) tra una chiacchiera ae l’altra si è iniziato a discorrere del difficile rapporto che corre tra il mondo OT ed IT, e di questi con la sicurezza dell’informazione nei suoi vari domini.

è sempre interessante sentire i vari punti di vista e le varie esperienze dalla voce dei protagonisti della nostra vita digitale, ed è interessante come spesso vi sia una comunità di esperienze che ci permette di definire lo stato (povero) della digitalizzazione in Italia.

IT vs OT il peccato originale.

Dall’osservatorio di un CISO è innegabile che OT e IT siano mondi diversi, che usano linguaggi diversi, con diverse esigenze e diverse metriche. Anche i tempi di vita degli oggetti che “vivono” nel mondo OT sono profondamente diversi da quelli che vivono nel mondo IT.

Criticità diverse, lingue diverse, metriche diverse non possono portare ne ad una facile convivenza ne a una facile comunicazione. Il risultato è una estrema diffidenza tra i due mondi, con l’OT che vede nel suo isolamento una forma di salvaguardia dall’invadenza dell’IT. Purtroppo, come già successe ai difensori dei mainframe, il mondo IT ha aumentato la sua pervasività nel mondo IT rompendo un “felice” isolamento che aveva reso i due mondi due cose diverse.

Il mantenimento di posizioni difensive da parte del mondo OT rispetto al mondo IT è comprensibile, ma occorre anche ammettere che il mondo OT si è sviluppato prima ma su esigenze e perimetri estremamente ristretti. L’accesso riluttante di componenti IT in questo mondo ha però aperto una finestra su una evidenza poco amata dall’OT: la senescenza di infrastrutture informatiche progettate senza un reale approccio di sicurezza by design e by default il cui cardine di sicurezza è sempre stato basato sull’isolamento e da un approccio security by oscurity.

Purtroppo questo approccio si è dimostrato, sempre più negli ultimi anni, insufficiente a garantire la sicurezza del mondo OT. Attacchi informatici verso strutture OT si sono moltiplicati con risultati economicamente importanti e non vi sono indicazioni che questo trend sia in diminuzione, anzi.

I criminali informatici non amano rinunziare a potenziali stream di monetizzazione una volta individuati, e la fragilità di molti sistemi OT sulle nuove tecniche di attacco in uso da queste organizzazioni è un canale interessante.

Questa vulnerabilità non è data solo dalla pervasività di sistemi IT nel campo OT, ma anche a fragilità specifiche di sistemi disegnati al di fuori di moderni parametri di sicurezza, non fosse altro per l’età di questi sistemi.

In questo dualismo però l’IT non è senza colpe, se la pervasività è un fatto, cosi come la apertura, la comprensione delle esigenze specifiche dell’OT non è altrettanto diffusa. Il risultato è che l’IT ha replicato, o cerca di replicare, i propri modelli operativi in un ambito differente.

Avendo i due mondi linguaggi diversi, metriche e spesso linee di riporto diverse la comunicazione risulta estremamente difficile e la resistenza tra i due mondi è ancora molto elevata

La sicurezza un ospite incomodo

Dall’osservatorio del ciso esiste però un comune nemico comune sia di OT che di IT, la cui pervasività è percepita come un peso e non come un fattore abilitante al business: la sicurezza dell’informazione.

Infatti la sicurezza o è vista come un sottoinsieme del mondo IT, cosa che alimenta la diffidenza del mondo OT nei sui confronti, o un elemento estraneo a tutto tondo da entrambe.

Ho già parlato in passato del fatto che la sicurezza della informazione è campo diverso dall’IT sia in termini di copertura (la cyber security è solo uno dei domini di riferimento) che in termini logici di indipendenza, controllato e controllore non possono coesistere e, in particolare, non può il controllore (la sicurezza) dipendere dal controllato per ovvi conflitti di interesse. la uscita della sicurezza dell’informazione dal dominio IT ha portato da parte dell’IT una “inimicizia” e la rottura di un rapporto nei confronti di chi si occupa di sicurezza, visto come un ulteriore peso, assieme a compliance.

Le ragioni della inimicizia di IT e OT nei confronti della sicurezza in realtà hanno ragioni più profonde: sistemi disegnati senza tener conto della sicurezza si vedono scoperti proprio nel loro punto di orgoglio, il design. Questo ha portato spesso l’IT (e inizia a vedersi il fenomeno anche nell’OT) a proiettare sulla sicurezza problematiche di design che non competono strettamente alla sicurezza.

Non è possibile pensare che la sicurezza dell’informazione, nei suoi vari domini, assolva a correttore di errori di design ed implementazione, processi incompleti o fallaci, digitalizzazione mal gestita e mal progettata. Eppure, spesso, questa è la richiesta che arriva alla sicurezza quella di coprire, con il proprio budget, errori di design e processo che sono, in realtà, attribuibili ad IT ed OT.

Come è facile immaginare questa “tensione” tra le diverse anime fa leva su questioni economiche e politiche interne all’organizzazione che non sono ne di facile ne di immediata risoluzione.

La percezione della sicurezza informatica come “ostacolo” alle attività di business e non di facilitatore (analogo discorso si può dire per le esigenze di compliance) in realtà è legato al fatto che sicurezza e compliance non sono considerate “ab initio” nel disegno delle infrastrutture ma chiamate ex post a coprire problematiche. Il concetto di disegnare infrastrutture e processi con “privacy e security” inserita “by design” e “by default” è ancora su carta più che reale. E il “business” inteso come la infrastruttura aziendale esterna a IT ed OT non ha competenze o comprensione delle problematiche se non a livello embrionale.

Esempi virtuosi, intendiamoci, ci sono ma sono eccezioni e non la norma. E quando ci sono l’azienda si ritrova un vantaggio competitivo in quanto aumenta la efficienza operativa e riduce i costi di gestione a fronte di un maggiore modesto costo iniziale.

Il prima, l’adesso e il domani

Se il futuro si può considerare da scrivere esiste il problema del pregresso e della gestione del corrente.

Sul passato si può intervenire solo in modalità reattiva, ovviamente, cercando di porre in atto processi e tecnologie che consentano la copertura di sicurezza delle aree più a rischio. Esistono esigenze varie da analizzare, in questo senso mi vengono in mente la microsegmentazione, il controllo degli accessi remoti da parte di operatori esterni, l’accesso remoto in modalità zero trusted, il controllo e monitoraggio di identità e attack pathway.

Per il presente si può pensare alla pianificazione della gestione delle risorse iniziando a definire metriche che aiutino le varie anime della azienda a condividere un approccio risk based che permetta di indirizzare le risorse in maniera più efficiente.

Per il futuro invece occorrerà prima o poi aprirsi ad una collaborazione tra i diversi stakeholder che condividano le esigenze e sappiano sviluppare tecnologie e processi in maniera efficace ed efficiente.

Esiste una soluzione?

La possibilità di riconciliare 6 anime (IT, OT, Sviluppo, Sicurezza, Compliance e Business) pur nella dinamica competitiva delle rispettive esigenze (il budget non è infinito e gli interessi vanno mediati) esiste quando si crea un ponte di comunicazione tra i diversi attori. Questa comunicazione è un elemento che non si crea “a tavolino” o “su carta, ma richiede la effettiva condivisione di attività operative e progetti. Far lavorare in gruppi di lavoro congiunto con obiettivi definiti e misurabili i vari elementi consente di definire una lingua comune che prelude a metriche compatibili e comprensibili.

Ovviamente questo richiede un commitment aziendale forte e una accettazione della sfida da parte dei vari stakeholder che devono accettare di essere “misurati” su questi obiettivi.

Modestamente mi permetterei di suggerire come primo possibile strumento il “cyber range” inteso come esercizio che consideri la attiva e fattiva partecipazione di tutti i vari stakeholders. Come esercizio di “sicurezza” la “simulazione realistica” di un attacco con le relative conseguenze permetterebbe ai vari soggetti di iniziare a capire le conseguenze delle scelte effettuate e di ripensare ad un futuro più ottimizzato. In questo senso la sicurezza potrebbe offrire alla azienda uno strumento di crescita e di creazione di ponti di comunicazione tra le sue diverse anime con la comprensione di cosa potrebbe accadere a causa di un problema di attacco alle infrastrutture (IT) in termini produttivi (OT) e quindi di business, all’immagine (MKTG e comunicazione) e alle ricadute economiche (finance) e legali.

Del resto il problema non è “se” qualcosa andrà male ma “quando”

Etica e DPO, un difficile rapporto?

Caso non comune ma sto ampliando un mio precedente articolo che, nei fatti, costituisce il corpo centrale di questo post.

Stimolato dai feedback sul mio ultimo post sul DPO

e stimolato dalla lettura di un post ed i commenti sagaci di Andrea Monti mi sono rimesso a pensare a certi ruoi aziendali.

Prima di proseguire nella lettura però dovete leggervi di Andrea Monti:

La scomoda sedia del Data Protection Officer, e perché gli avvocati non possono occuparla

La chiusura finale in particolare è interessante dove Andrea nota:

“…o il DPO fa finta di non vedere (e diventa concorrente in un illecito. Formale, ma pur sempre illecito) oppure mette il veto sull’iniziativa e, se l’azienda prosegue, non ha troppe alternative rispetto a segnalare il fatto all’autorità di protezione.”

…

“Quindi il DPO, anche se non segnala in autonomia una violazione normativa, può essere ascoltato dall’autorità (non solo) di protezione dei dati su queste circostanze. E dunque diventare un potenziale teste a carico (dell’accusa, in altri termini).”

…

Andrea Monti

E qui si apre un interessante punto .. ed è una esperienza che ho vissuto come manager in una multinazionale.

image taken from http://elaine.ie/2016/05/27/state-should-pay-whistleblowers/

Ad un certo punto, in una certa azienda, mi è stato detto che certi dati del personale sarebbero stati trasferiti fuori europa semplicemente perchè si, in barba al GDPR, e che non si doveva dire.

La questione mi ha subito dato fastidio per un motivo personale, tra quei dipendenti c’ero anche io. Erano i miei diritti che erano lesi, anche se i dati sarebbero stati trattati in maniera sicura.

Il punto era che invece che provare a discorrere con le autorità europee o trovare delle vie di mezzo percorribili si era scelto di non rispettare alcuni termini del GDPR. sapendo benissimo di violare un regolamento EU e sapendo benissimo di capire di tale regolamento poco o nulla.

Ancora più fastidioso era l’essere messo in mezzo ad un dilemma etico ed economico.

Durante la riunione ho obiettato che:

1. mi si chiedeva esplicitamente di mentire alle mie persone e colleghi
2. mi si chiedeva di non rispettare le leggi del mio paese
3. mi si chiedeva di rendermi complice di un illecito.

Lo scopo era vedere se ci fossero state reazione da parte dei miei colleghi. Aimè solo 2 CSO nord europei mi diedero ragione.

Ovviamente le mie obiezioni furono derubricate a “quello rompe sempre le scatole” il che mi ha portato, assieme ad altre considerazioni (alcune strettamente personali) alla decisione di non rinnovare la collaborazione con quella azienda e contestualmente segnalare la cosa all’authority dopo la fuoriuscita.

Ora la questione è dove deve, eticamente, cadere la mia lealtà in questi casi? Verso la azienda o verso, in questo caso, le leggi del mio paese?

La cosa non è semplice, ne parlavo in un altro post quando osservavo che considero mascalzoni quei CEO/Board che per puro calcolo matematico preferiscono il rischio della sanzione che l’implementazione corretta del GDPR.

La mia obiezione risiede nel fatto che il GDPR è norma per proteggere le libertà di noi cittadini e residenti EU, non rispettarlo quindi implicitamente mette a rischio le mie libertà individuali.

Nel mio caso la mia lealtà va alla protezione dei miei concittadini e al rispetto della legge, anche se parliamo di un illecito amministrativo o formale la questione non è banale.

Un manager potrebbe allinearsi alla richiesta aziendale, potrebbe non allinearsi e prenderne le conseguenze (lo ho vissuto) o fare una via di mezzo, ad esempio denunciare il comportamento in via anonima alla autorità competente dopo aver, almeno, provato a obiettare sul comportamento.

Ancora più delicato, in questo caso, è il dipendente non manager, vaso di coccio.

L’istituto del whistleblowing potrebbe in qualche modo “proteggere” ma diciamocelo se si viene a sapere chi ha cantato…

Il problema etico rimane, in mancanza di obblighi formali a comunicare alla opportuna authority un eventuale illecito.

Il caso del DPO è anche più critico, visto che istituzionalmente ha obblighi chiari in merito al rispetto del GDPR che sono di indirizzo, formazione e controllo. Il punto è che in assenza di segnalazione alla autorità della non aderenza al regolamento il DPO non esercita la sua funzione di controllo.

Supponiamo per un momento che il DPO presenti le sue valutazioni di rischio su di un processo al board dando una valutazione che presenta un piccolo rischio residuale come accettabile, e che il board rifiuti le conclusioni definendo un rischio accettabile più alto. Ora posso comprendere che questo entri in un ambito di contrattazione tra le parti, se il rischio residuale è troppo alto il DPO deve comunicare con l’authority per la valutazione.

Ora il quanto alto sia è il punto dirimente, se il DPO considera il rischio accettato dal board troppo alto fa bene a comunicare al garante la cosa per un parere?

E se non lo fa e accade un incidente? E se non lo fa e viene una ispezione che giunge alle conclusioni del DPO e trova scritto nelle minute dei meeting del board quali erano le posizioni in merito?

Situazione scivolosa persino senza che vi sia un illecito formale come indicato nel post di andrea che vi invitavo a leggere inizialmente.

Analogo discorso potremmo farlo per il CISO che non ritenga adatti i meccanismi di protezione messi in atto dall’azienda ed in caso di breach incalzato dalle autorità esprima le sue perplessità (possibilmente scritte in qualche documento ufficiale).

Fa bene?

Fa male?

La questione delle responsabilità è quindi delicata, si prenda il caso INPS, dove alla fine tutto è finito a tarallucci e vino. Possibile che internamente nessuno ha sentito il bisogno di denunciare una situazione che ha portato al disastro? Non voglio credere che il livello di incompetenza sia tale per cui nessuno se ne potesse rendere conto.

Se è vero che vi sono vincoli di riservatezza, fino a dove questi si possono spingere?

Come Whistleblower o per ruolo la questione è non semplice, anche perchè vi sono altri termini da considerare tipo:

1. la necessità di uno stipendio
2. la possibilità di trovare lavoro

Pensate, ad esempio, un DPO che denuncia al garante una non conformità della propria azienda. Tra lui ed il CEO difficilmente sarà il CEO ad essere licenziato.

Ma se il DPO perde il lavoro a seguito della cosa (e i metodi ci sono per farlo) e la cosa si sa (questo è un mondo piccolo)…quante possibilità avrà di trovare una nuova collocazione?

Pensare ad una indipendenza che sia reale diventa estremamente difficile soprattutto in una situazione economica dove la ricollocazione non è ne facile ne garantita.

Meditiamo, Meditiamo

Etica e DPO, un difficile rapporto?

Caso non comune ma sto ampliando un mio precedente articolo che, nei fatti, costituisce il corpo centrale di questo post.

Stimolato dai feedback sul mio ultimo post sul DPO

e stimolato dalla lettura di un post ed i commenti sagaci di Andrea Monti mi sono rimesso a pensare a certi ruoi aziendali.

Prima di proseguire nella lettura però dovete leggervi di Andrea Monti:

La scomoda sedia del Data Protection Officer, e perché gli avvocati non possono occuparla

La chiusura finale in particolare è interessante dove Andrea nota:

“…o il DPO fa finta di non vedere (e diventa concorrente in un illecito. Formale, ma pur sempre illecito) oppure mette il veto sull’iniziativa e, se l’azienda prosegue, non ha troppe alternative rispetto a segnalare il fatto all’autorità di protezione.”

…

“Quindi il DPO, anche se non segnala in autonomia una violazione normativa, può essere ascoltato dall’autorità (non solo) di protezione dei dati su queste circostanze. E dunque diventare un potenziale teste a carico (dell’accusa, in altri termini).”

…

Andrea Monti

E qui si apre un interessante punto .. ed è una esperienza che ho vissuto come manager in una multinazionale.

image taken from http://elaine.ie/2016/05/27/state-should-pay-whistleblowers/

Ad un certo punto, in una certa azienda, mi è stato detto che certi dati del personale sarebbero stati trasferiti fuori europa semplicemente perchè si, in barba al GDPR, e che non si doveva dire.

La questione mi ha subito dato fastidio per un motivo personale, tra quei dipendenti c’ero anche io. Erano i miei diritti che erano lesi, anche se i dati sarebbero stati trattati in maniera sicura.

Il punto era che invece che provare a discorrere con le autorità europee o trovare delle vie di mezzo percorribili si era scelto di non rispettare alcuni termini del GDPR. sapendo benissimo di violare un regolamento EU e sapendo benissimo di capire di tale regolamento poco o nulla.

Ancora più fastidioso era l’essere messo in mezzo ad un dilemma etico ed economico.

Durante la riunione ho obiettato che:

1. mi si chiedeva esplicitamente di mentire alle mie persone e colleghi
2. mi si chiedeva di non rispettare le leggi del mio paese
3. mi si chiedeva di rendermi complice di un illecito.

Lo scopo era vedere se ci fossero state reazione da parte dei miei colleghi. Aimè solo 2 CSO nord europei mi diedero ragione.

Ovviamente le mie obiezioni furono derubricate a “quello rompe sempre le scatole” il che mi ha portato, assieme ad altre considerazioni (alcune strettamente personali) alla decisione di non rinnovare la collaborazione con quella azienda e contestualmente segnalare la cosa all’authority dopo la fuoriuscita.

Ora la questione è dove deve, eticamente, cadere la mia lealtà in questi casi? Verso la azienda o verso, in questo caso, le leggi del mio paese?

La cosa non è semplice, ne parlavo in un altro post quando osservavo che considero mascalzoni quei CEO/Board che per puro calcolo matematico preferiscono il rischio della sanzione che l’implementazione corretta del GDPR.

La mia obiezione risiede nel fatto che il GDPR è norma per proteggere le libertà di noi cittadini e residenti EU, non rispettarlo quindi implicitamente mette a rischio le mie libertà individuali.

Nel mio caso la mia lealtà va alla protezione dei miei concittadini e al rispetto della legge, anche se parliamo di un illecito amministrativo o formale la questione non è banale.

Un manager potrebbe allinearsi alla richiesta aziendale, potrebbe non allinearsi e prenderne le conseguenze (lo ho vissuto) o fare una via di mezzo, ad esempio denunciare il comportamento in via anonima alla autorità competente dopo aver, almeno, provato a obiettare sul comportamento.

Ancora più delicato, in questo caso, è il dipendente non manager, vaso di coccio.

L’istituto del whistleblowing potrebbe in qualche modo “proteggere” ma diciamocelo se si viene a sapere chi ha cantato…

Il problema etico rimane, in mancanza di obblighi formali a comunicare alla opportuna authority un eventuale illecito.

Il caso del DPO è anche più critico, visto che istituzionalmente ha obblighi chiari in merito al rispetto del GDPR che sono di indirizzo, formazione e controllo. Il punto è che in assenza di segnalazione alla autorità della non aderenza al regolamento il DPO non esercita la sua funzione di controllo.

Supponiamo per un momento che il DPO presenti le sue valutazioni di rischio su di un processo al board dando una valutazione che presenta un piccolo rischio residuale come accettabile, e che il board rifiuti le conclusioni definendo un rischio accettabile più alto. Ora posso comprendere che questo entri in un ambito di contrattazione tra le parti, se il rischio residuale è troppo alto il DPO deve comunicare con l’authority per la valutazione.

Ora il quanto alto sia è il punto dirimente, se il DPO considera il rischio accettato dal board troppo alto fa bene a comunicare al garante la cosa per un parere?

E se non lo fa e accade un incidente? E se non lo fa e viene una ispezione che giunge alle conclusioni del DPO e trova scritto nelle minute dei meeting del board quali erano le posizioni in merito?

Situazione scivolosa persino senza che vi sia un illecito formale come indicato nel post di andrea che vi invitavo a leggere inizialmente.

Analogo discorso potremmo farlo per il CISO che non ritenga adatti i meccanismi di protezione messi in atto dall’azienda ed in caso di breach incalzato dalle autorità esprima le sue perplessità (possibilmente scritte in qualche documento ufficiale).

Fa bene?

Fa male?

La questione delle responsabilità è quindi delicata, si prenda il caso INPS, dove alla fine tutto è finito a tarallucci e vino. Possibile che internamente nessuno ha sentito il bisogno di denunciare una situazione che ha portato al disastro? Non voglio credere che il livello di incompetenza sia tale per cui nessuno se ne potesse rendere conto.

Se è vero che vi sono vincoli di riservatezza, fino a dove questi si possono spingere?

Come Whistleblower o per ruolo la questione è non semplice, anche perchè vi sono altri termini da considerare tipo:

1. la necessità di uno stipendio
2. la possibilità di trovare lavoro

Pensate, ad esempio, un DPO che denuncia al garante una non conformità della propria azienda. Tra lui ed il CEO difficilmente sarà il CEO ad essere licenziato.

Ma se il DPO perde il lavoro a seguito della cosa (e i metodi ci sono per farlo) e la cosa si sa (questo è un mondo piccolo)…quante possibilità avrà di trovare una nuova collocazione?

Pensare ad una indipendenza che sia reale diventa estremamente difficile soprattutto in una situazione economica dove la ricollocazione non è ne facile ne garantita.

Meditiamo, Meditiamo

Chi va con lo zoppo impara a DPOare

Caso non comune ma sto ampliando un mio precedente articolo che, nei fatti, costituisce il corpo centrale di questo post.

Stimolato dai feedback sul mio ultimo post sul DPO

e stimolato dalla lettura di un post ed i commenti sagaci di Andrea Monti mi sono rimesso a pensare a certi ruoi aziendali.

Prima di proseguire nella lettura però dovete leggervi di Andrea Monti:

La scomoda sedia del Data Protection Officer, e perché gli avvocati non possono occuparla

La chiusura finale in particolare è interessante dove Andrea nota:

“…o il DPO fa finta di non vedere (e diventa concorrente in un illecito. Formale, ma pur sempre illecito) oppure mette il veto sull’iniziativa e, se l’azienda prosegue, non ha troppe alternative rispetto a segnalare il fatto all’autorità di protezione.”

…

“Quindi il DPO, anche se non segnala in autonomia una violazione normativa, può essere ascoltato dall’autorità (non solo) di protezione dei dati su queste circostanze. E dunque diventare un potenziale teste a carico (dell’accusa, in altri termini).”

…

Andrea Monti

E qui si apre un interessante punto .. ed è una esperienza che ho vissuto come manager in una multinazionale.

image taken from http://elaine.ie/2016/05/27/state-should-pay-whistleblowers/

Ad un certo punto, in una certa azienda, mi è stato detto che certi dati del personale sarebbero stati trasferiti fuori europa semplicemente perchè si, in barba al GDPR, e che non si doveva dire.

La questione mi ha subito dato fastidio per un motivo personale, tra quei dipendenti c’ero anche io. Erano i miei diritti che erano lesi, anche se i dati sarebbero stati trattati in maniera sicura.

Il punto era che invece che provare a discorrere con le autorità europee o trovare delle vie di mezzo percorribili si era scelto di non rispettare alcuni termini del GDPR. sapendo benissimo di violare un regolamento EU e sapendo benissimo di capire di tale regolamento poco o nulla.

Ancora più fastidioso era l’essere messo in mezzo ad un dilemma etico ed economico.

Durante la riunione ho obiettato che:

1. mi si chiedeva esplicitamente di mentire alle mie persone e colleghi
2. mi si chiedeva di non rispettare le leggi del mio paese
3. mi si chiedeva di rendermi complice di un illecito.

Lo scopo era vedere se ci fossero state reazione da parte dei miei colleghi. Aimè solo 2 CSO nord europei mi diedero ragione.

Ovviamente le mie obiezioni furono derubricate a “quello rompe sempre le scatole” il che mi ha portato, assieme ad altre considerazioni (alcune strettamente personali) alla decisione di non rinnovare la collaborazione con quella azienda e contestualmente segnalare la cosa all’authority dopo la fuoriuscita.

Ora la questione è dove deve, eticamente, cadere la mia lealtà in questi casi? Verso la azienda o verso, in questo caso, le leggi del mio paese?

La cosa non è semplice, ne parlavo in un altro post quando osservavo che considero mascalzoni quei CEO/Board che per puro calcolo matematico preferiscono il rischio della sanzione che l’implementazione corretta del GDPR.

La mia obiezione risiede nel fatto che il GDPR è norma per proteggere le libertà di noi cittadini e residenti EU, non rispettarlo quindi implicitamente mette a rischio le mie libertà individuali.

Nel mio caso la mia lealtà va alla protezione dei miei concittadini e al rispetto della legge, anche se parliamo di un illecito amministrativo o formale la questione non è banale.

Un manager potrebbe allinearsi alla richiesta aziendale, potrebbe non allinearsi e prenderne le conseguenze (lo ho vissuto) o fare una via di mezzo, ad esempio denunciare il comportamento in via anonima alla autorità competente dopo aver, almeno, provato a obiettare sul comportamento.

Ancora più delicato, in questo caso, è il dipendente non manager, vaso di coccio.

L’istituto del whistleblowing potrebbe in qualche modo “proteggere” ma diciamocelo se si viene a sapere chi ha cantato…

Il problema etico rimane, in mancanza di obblighi formali a comunicare alla opportuna authority un eventuale illecito.

Il caso del DPO è anche più critico, visto che istituzionalmente ha obblighi chiari in merito al rispetto del GDPR che sono di indirizzo, formazione e controllo. Il punto è che in assenza di segnalazione alla autorità della non aderenza al regolamento il DPO non esercita la sua funzione di controllo.

Supponiamo per un momento che il DPO presenti le sue valutazioni di rischio su di un processo al board dando una valutazione che presenta un piccolo rischio residuale come accettabile, e che il board rifiuti le conclusioni definendo un rischio accettabile più alto. Ora posso comprendere che questo entri in un ambito di contrattazione tra le parti, se il rischio residuale è troppo alto il DPO deve comunicare con l’authority per la valutazione.

Ora il quanto alto sia è il punto dirimente, se il DPO considera il rischio accettato dal board troppo alto fa bene a comunicare al garante la cosa per un parere?

E se non lo fa e accade un incidente? E se non lo fa e viene una ispezione che giunge alle conclusioni del DPO e trova scritto nelle minute dei meeting del board quali erano le posizioni in merito?

Situazione scivolosa persino senza che vi sia un illecito formale come indicato nel post di andrea che vi invitavo a leggere inizialmente.

Analogo discorso potremmo farlo per il CISO che non ritenga adatti i meccanismi di protezione messi in atto dall’azienda ed in caso di breach incalzato dalle autorità esprima le sue perplessità (possibilmente scritte in qualche documento ufficiale).

Fa bene?

Fa male?

La questione delle responsabilità è quindi delicata, si prenda il caso INPS, dove alla fine tutto è finito a tarallucci e vino. Possibile che internamente nessuno ha sentito il bisogno di denunciare una situazione che ha portato al disastro? Non voglio credere che il livello di incompetenza sia tale per cui nessuno se ne potesse rendere conto.

Se è vero che vi sono vincoli di riservatezza, fino a dove questi si possono spingere?

Come Whistleblower o per ruolo la questione è non semplice, anche perchè vi sono altri termini da considerare tipo:

1. la necessità di uno stipendio
2. la possibilità di trovare lavoro

Pensate, ad esempio, un DPO che denuncia al garante una non conformità della propria azienda. Tra lui ed il CEO difficilmente sarà il CEO ad essere licenziato.

Ma se il DPO perde il lavoro a seguito della cosa (e i metodi ci sono per farlo) e la cosa si sa (questo è un mondo piccolo)…quante possibilità avrà di trovare una nuova collocazione?

Pensare ad una indipendenza che sia reale diventa estremamente difficile soprattutto in una situazione economica dove la ricollocazione non è ne facile ne garantita.

Meditiamo, Meditiamo

Chi va con lo zoppo impara a DPOare

Caso non comune ma sto ampliando un mio precedente articolo che, nei fatti, costituisce il corpo centrale di questo post.

Stimolato dai feedback sul mio ultimo post sul DPO

e stimolato dalla lettura di un post ed i commenti sagaci di Andrea Monti mi sono rimesso a pensare a certi ruoi aziendali.

Prima di proseguire nella lettura però dovete leggervi di Andrea Monti:

La scomoda sedia del Data Protection Officer, e perché gli avvocati non possono occuparla

La chiusura finale in particolare è interessante dove Andrea nota:

“…o il DPO fa finta di non vedere (e diventa concorrente in un illecito. Formale, ma pur sempre illecito) oppure mette il veto sull’iniziativa e, se l’azienda prosegue, non ha troppe alternative rispetto a segnalare il fatto all’autorità di protezione.”

…

“Quindi il DPO, anche se non segnala in autonomia una violazione normativa, può essere ascoltato dall’autorità (non solo) di protezione dei dati su queste circostanze. E dunque diventare un potenziale teste a carico (dell’accusa, in altri termini).”

…

Andrea Monti

E qui si apre un interessante punto .. ed è una esperienza che ho vissuto come manager in una multinazionale.

image taken from http://elaine.ie/2016/05/27/state-should-pay-whistleblowers/

Ad un certo punto, in una certa azienda, mi è stato detto che certi dati del personale sarebbero stati trasferiti fuori europa semplicemente perchè si, in barba al GDPR, e che non si doveva dire.

La questione mi ha subito dato fastidio per un motivo personale, tra quei dipendenti c’ero anche io. Erano i miei diritti che erano lesi, anche se i dati sarebbero stati trattati in maniera sicura.

Il punto era che invece che provare a discorrere con le autorità europee o trovare delle vie di mezzo percorribili si era scelto di non rispettare alcuni termini del GDPR. sapendo benissimo di violare un regolamento EU e sapendo benissimo di capire di tale regolamento poco o nulla.

Ancora più fastidioso era l’essere messo in mezzo ad un dilemma etico ed economico.

Durante la riunione ho obiettato che:

1. mi si chiedeva esplicitamente di mentire alle mie persone e colleghi
2. mi si chiedeva di non rispettare le leggi del mio paese
3. mi si chiedeva di rendermi complice di un illecito.

Lo scopo era vedere se ci fossero state reazione da parte dei miei colleghi. Aimè solo 2 CSO nord europei mi diedero ragione.

Ovviamente le mie obiezioni furono derubricate a “quello rompe sempre le scatole” il che mi ha portato, assieme ad altre considerazioni (alcune strettamente personali) alla decisione di non rinnovare la collaborazione con quella azienda e contestualmente segnalare la cosa all’authority dopo la fuoriuscita.

Ora la questione è dove deve, eticamente, cadere la mia lealtà in questi casi? Verso la azienda o verso, in questo caso, le leggi del mio paese?

La cosa non è semplice, ne parlavo in un altro post quando osservavo che considero mascalzoni quei CEO/Board che per puro calcolo matematico preferiscono il rischio della sanzione che l’implementazione corretta del GDPR.

La mia obiezione risiede nel fatto che il GDPR è norma per proteggere le libertà di noi cittadini e residenti EU, non rispettarlo quindi implicitamente mette a rischio le mie libertà individuali.

Nel mio caso la mia lealtà va alla protezione dei miei concittadini e al rispetto della legge, anche se parliamo di un illecito amministrativo o formale la questione non è banale.

Un manager potrebbe allinearsi alla richiesta aziendale, potrebbe non allinearsi e prenderne le conseguenze (lo ho vissuto) o fare una via di mezzo, ad esempio denunciare il comportamento in via anonima alla autorità competente dopo aver, almeno, provato a obiettare sul comportamento.

Ancora più delicato, in questo caso, è il dipendente non manager, vaso di coccio.

L’istituto del whistleblowing potrebbe in qualche modo “proteggere” ma diciamocelo se si viene a sapere chi ha cantato…

Il problema etico rimane, in mancanza di obblighi formali a comunicare alla opportuna authority un eventuale illecito.

Il caso del DPO è anche più critico, visto che istituzionalmente ha obblighi chiari in merito al rispetto del GDPR che sono di indirizzo, formazione e controllo. Il punto è che in assenza di segnalazione alla autorità della non aderenza al regolamento il DPO non esercita la sua funzione di controllo.

Supponiamo per un momento che il DPO presenti le sue valutazioni di rischio su di un processo al board dando una valutazione che presenta un piccolo rischio residuale come accettabile, e che il board rifiuti le conclusioni definendo un rischio accettabile più alto. Ora posso comprendere che questo entri in un ambito di contrattazione tra le parti, se il rischio residuale è troppo alto il DPO deve comunicare con l’authority per la valutazione.

Ora il quanto alto sia è il punto dirimente, se il DPO considera il rischio accettato dal board troppo alto fa bene a comunicare al garante la cosa per un parere?

E se non lo fa e accade un incidente? E se non lo fa e viene una ispezione che giunge alle conclusioni del DPO e trova scritto nelle minute dei meeting del board quali erano le posizioni in merito?

Situazione scivolosa persino senza che vi sia un illecito formale come indicato nel post di andrea che vi invitavo a leggere inizialmente.

Analogo discorso potremmo farlo per il CISO che non ritenga adatti i meccanismi di protezione messi in atto dall’azienda ed in caso di breach incalzato dalle autorità esprima le sue perplessità (possibilmente scritte in qualche documento ufficiale).

Fa bene?

Fa male?

La questione delle responsabilità è quindi delicata, si prenda il caso INPS, dove alla fine tutto è finito a tarallucci e vino. Possibile che internamente nessuno ha sentito il bisogno di denunciare una situazione che ha portato al disastro? Non voglio credere che il livello di incompetenza sia tale per cui nessuno se ne potesse rendere conto.

Se è vero che vi sono vincoli di riservatezza, fino a dove questi si possono spingere?

Come Whistleblower o per ruolo la questione è non semplice, anche perchè vi sono altri termini da considerare tipo:

1. la necessità di uno stipendio
2. la possibilità di trovare lavoro

Pensate, ad esempio, un DPO che denuncia al garante una non conformità della propria azienda. Tra lui ed il CEO difficilmente sarà il CEO ad essere licenziato.

Ma se il DPO perde il lavoro a seguito della cosa (e i metodi ci sono per farlo) e la cosa si sa (questo è un mondo piccolo)…quante possibilità avrà di trovare una nuova collocazione?

Pensare ad una indipendenza che sia reale diventa estremamente difficile soprattutto in una situazione economica dove la ricollocazione non è ne facile ne garantita.

Meditiamo, Meditiamo

Caro CISO, ti suggerisco di parlare d'affari con il tuo CdA, evita tecnicismi.

Caro consiglio di amministrazione e caro CISO

Penso che dovremmo sempre considerare il nostro lavoro come una parte del business. Abbiamo finalmente iniziato a prendere in considerazione la sicurezza informatica e la protezione dei dati come un problema serio, ma ora la domanda è come valutare un rischio nei nostri piani di analisi e di business…

Usualmente la documentazione e le relazioni per l’analisi di rischio, presentati nelle aziende (se e quando vengono presentati ovvio) si limitano, per la maggior parte, all’uso di valori generici (rischio alto, medio, basso), ma non sembra che si usi specificare qualsiasi metrica. Senza metrica è difficile fare una valutazione che abbia senso e parimenti impossible fare confronti;

così alla eventuale questione sollevata da un qualsiasi membro del Consiglio:

“il rischio XYZ è grave come il rischio ABC?”

non si può avere una risposta credibile se non sulla “percezione”, che è soggettiva, se non supportata da fatti…

Costruire metriche di sicurezza è un lavoro complesso e sono oggetto di studio, interpretazione e discussione anche in sede universitaria tutt’oggi, ma nonostante questa complessità possiamo semplificare l’approccio per fare analisi di sicurezza in qualche modo comprensibili e credibili.

Prima di tutto, per rispondere alla domanda presentata dal membro del CdA è necessario avere un quadro comune e condiviso di valutazione, che includa metriche di facile lettura per permettere di fare confronti comprensibili anche ai non esperti di cyber sicurezza, caratteristica comune alla maggior parte dei membri del Consiglio di Amministrazione che, però, devono prendere decisioni basate su tali dati.

Lo so, questo è qualcosa che va oltre le attività di un Cyber e Information Security Officer, questo richiede che l’intera azienda a iniziare a pensare alla cyber sicurezza e alle risorse digitali in campo ma, a meno che l’approccio sia quello di procedere in modo reattivo in caso di problemi (tipo: “mi sono beccato il ransomware…e adesso? che faccio? quanto mi costa? …”), indicazioni da parte del CISO sono indispensabili per delineare il quadro e aiutare nella definizione delle metriche.

Haimè l’analisi del rischio per la sicurezza informatica è tutto tranne che semplice, soprattutto se le analisi sono relative all’impatto aziendale di un incidente, poiché è richiesta tanto la comprensione del problema di sicurezza dal punto di vista cyber così come la comprensione delle ricadute sul business in cui il rischio è analizzato.

Ci sono due aspetti principali che hanno bisogno di metriche leggibili:

1. Valutazione del rischio
2. Conseguenze di rischio

Il primo elemento viene utilizzato per definire quanto “rischioso” è qualcosa.

La misura del rischio richiede, per semplificare una questione complessa, di essere in grado di valutare la probabilità che qualcosa accada, l’entità del danno e il costo per aggiustare le cose.

La dimensione economica dei danni e dei costi occorrenti per sistemare le cose sono legati alle conseguenze identificate per uno specifico rischio. Queste sono, fondamentalmente, le metriche che possono essere utilizzate in una riunione col consiglio di amministrazione per descrivere il rischio in termini comprensibili ad un pubblico non-consapevole in termini di cyber sicurezza.

Non voglio qui entrare nel dettaglio della valutazione del rischio, sono sicuro che come CISO avrai una profonda conoscenza e comprensione del problema e non voglio annoiarti con le mie riflessioni al riguardo, ma permettimi di osservare come non ci sia, apparentemente, ancora un quadro comune di valutazione diffuso tra gruppi e Business Unit della tua azienda. Trovo difficile credere che la percezione del rischio del dipartimento HR sia analogo a quello del dipartimento IT o del Marketing, o della produzione o vendita,  se cosi fosse probabilmente non staresti leggendo questo articolo mentre io starei quasi sicuramente leggendo il tuo.

La valutazione del rischio è una attività prevalentemente tecnica: la comprensione delle tecniche di attacco e difesa, le risorse necessarie sono ambiti dove CISO e management IT dovrebbero essere in grado di dare risposte sensate e credibili. Discorso diverso invece è l’analisi dell’impatto dell’incidente sul business. Questo impatto richiede sia la comprensione di cosa avvenga tecnicamente, almeno a grandi linee, ma anche la comprensione di quali siano i meccanismi legati al business che sono danneggiati dall’incidente. Va da se che le metriche da usarsi devono essere comprensibili al business, altrimenti sono inutili.

Le conseguenze di un incidente ed il suo livello di rischio sono ovviamente correlate cosi come sono correlate le dimensioni che definiscono il problema, l’obiettivo è capire, nella ipotesi che si verifichi un incidente di sicurezza, quali possano essere le misure che consentono alla vostra azienda di descriverlo e effettuare un confronto con un altro evento per determinare, ad esempio, priorità di intervento e di budget.

Avrebbe senso, dal mio punto di vista, presentare qualsiasi analisi di rischio al consiglio di amministrazione e altri manager e dirigenti in questi termini:

1) costo monetario in termini di perdita di ricavi

2) costo monetario in termini di costi effettivi sostenuti o da sostenere

3) impatto sulla penetrazione del mercato

4) impatto sulla percezione del marchio

Utilizzare queste 4 dimensioni permette di confrontare un incidente “ABC” ad un avvenimento “XYZ” e rispondere in qualche modo alla domanda del membro del consiglio fatta prima e, inoltre, a dare una metrica per capire dove e perché investire in un’area invece in un’altra.

Permettimi di descrivere rapidamente i 4 punti.

1) costo monetario in termini di perdita di ricavi

Si tratta di una dimensione che può essere facilmente percepita dai responsabili commerciali e finanziari. Comporta l’essere in grado di stimare quanta attività di vendita sarà influenzata dall’incidente. Il lasso di tempo preso in considerazione è, ovviamente, una delle criticità chiave, dal momento che gli eventi possono avere un effetto diverso in termini di intervallo di tempo breve, medio e lungo termine.

La valutazione può essere presentata sia in termini di importo netto di denaro o % rispetto al bilancio. Entrambi sono utili per capire l’impatto dell’evento.

2) costo monetario in termini di costi effettivi sostenuti o da sostenere

Questo significa mettere in considerazione tutti i costi vivi relazionati all’incidente come multe, questioni legali, interventi di sostituzione o aggiornamento del parco HWSW , persone che lavorano sull’incidente e così via. È importante separare i costi collegati all’incidente, dalle perdite economiche collegate all’incidente stesso, perché la natura degli interventi correttivi è estremamente diversa nei diversi casi.

3) impatto sulla penetrazione del mercato

Si tratta di una metrica che ha senso per un fornitore che sta cercando di espandere la sua presenza nel mercato come la tua azienda sta probabilmente cercando di fare. È strettamente connesso ai ricavi diretti, ma anche con le aspettative di crescita. Ciò può essere rappresentato come una % della quota di mercato.

4) impatto sulla percezione del marchio

Questo ultimo elemento è il più difficile da misurare, ma dato che dipende dalla metrica utilizzata per valutare il valore del Brand all’interno dell’azienda, dal momento che non mi è stato detto quali parametri vengono utilizzati qui posso solo suggerirti di presentare la variazione % correlata al valore stimato prima dell’incidente.

Per quello che so se questo non è stato fatto prima potrebbe essere qualcosa di intelligente da presentare in un futuro Business Plan o un’attività per il Cyber e Information Security Office da effettuarsi quest’anno in maniera da essere in grado, in futuro, di fare presentazioni e proiezioni che abbiano un senso.

Con quei 4 punti sarebbe possibile per entrambi (tu ed il consiglio di amministrazione):

a) fare confronto tra rischi

e

b) fornire al Consiglio una serie di elementi che possono essere oggettivamente utilizzati per prendere decisioni strategiche e di indirizzo.

Prendiamo come esempio la analisi dei rischi concernenti ad una violazione delle normative sulla privacy europea, il famigerato GDPR

L’approccio che ti ho proposto consentirebbe di presentare nel BP un insieme di dati comprensibili ed adatti a giustificare le spese e gli investimenti per ogni tipologia di rischio presentato; qualcosa di simile alla seguente tabella:

Permettimi di spiegare la tabella, considera naturalmente che i valori sono fittizi e il lasso di tempo considerato può essere regolato in base alla tua realtà.

Non conformità al GDPR

1) violazione di dati personali del cliente: intestazioni di colonne

Impatto a breve termine (1-3 mesi)

È cosa succedere immediatamente dopo il problema, quando è necessario intraprendere le operazioni necessarie per riprendere la operatività. Se hai un Emergency Response Team (dovresti) va computato qui…

Impatto di medio termine (3 mesi – un anno)

Permettimi di essere onesto, se è un problema di minore entità può accadere che le cose si possano risolvere rapidamente, ma se il problema è più grande, come ad esempio il tuo database di marketing esposto al pubblico su internet, devi iniziare a considerare anche le spese legali, multe e l’impatto sul tuo mercato…

Impatto a lungo termine (1-3 anni)

Le cose hanno un impatto anche dopo il tuo Business Plan, la vita non è limitata alla tua arbitraria finestra temporale, il business non si limita a finestre temporali limitate, tu dovresti essere in grado di fare previsione e analisi di più lungo periodo, oltre alla visione, orrore, trimestrale o annuale. È una esigenza comune in qualsiasi attività commerciale, e qui è o stesso.

2) violazione dei dati personali cliente: intestazioni di riga

Perdita di entrate

Questa è la perdita di gettito, legata all’incidente, che si dovrà affrontare rispetto le vostre aspettative di bilancio.

Costi diretti

Questo contiene ciò che si deve pagare per causa diretta  dell’incidente ad esempio:

• Sostituzione, aggiornamento, implementazione soluzioni HWSW
• Multe
• Stima dell’eventuale costo legato alla richiesta di risarcimento di eventuali parti lese
• riscatto pagato (ad esempio in caso di ransomware)
• aumento di costo di eventuali polizze assicurative sulla cyber security
• costi di fermo porduzione
• persone che lavorano sulla questione per risolvere il problema (eventuali analisti forensi, esperti informatici, avvocati…)
• …

Impatto sulla penetrazione del mercato

Questo è il posto dove mettere come l’incidente danneggerà il vostro business in termini della vostra presenza sul mercato (quote di mercato) e le prospettive future.

Impatto sulla percezione del marchio

Questo indica quanto la tua credibilità risentirà dell’incidente

Con questo tipo di matrice sarebbe facile fare valutazioni corrette e confronti sensati. Non so se questo è, al momento, qualcosa che può essere fatto con gli attuali strumenti di analisi in tuo possesso, ma sarebbe un elemento utile da mettere in un BP e per un futuro corretto approccio alla valutazione del rischio per la sicurezza informatica (cyber security, data seurity e data privacy).

ciao

Antonio

Caro CISO, ti suggerisco di parlare d'affari con il tuo CdA, evita tecnicismi.

Caro consiglio di amministrazione e caro CISO

Penso che dovremmo sempre considerare il nostro lavoro come una parte del business. Abbiamo finalmente iniziato a prendere in considerazione la sicurezza informatica e la protezione dei dati come un problema serio, ma ora la domanda è come valutare un rischio nei nostri piani di analisi e di business…

Usualmente la documentazione e le relazioni per l’analisi di rischio, presentati nelle aziende (se e quando vengono presentati ovvio) si limitano, per la maggior parte, all’uso di valori generici (rischio alto, medio, basso), ma non sembra che si usi specificare qualsiasi metrica. Senza metrica è difficile fare una valutazione che abbia senso e parimenti impossible fare confronti;

così alla eventuale questione sollevata da un qualsiasi membro del Consiglio:

“il rischio XYZ è grave come il rischio ABC?”

non si può avere una risposta credibile se non sulla “percezione”, che è soggettiva, se non supportata da fatti…

Costruire metriche di sicurezza è un lavoro complesso e sono oggetto di studio, interpretazione e discussione anche in sede universitaria tutt’oggi, ma nonostante questa complessità possiamo semplificare l’approccio per fare analisi di sicurezza in qualche modo comprensibili e credibili.

Prima di tutto, per rispondere alla domanda presentata dal membro del CdA è necessario avere un quadro comune e condiviso di valutazione, che includa metriche di facile lettura per permettere di fare confronti comprensibili anche ai non esperti di cyber sicurezza, caratteristica comune alla maggior parte dei membri del Consiglio di Amministrazione che, però, devono prendere decisioni basate su tali dati.

Lo so, questo è qualcosa che va oltre le attività di un Cyber e Information Security Officer, questo richiede che l’intera azienda a iniziare a pensare alla cyber sicurezza e alle risorse digitali in campo ma, a meno che l’approccio sia quello di procedere in modo reattivo in caso di problemi (tipo: “mi sono beccato il ransomware…e adesso? che faccio? quanto mi costa? …”), indicazioni da parte del CISO sono indispensabili per delineare il quadro e aiutare nella definizione delle metriche.

Haimè l’analisi del rischio per la sicurezza informatica è tutto tranne che semplice, soprattutto se le analisi sono relative all’impatto aziendale di un incidente, poiché è richiesta tanto la comprensione del problema di sicurezza dal punto di vista cyber così come la comprensione delle ricadute sul business in cui il rischio è analizzato.

Ci sono due aspetti principali che hanno bisogno di metriche leggibili:

1. Valutazione del rischio
2. Conseguenze di rischio

Il primo elemento viene utilizzato per definire quanto “rischioso” è qualcosa.

La misura del rischio richiede, per semplificare una questione complessa, di essere in grado di valutare la probabilità che qualcosa accada, l’entità del danno e il costo per aggiustare le cose.

La dimensione economica dei danni e dei costi occorrenti per sistemare le cose sono legati alle conseguenze identificate per uno specifico rischio. Queste sono, fondamentalmente, le metriche che possono essere utilizzate in una riunione col consiglio di amministrazione per descrivere il rischio in termini comprensibili ad un pubblico non-consapevole in termini di cyber sicurezza.

Non voglio qui entrare nel dettaglio della valutazione del rischio, sono sicuro che come CISO avrai una profonda conoscenza e comprensione del problema e non voglio annoiarti con le mie riflessioni al riguardo, ma permettimi di osservare come non ci sia, apparentemente, ancora un quadro comune di valutazione diffuso tra gruppi e Business Unit della tua azienda. Trovo difficile credere che la percezione del rischio del dipartimento HR sia analogo a quello del dipartimento IT o del Marketing, o della produzione o vendita,  se cosi fosse probabilmente non staresti leggendo questo articolo mentre io starei quasi sicuramente leggendo il tuo.

La valutazione del rischio è una attività prevalentemente tecnica: la comprensione delle tecniche di attacco e difesa, le risorse necessarie sono ambiti dove CISO e management IT dovrebbero essere in grado di dare risposte sensate e credibili. Discorso diverso invece è l’analisi dell’impatto dell’incidente sul business. Questo impatto richiede sia la comprensione di cosa avvenga tecnicamente, almeno a grandi linee, ma anche la comprensione di quali siano i meccanismi legati al business che sono danneggiati dall’incidente. Va da se che le metriche da usarsi devono essere comprensibili al business, altrimenti sono inutili.

Le conseguenze di un incidente ed il suo livello di rischio sono ovviamente correlate cosi come sono correlate le dimensioni che definiscono il problema, l’obiettivo è capire, nella ipotesi che si verifichi un incidente di sicurezza, quali possano essere le misure che consentono alla vostra azienda di descriverlo e effettuare un confronto con un altro evento per determinare, ad esempio, priorità di intervento e di budget.

Avrebbe senso, dal mio punto di vista, presentare qualsiasi analisi di rischio al consiglio di amministrazione e altri manager e dirigenti in questi termini:

1) costo monetario in termini di perdita di ricavi

2) costo monetario in termini di costi effettivi sostenuti o da sostenere

3) impatto sulla penetrazione del mercato

4) impatto sulla percezione del marchio

Utilizzare queste 4 dimensioni permette di confrontare un incidente “ABC” ad un avvenimento “XYZ” e rispondere in qualche modo alla domanda del membro del consiglio fatta prima e, inoltre, a dare una metrica per capire dove e perché investire in un’area invece in un’altra.

Permettimi di descrivere rapidamente i 4 punti.

1) costo monetario in termini di perdita di ricavi

Si tratta di una dimensione che può essere facilmente percepita dai responsabili commerciali e finanziari. Comporta l’essere in grado di stimare quanta attività di vendita sarà influenzata dall’incidente. Il lasso di tempo preso in considerazione è, ovviamente, una delle criticità chiave, dal momento che gli eventi possono avere un effetto diverso in termini di intervallo di tempo breve, medio e lungo termine.

La valutazione può essere presentata sia in termini di importo netto di denaro o % rispetto al bilancio. Entrambi sono utili per capire l’impatto dell’evento.

2) costo monetario in termini di costi effettivi sostenuti o da sostenere

Questo significa mettere in considerazione tutti i costi vivi relazionati all’incidente come multe, questioni legali, interventi di sostituzione o aggiornamento del parco HWSW , persone che lavorano sull’incidente e così via. È importante separare i costi collegati all’incidente, dalle perdite economiche collegate all’incidente stesso, perché la natura degli interventi correttivi è estremamente diversa nei diversi casi.

3) impatto sulla penetrazione del mercato

Si tratta di una metrica che ha senso per un fornitore che sta cercando di espandere la sua presenza nel mercato come la tua azienda sta probabilmente cercando di fare. È strettamente connesso ai ricavi diretti, ma anche con le aspettative di crescita. Ciò può essere rappresentato come una % della quota di mercato.

4) impatto sulla percezione del marchio

Questo ultimo elemento è il più difficile da misurare, ma dato che dipende dalla metrica utilizzata per valutare il valore del Brand all’interno dell’azienda, dal momento che non mi è stato detto quali parametri vengono utilizzati qui posso solo suggerirti di presentare la variazione % correlata al valore stimato prima dell’incidente.

Per quello che so se questo non è stato fatto prima potrebbe essere qualcosa di intelligente da presentare in un futuro Business Plan o un’attività per il Cyber e Information Security Office da effettuarsi quest’anno in maniera da essere in grado, in futuro, di fare presentazioni e proiezioni che abbiano un senso.

Con quei 4 punti sarebbe possibile per entrambi (tu ed il consiglio di amministrazione):

a) fare confronto tra rischi

e

b) fornire al Consiglio una serie di elementi che possono essere oggettivamente utilizzati per prendere decisioni strategiche e di indirizzo.

Prendiamo come esempio la analisi dei rischi concernenti ad una violazione delle normative sulla privacy europea, il famigerato GDPR

L’approccio che ti ho proposto consentirebbe di presentare nel BP un insieme di dati comprensibili ed adatti a giustificare le spese e gli investimenti per ogni tipologia di rischio presentato; qualcosa di simile alla seguente tabella:

Permettimi di spiegare la tabella, considera naturalmente che i valori sono fittizi e il lasso di tempo considerato può essere regolato in base alla tua realtà.

Non conformità al GDPR

1) violazione di dati personali del cliente: intestazioni di colonne

Impatto a breve termine (1-3 mesi)

È cosa succedere immediatamente dopo il problema, quando è necessario intraprendere le operazioni necessarie per riprendere la operatività. Se hai un Emergency Response Team (dovresti) va computato qui…

Impatto di medio termine (3 mesi – un anno)

Permettimi di essere onesto, se è un problema di minore entità può accadere che le cose si possano risolvere rapidamente, ma se il problema è più grande, come ad esempio il tuo database di marketing esposto al pubblico su internet, devi iniziare a considerare anche le spese legali, multe e l’impatto sul tuo mercato…

Impatto a lungo termine (1-3 anni)

Le cose hanno un impatto anche dopo il tuo Business Plan, la vita non è limitata alla tua arbitraria finestra temporale, il business non si limita a finestre temporali limitate, tu dovresti essere in grado di fare previsione e analisi di più lungo periodo, oltre alla visione, orrore, trimestrale o annuale. È una esigenza comune in qualsiasi attività commerciale, e qui è o stesso.

2) violazione dei dati personali cliente: intestazioni di riga

Perdita di entrate

Questa è la perdita di gettito, legata all’incidente, che si dovrà affrontare rispetto le vostre aspettative di bilancio.

Costi diretti

Questo contiene ciò che si deve pagare per causa diretta  dell’incidente ad esempio:

• Sostituzione, aggiornamento, implementazione soluzioni HWSW
• Multe
• Stima dell’eventuale costo legato alla richiesta di risarcimento di eventuali parti lese
• riscatto pagato (ad esempio in caso di ransomware)
• aumento di costo di eventuali polizze assicurative sulla cyber security
• costi di fermo porduzione
• persone che lavorano sulla questione per risolvere il problema (eventuali analisti forensi, esperti informatici, avvocati…)
• …

Impatto sulla penetrazione del mercato

Questo è il posto dove mettere come l’incidente danneggerà il vostro business in termini della vostra presenza sul mercato (quote di mercato) e le prospettive future.

Impatto sulla percezione del marchio

Questo indica quanto la tua credibilità risentirà dell’incidente

Con questo tipo di matrice sarebbe facile fare valutazioni corrette e confronti sensati. Non so se questo è, al momento, qualcosa che può essere fatto con gli attuali strumenti di analisi in tuo possesso, ma sarebbe un elemento utile da mettere in un BP e per un futuro corretto approccio alla valutazione del rischio per la sicurezza informatica (cyber security, data seurity e data privacy).

ciao

Antonio