Questo articolo fa parte della serie Spiegare la sicurezza.
Un articolo uscito sull’ultimo numero di (IN)SECURE Magazine, webzine gratuita e interessante, anche se con troppe pubblicità, mi offre lo spunto per parlare delle relazioni con gli alti dirigenti aziendali.
Ho sempre trovato l’argomento di elevato interesse, anche perché è uno dei cardini principali su cui gira l’efficacia delle attività di sicurezza informatica in azienda. La problematica è che molto spesso il cardine si ferma, per tutta una serie di incomprensioni, oppure accelera vorticosamente in seguito a un fortissimo commitment che viene dall’alto (e di questo ne riparlerò meglio in un prossimo post).
L’articolo in questione è Managers are from Mars, information security professionals are from Venus, scritto da Brian Honan. Brian è un esperto di sicurezza irlandese fondatore del primo CERT/CSIRT dell’isola di smeraldo. Avendo a che fare con rappresentanti governativi, immagino l’esperienza di Brian in termini di relazioni tra strutture operative e dirigenza (e anche io ne so qualcosa). Il suo punto di vista mi sembra quindi sia da considerare.
Un passaggio chiave da cui iniziare è questo:
Senior Management does not care about technology. Their focus is on the core functions of the business to ensure the business survives, meets its goals and also on being accountable to the stakeholders.
Questo punto di vista spesso non è ben compreso da un esperto di sicurezza ICT, anzi è visto come un segno di ignoranza del manager, di scarsa considerazione del valore del proprio lavoro.
In realtà le cose non stanno così, il focus di un C-Level executive resta quello dell’erogazione del business, comunque vada. Questo va compreso da parte di chi si occupa della sicurezza, perché comprendendo questa necessità (non derogabile né modificabile) ci si può porre in modo diverso. Si dovrebbe offrire al top manager un prospetto sullo stato della sicurezza per quel determinato progetto e/o servizio, aiutandolo a capire come possono eventuali problemi influire sull’erogazione del servizio stesso. Nel frattempo, altra cosa fondamentale, bisogna fornire dati che servono al manager a riferire agli stakeholders. Perché, non dobbiamo scordarlo, tutti abbiamo un superiore.
Questo non succede perché spesso i tecnici della sicurezza si basano sul paradigma del “pezzo di ferro”, ovvero: tecnologia tecnologia tecnologia. Scrive sagge parole Honan:
Information security is not all about firewalls, Intrusion Detection Systems, anti-virus software or whatever the latest shiny gadget is. It is also about ensuring the proper policies and procedures are in place and that people are trained and educated properly to understand their role and responsibilities in securing the information they deal with on a daily basis.
Gli alti dirigenti non ne sanno nulla di tecnologia e non ne vogliono (né devono, non è il loro lavoro) saperne. Parlare solo di tecnologia, e costi a essa associata, confonde le acque e crea ostilità da entrambi i fronti. I dirigenti pensano che la sicurezza sia solo un costo e gli esperti di sicurezza tornano in ufficio frustrati, pensando di avere come capi una mandria di imbecilli che non comprendono quanto importante sia il loro lavoro.
Ma il problema è che si stanno semplicemente parlando due lingue diverse.
Ma come facciamo noi che lavoriamo nella sicurezza ICT a portare correttamente il nostro messaggio ai vertici aziendali? Dobbiamo studiare come funziona l’azienda. Dobbiamo capire quali sono le priorità del top management e proporre contributi e soluzioni (procedure, policy, rischi reali). È inutile fornire parole complicate (zero-day, SQL injection, ecc.) ma bisogna parlare di analisi dei rischi, di governance, proporre piani di rientro e fornire numeri e dati verificabili. Questo perché
Management understands and speaks about issues relating to the business in terms of risk. Learning to understand risk and how to present it to the management will enable them to appreciate and better understand what you are trying to achieve.
Loro necessitano di informazioni, numeri, analisi su come ridurre i costi (fa sempre effetto) e di come ottenere un ROI anche sulla sicurezza. La finalità deve essere far comprendere i rischi riguardo l’erogazione del servizio, ed eventuali conseguenze che l’azienda potrebbe subire nel caso insorga un problema di sicurezza. Bisogna essere propositivi, portare all’attenzione dei dirigenti le analisi, i rischi e le contromisure. Ma va fatto tutto prima che succeda qualcosa, non andarsi a lamentare di aver fatto la Cassandra e tutto è andato male.
Perché potreste essere incolpati voi di non aver fatto qualcosa…
Questo vuol dire anche evitare assolutamente di ricorrere al terrorismo (fear, uncertainty and doubt), perché questo può essere sì un modo per ottenere subito ascolto, soprattutto se il dirigente è realmente un imbecille, ma poi, quando si faranno i conti e si scoprirà che era tutta fuffa, chi pagherà non sarà certo il manager…
When the dreaded event you warned the business about never happens you then become the “boy who cried wolf”.
E allora poi, davvero, non vi ascolterà più nessuno…
Glamis on Security 
C’è anche la tecnica “Accenture” che oltre al terrorismo per convincere il dirigente imbecille, fa in modo nel contempo di renderlo complice.
Così il progetto di sicurezza diventa una sovrastruttura draconiana che oltre a funzionare male, ostacola il lavoro.
Il board accetta il lavoro finito perché il complice interno maschera le fetenzie ed il gioco è fatto!
I problemi sono già enormi nella comunicazione tra strutture di una stessa azienda, se poi ci mettiamo anche i consulenti…
Penso che anche della consulenza in ambito sicurezza ci sarà spazio per parlarne.
Articolo interessante. Anche se ritengo la seguente affermazione tutta da discutere.
“In realtà le cose non stanno così, il focus di un C-Level executive resta quello dell’erogazione del business, comunque vada”.
Personalmente credo che il focus di un C-Level dovrebbe essere l’erogazione del business, nell’ambito del business, secondo le regole del business e in accordo con gli obiettivi del business.
E cosa accade per le organizzazioni che non operando su un mercato e non sono business-driven?
La differenza non è di poco conto se si considera che il “comunque vada” sottende una totale perdita di consapevolezza del ruolo manageriale.
L’IT nel suo complesso rappresenta il sistema nervoso di un’organizzazione, e la sicurezza nello specifico, un processo che permette all’organizzazione di esistere, sopravvivere e reagire agli stimoli e ai disturbi dell’ambiente dove opera.
E’ vero che il linguaggio del manager e del tecnico sono diversi, ma è vero pure che se di linguaggi parliamo, entrambi sono in grado di rappresentare le stesse esigenze e di essere tradotti. Inoltre è necessario introdurre un importante elemento dialettico tra obiettivi economici e organizzativi. I primi molto spesso sono di breve/medio termine che possono, e non mancano certo esempi chiari, interrompere il ciclo vitale di un’organizzazione, i secondi, svincolati da una pura logica di risultato, possono valorizzare nel lungo termine il sistema.
In quest’ottica, se è vero che bisogna eliminare i tecnicismi, è pur vero che bisogna pensare alla sicurezza come si pensa alla propria salute, dove si tende pochissimo al risparmio. Quale miglior ROI può essere vivere più a lungo possibile per un’organizzazione?
A mio avviso il vero limite della comunicazione è di natura culturale e riguarda l’Information Technology in maniera globale. L’IT di oggi è come l’industria automobilistica dell’inizio del novecento, tanta passione ma poca organizzazione. Tanta competenza tecnica, a volte troppa dei vari tipi di engineer e mancanza completa di consapevolezza dell’IT Management. Naturalmente esistono bellissime eccezioni.
Se la sicurezza è il processo di controllo dell’interfaccia organizzazione/ambiente com’è possibile fondarla senza metodologie condivise, misurabili e ripetibili?
Tornando al paragone automobilistico, oggi due vetture di serie sono uguali come due atomi di idrogeno (i fisici perdoneranno l’analogia) mentre due realizzazioni di un progetto IT possono essere due cose diversissime. Gli addetti IT dovrebbero imparare, executive compresi, la cultura della qualità di processo, della minimizzazione della varianza, unico modo per fondare processi IT e IT Security saldi e performanti e quasi indipendenti dalla tecnologia. Inoltre la ricerca della sicurezza e la creazione di una governance IT deve essere un atto libero e volontario di un management che verifica i modi di esecuzione e adesione ai principi della governace stessa in maniera continua, garantendo i risultati attesi e correggendo le anomalie. Di là dalle tecnologie, mi pare sia necessario saper classificare le esigenze organizzative e produrre risposte nell’ambito IT facendo tesoro della cultura di project management tipica di altri settori produttivi ben più maturi. In questi ambiti la tecnologia diventa un modo per produrre e innovare rispondendo alle richieste del business o alle necessità organizzative sempre mutevoli. Così facendo la sicurezza è l’IT in genere non saranno solo un semplice costo ma anche una via per il miglioramento continuo e l’aumento delle performance del sistema.
Ciao Glamis,
come ho già avuto modo di dirti, complimenti per l’iniziativa. I miei migliori auguri per il prosieguo.
Venendo all’argomento, condivido molta parte di quello che hai scritto, volevo solo aggiungere un ricordo di un altro post molto interessante sull’argomento. Taosecurity (da poco ex responsabile del CERT della General Electric ed ora in forza a Mandiant Security) suggeriva di proporre ai vari C-level la sicurezza sotto forma di”vantaggio competitivo” rispetto ai competitor. Non sto a riportare tutto il concetto (che può essere facilmente ripreso dal suo sito) ma devo dire che era abbastanza convincente.
Se qualcuno decidesse di provarci, ci faccia sapere come va a finire.
Un caro saluto e in bocca al lupo a Glamis!
Matteo
Ciao Alessandro e Matteo, grazie innanzitutto per i commenti. Veniamo a noi.
@Alessandro: hai fornito un punto d’osservazione molto interessante. Il problema principale che ho riscontrato nell’esperienza di tutti giorni è proprio quello che a volte la dirigenza non considera, anche perché gli viene spiegato male, il valore di questo o quel sistema IT, principalmente nell’ottica della sicurezza informatica, visto che è di quel campo che posso parlare.
Quando parli di cultura della qualità di processo non posso che approvare, ma proprio da questa carenza culturale nasce il “comunque vada”. A maggior ragione in ambito sicurezza IT, quando c’è un problema nell’erogazione del servizio, si mette la classica pezza e alla via così. Infischiandosene della qualità, della risoluzione dei problemi. Penso che chiunque abbia gestito un firewall si sarà sentito dire almeno una volta dal capo del suo capo il classico non funziona un cazzo, apri tutto!.
E magari dopo non si fa nemmeno analisi, non si cercano le cause, nulla.
La mancanza di cultura della qualità è proprio causa di questo, ed è qui che penso i linguaggi dei vari componenti aziendali dovrebbero capirsi…
@Matteo: crepi il lupo!
Per quanto riguarda TaoSecurity, penso che gli articoli a cui fai riferimento sono questi.
Li avevo letti all’uscita, li trovo interessanti anche se un po’ troppo orientati al mondo anglosassone. Forniscono però spunti interessanti, sia quando criticano il ROI o l’indice di rischio applicato alla sicurezza ICT (storia trita e ritrita), ma soprattutto questo:
In addition to mentioning ROI and risk, it’s important to remember that compliance is the other driver that is likely to justify funding.
Questo lo vedo molto più applicabile alla realtà italiana, ed è un argomento che vorrei riprendere appena possibile.
In realtà era questo il post che avevo in mente…
http://taosecurity.blogspot.com/2010/03/forget-roi-and-risk-consider.html
ma esprime concetti abbastanza simili a quello che hai trovato anche tu.
Un salutone,
Matteo
In realtà avevo citato anche quello, gli articoli sono due.
Forse si capiva poco 😉