Una serie di interessanti articoli (nell’ordine questo, questo, e questo) che ruotano attono all’uso che fanno i CISO, e chi si occupa di sicurezza IT in generale, del concetto e del termine di ROI. La discussione sul fatto che un risparmio si possa o meno considerare parte di un ROI mi lascia piuttosto indifferente: basta che un economista mi dica se è corretto o meno, e mi adeguo :). Tuttavia, nella discussione vengono fuori una serie di concetti che meritano di essere evidenziati. Il più importante è che se è vero che il CIO, e il CISO a seguire, devono essere maggiormente coinvolti e propositivi riguardo al ruolo che l’IT può avere nello sviluppo delle opportunità di business aziendali, allora dovranno essere sempre più in grado di padroneggiare almeno i concetti più elementari dell’economia e della gestione aziendale. Così, dopo esserci dovuti “inventare” una competenza sulle normative del settore ICT, ce ne dovremo creare una anche di economia di base.
Mentre inizialmente la sicurezza era presentata come una “esigenza” tecnica, un po’ di anni fa hanno cominciato a girare i primi termini “finanziari”. Il primo che ricordo è il TCO, il Total Cost of Ownership. Più che altro, lo sentivo usare per giustificare la scelta di un prodotto anziché di un altro, ma presto si sono visti i suoi limiti: la scelta di un prodotto di sicurezza non si basa su quanto costa ma su quanto è efficace nell’evitare problemi (nel ridurre il rischio). Il TCO andrebbe bene quindi solo per confrontare prodotti assolutamente equivalenti, una volta però che si sia già deciso che uno dei due deve essere acquistato: un paramentro quindi decisamente poco utile nelle scelte più importanti. Si è quindi passati rapidamente al ROI, mutuando ovviamente il termine da altri contesti, probabilmente dalla gestione di progetti IT di breve durata. Se ben ricordo, era anche il periodo in cui si cercava di presentare la sicurezza come “enabling technology” (ovvero, se non ce l’hai non puoi svolgere certe attività). Anche questo discorso ha portato pochi frutti, perché chi ritiene di svolgere delle attività le svolge, riducendo comunque i costi della sicurezza ad un minimo, generalmente misurato più su un benchmarking per attività analoghe, magari dei concorrenti, che su una valutazione del ROI o di altri parametri finanziari. Abbiamo cominciato ad usare il termine ROI come se il significato fosse ovvio, ma in realtà praticamente nessuno si è posto il problema di “studiare” cosa fosse. Come dice giustamente il primo articolo, è sembrato semplicemente un termine adatto a comunicare con il management nella sua lingua. Di principio però, per comunicare bisognerebbe usare i termini giusti… Oltre a non essere ovvio il significato di ROI, non è ovvio neanche che sia un buono strumento per valutare gli investimenti in sicurezza. E qui la cosa si fa più interessante. Non sono in grado di valutare la competenza dei due autori, ma entrambi sembrano riconoscere l’autorevolezza di Lowrence A. Gordon. Questi, ad esempio in questo articolo del 2004, dice proprio che “Infosec managers trying to justify budget requests sometimes prop themselves up on a discussion of ROI (return on investment), but with mixed results. After all, what’s the return on a firewall investment? And they don’t use capital budgeting calculations, such as NPV (net present value) and IRR (internal rate of return), to defend investments in information security infrastructure. However, CFOs use these calculations regularly and expect department heads to refer to them when competing for funds, so it behooves security pros to join their peers in other departments who already talk the talk.” Quindi ci dovremmo studiare un po’ di economia per parlare il gergo dei CFO sapendo cosa diciamo… Incidentalmente, cercando ho trovato questo altro articolo in italiano che sembra almeno in parte ispirato da quello in inglese. L’IRR (tasso interno di investimento, TIR) non ha una sua voce nella Wikipedia in italiano, compare solo nella pagina sulla valutazione degli investimenti, che mi sembra comunque la pagina adatta per capire questi concetti, compreso il NPV (valore attuale netto, VAN). Confrontando il ROI con il TIR o il VAN, mi sembra chiaro perché viene usato quest’ultimo quando si parla di investimenti, specialmente quelli che devono avere un effetto sul lungo periodo, dato che il ROI non tiene minimamente conto né del fattore tempo né, conseguentemente, di un fattore di sconto. Infatti, nella pagina sul ROI di Wikipedia, si dice che è generalmente riferito ad un periodo definito, ad esempio l’anno fiscale. Non è difficile capire come sia facile che la persona dell’IT lo usi in modo improprio. In effetti, gli investimenti sulla sicurezza sono generalmente destinati ad avere i loro effetti su periodi medio lunghi, e quindi il ROI sembrerebbe particolarmente inadatto. Dopo aver imparato il “gergo” del CFO e il suo significato, che ovviamente non si ridurrà a questi due termini, dobbiamo verificare quali sono le differenze fra le pratiche italiane e quelle USA, tenendo conto delle differenze di cultura e di dimensioni, in modo da non usare i termini nel contesto sbagliato. Ve lo immaginate il CISO che a una riunione cerca di fare il ganzo parlando di “tasso interno di investimento”, e il CFO che gli dice (per dire) “Dove l’ha letta ‘sta roba? In Italia non al usa nessuno, noi usiamo solo il VAN…”
Questi articoli scritti da persone di provenienza “finance”, mentre correttamente suggeriscono di usare i termini e gli strumenti corretti per confrontarsi con il financial officer, sorvolano comunque sulla difficoltà maggiore, e cioè quantificare correttamente i ritorni della sicurezza, indipendentemente da come poi, ad esempio, i ritorni vengono attualizzati. Cito ad esempio: “We did an analysis of how many alerts we got, how many people it took to run those alerts down and how many of those [alerts] were false positives,” says Mary Ann Davidson, chief security officer at Oracle. “For the IDS we had in place, we got something like 80,000 alerts a week, and the false-positive rate was 60 percent to 70 percent. We looked at that versus the system we were piloting, where we found we had far fewer alerts and the ones we got were higher quality. So we said, how many people would we have to hire to make sense of the system we had? It turned out to cost a lot less to replace the system right away.” Certo, si tratta di confrontare semplicemente i costi del mantenimento di un prodotto rispetto alla sostituzione con un altro che funziona meglio. Cosa avrebbero fatto se il secondo prodotto avesse dato qualche falso negativo in più? Pesa più la riduzione dei costi di gestione o l’aumento di rischio? E come fanno a dire che non è più conveniente eliminare del tutto l’IPS e sostituirlo con un’altra tecnologia? Perché il difficile non è valutare quanto costa mantenere un sistema di sicurezza, ma valutare quanto fa risparmiare in termini di riduzione del rischio. Attualmente infatti, la riduzione del rischio è il parametro sul quale si basa la valutazione dell'”efficacia” di un meccanismo di sicurezza. Sempre più persone però mettono in dubbio l’utilizzabilità pratica di questa metrica in un contesto in rapida evoluzione, senza dati storici e con dati sullo stato attuale frammentari e poco affidabili. Dice anche il primo articolo: “Another problem most security managers will encounter is their inability to definitively say that their project will indeed save a certain amount of money. This is not the case for licensing deals, e.g., “Switching from Vendor X’s SSL VPN to Vendor Y’s SSL VPN will save $10,000” because the outcome is certain, breach of contract nonwithstanding. Certainty or even approximate probability is a huge hurdle for many security projects because of several factors:
- Asset value is often undetermined; in some cases, assets themselves are not even inventoried
- Vulnerabilities in assets are unknown, because new flaws are discovered every day
- The threat cannot be properly assessed, because they are unpredictable and creative
As a result, risk assessment is largely guesswork. Guesswork means the savings can be just about anything the security manager chooses to report.” Un altro che si unisce al coro. Anche se l’articolo di Gordon ad esempio contiene delle idee interessanti, di fatto queste sembrano avere bisogno del supporto di una quantificazione della riduzione del rischio fornita dai meccanismi di sicurezza. Tuttavia, per chi si occupa di sicurezza IT il problema del rapportarsi con i concetti dell’economia non è neppure tutto lì. La tendenza è ad esempio quella di dire che gli investimenti in sicurezza non devono superare le perdite attese. Invece, a quanto pare, Gordon mostrerebbe che l’investimento ottimo sarebbe molto meno; non ho ancora letto perché, ma probabilmente dimostra anch’esso che l’economia e la finanza “spicciole”, esattamente come la statistica spicciola, la giurisprudenza spicciola ecc. ecc., possono far prendere delle grosse cantonate.
