L’esecuzione di un’analisi dei rischi, come visto in un precedente articolo, potrebbe nascondere incognite in grado di minare la qualità del risultato finale. In particolare, in quell’approfondimento venivano presi in considerazione una serie di elementi, ma accanto a quell’elenco dobbiamo aggiungerne uno molto significativo le cui origini sono di natura prettamente culturale e derivano dal fatto che gli standard e le buone prassi vengono applicate spesso senza alcuno spirito critico.
L’errore a cui faccio riferimento è il naturale abbinamento fra analisi del rischio informatico e i soli rischi legati alla sicurezza.
Vi è infatti un’innata tendenza a far corrispondere le analisi dei rischi in ambito ICT ai soli parametri di integrità, disponibilità e riservatezza dei dati e dei sistemi.
In questo modo ci si dimentica che esistono numerosi altri parametri che caratterizzano i dati o un sistema informativo, i quali possono essere influenzati da eventi accidentali o volontari che, analogamente a quanto avviene per i parametri di sicurezza, sfruttano le vulnerabilità del sistema per creare danni.
Per essere esaustivo citerò esempi in ambito sistemi e in ambito dati.
Indice degli argomenti
Analisi del rischio informatico: il degrado delle prestazioni
Tutti abbiamo sperimentiamo la perdita di performance quando si sta utilizzando un’applicazione o quando la connessione rallenta improvvisamente.
Non è una vera e propria indisponibilità, ma un rallentamento dovuto a molteplici fattori che non hanno impatti sulla sicurezza, ma che comunque hanno impatti sul sistema informativo e che possono provocare danni di vario tipo all’organizzazione che li subisce.
Ad esempio, lato fornitore il mancato rispetto degli SLA da parte di chi eroga un servizio potrebbe comportare delle penali; lato utente questo rallentamento potrebbe comportare il non riuscire a terminare un lavoro in tempo utile.
Per me uno degli effetti più fastidiosi è la riduzione della banda trasmissiva mentre sto erogando qualche corso (o peggio la caduta della linea…).
Gli eventi che generano tali situazioni e le relative azioni di rimedio hanno una gestione all’interno delle organizzazioni parallela a quella della gestione degli incidenti di sicurezza ed in effetti si tratta di incidenti operativi.
Possono essere così significativi che la PSD2 obbliga alla segnalazione degli incidenti che hanno impatti rilevanti nel mondo finanziario, indipendentemente dal fatto che questi siano incidenti operativi o di sicurezza.
L’esempio del degrado delle prestazioni è voluto in quanto in questo caso il confine con una versa indisponibilità del servizio può diventare labile, con tutte le conseguenze del caso, compresa l’eventuale escalation verso una crisi che invocherebbe il piano di continuità operativa.
A tal riguardo quanti operatori hanno ipotizzato scenari di degrado del servizio che portino a questo tipo di soluzione?
Considerando che quando si opera in continuità operativa le soluzioni sono progettate per erogare un servizio accettabile, ma non certo pari a quello erogato in produzione è molto significativo capire se si è effettivamente pronti a gestire una situazione nella quale sia opportuno o meno invocare il piano di business continuity[1].
I parametri per una corretta analisi del rischio informatico
Prendiamo ora in considerazione un altro esempio considerando ulteriori parametri che possono descrivere i dati (al di là dei già citati integrità, disponibilità e riservatezza). Al riguardo è possibile trovarne in letteratura molteplici. Ad esempio, lo standard ISO 25012 cita i seguenti parametri:
Accuracy |
Completeness |
Consistency |
Credibility |
Currentness |
Accessibility |
Compliance |
Confidentiality |
Efficiency |
Precision |
Traceability |
Understandability |
Availability |
Portability |
Recoverability |
Ma limitiamoci a considerare alcuni parametri descrittivi con cui tutte le organizzazioni hanno a che fare tutti i giorni in quanto il loro rispetto è un requisito normativo (GDPR).
L’importanza dell’esattezza dei dati
Rifacendoci all’art. 5 del GDPR (per quanto di nostro interesse esattamente identico al precedente art. 11 del D.lgs 196/03) lo stesso richiede che i dati personali siano:
esatti e, se necessario, aggiornati; devono essere adottate tutte le misure ragionevoli per cancellare o rettificare tempestivamente i dati inesatti rispetto alle finalità per le quali sono trattati («esattezza»);
Quali sono i rischi in cui incorre un’organizzazione che non tratti dei dati esatti?
Se si tratta di dati personali ovviamente un rischio sanzionatorio.
Se qualcuno subisce delle conseguenze come effetto del trattamento di dati inesatti un rischio risarcitorio.
Ma al di là degli aspetti legati al trattamento di dati personali si consideri il fatto che un’azienda tratti dei dati inesatti come risultato di un errore informatico ad esempio relativamente al proprio bilancio e che, in conseguenza di questo fatto, i vertici aziendali assumano delle decisioni che comportano forti perdite all’azienda stessa.
Avere dei dati esatti è quindi fondamentale.
Il concetto di esattezza è molto diverso dal concetto di integrità così come inteso dal punto di vista della sicurezza; un dato può essere integro, ma non esatto.
Anzi, l’integrità garantisce che un dato che sia stato inserito in modo sbagliato in un sistema informativo non venga alterato, restando pertanto sbagliato.
Ovviamente il concetto di esatto è molto intuitivo, ma come si evince dalla precedente tabella sono molteplici i parametri che è necessario considerare.
Analisi del rischio informatico e qualità dei dati
Una reale valutazione del rischio informatico è quindi molto più impegnativa di una “semplice” analisi dei rischi legati alla sicurezza e sarebbe oltretutto doverosa.
Questo sia per una reale quantificazione dei rischi che un’organizzazione dovrà affrontare, sia per valutare più adeguatamente le contromisure da adottare.
Se ad esempio una contromisura ha effetti di mitigazione verso eventi che influenzano più fattori, sarà più facile giustificarne l’adozione in un’ottica di costi e benefici attesi.
Si potrebbe obiettare che il concetto di esattezza è legato alla qualità dei dati.
Ma la gestione della qualità dei dati è lo strumento con cui mitigare gli effetti; quello che questo articolo vuole evidenziare è che l’analisi dei rischi informatici dovrebbe comprendere molti più aspetti rispetto alla semplice sicurezza, compresi (ma non sono i soli) quelli che riguardano la qualità dei dati.
Conclusioni
Anche se l’analisi dei rischi che riguarda la vostra organizzazione evidenzia un basso profilo di rischio dal punto di vista della sicurezza, nulla vi garantisce che decine di altri fattori che riguardano i vostri dati ed il vostro sistema informativo non abbiano impatti per voi irrimediabili.
Forse è il caso di iniziare a pensare ad una visione molto più estesa di cosa sia effettivamente il rischio informatico.
NOTE
Si consideri il caso che la soluzione di continuità operativa sia progettata per erogare un servizio con una prestazione pari all’80% di quanto erogato in produzione. Se la mia prestazione in produzione si è degradata al 70% e persiste in tale situazione per un tempo prolungato e senza che sia ipotizzabile una soluzione a breve termine mi azzardo ad attivare la soluzione di business continuity che, se tutto va bene mi garantisce solo il 10% di prestazione in più? ↑
