Il meglio del Security Summit 2011

Logo Security SummitFinalmente (con un po’ di ritardo devo dire…) sono stati pubblicati gli atti del Security Summit 2011 a Milano.

È possibile quindi procedere con un’analisi degli interventi a cui ho assistito e che ritengo comunque più significativi.

Ricordo che dei keynote avevo già parlato.

Parto subito dalla fine, ovvero dall’evento satellite che ha chiuso le prime due giornate del Summit, l’Hacker Film Festival. Devo dire che è stato senza dubbio lo spazio più piacevole del convegno, sia per l’atmosfera informale che per l’apertura della discussione tra chi presentava i corti e i (pochi, per fortuna) spettatori rimasti. Lo spazio era veramente amichevole e ha permesso di dialogare sulla cultura hacker, sulle problematiche che da anni affrontiamo nel campo delle libertà civili. Il tutto dimenticando per un attimo l’ambito lavorativo e tornando alla passione che, in fondo, ci spinge a fare quello che facciamo. Poter discutere di queste cose con gente come Perri, Ziccardi e i soliti Chiesa/Pennasilico poi, vale sicuramente la fatica di chiudere 12 ore di incontri. E poi offrivano anche l’aperitivo! 🙂

Ma veniamo agli interventi regolari.

Attacchi alle infrastrutture virtuali: l’intervento di Pennasilico/Nencini ha ripreso i concetti di sicurezza dei sistemi virtualizzati di cui si parla praticamente da quando esistono. Rimane tuttavia attuale poiché noto che molto spesso chi si occupa di queste piattaforme, soprattutto dal lato sistemistico, non conosce il rischio derivato dalla possibilità di effettuare un escape from VM (e il link è del 2007). Questo sia per una estrema difficoltà nell’eseguire l’attacco, sia nel fatto che forse (…) i vendor di tecnologie di virtualizzazione tendono a non evidenziare troppo i problemi di sicurezza. Tra virtualizzazione e cloud poi ho apprezzato molto il discutere di come il perimetro attuale che conosciamo (isolato da firewall, ips e quant’altro), abbia ancora senso. La chiave ancora una volta è analizzare e progettare bene le proprie infrastrutture e i propri sistemi. Senza farsi prendere dalla moda del momento (che sia cloud o virtualizzazione o, in molti casi, entrambi) e senza ragionare con schemi ormai antiquati (ad esempio pensare solo a difendere il perimetro o trattare gli host virtuali come se fossero fisici).

Mobile Security: Rischi, Tecnologie, Mercato e Rischi ed opportunità nell’utilizzo degli Smartphones: Raoul Chiesa (in entrambi gli interventi) e Philippe Langlois (solo nel primo) hanno presentato prima una tavola rotonda (molto animata, come sempre quando c’è Raoul) sulla sicurezza dei dispositivi mobili e poi un intervento più mirato al malware. La chiave è stata senza dubbio la comprensione che i principali scopo degli attacchi ai telefonini è il billing. Sia malware che truffe classiche hanno come obiettivo far chiamare la vittima dei PNR (Premium Rate Numbers) da cui trarre grossi profitti. Devo dire che una soluzione possibile, a livello aziendale, per proteggersi è senza dubbio quella di stipulare contratti con gli operatori mobili che non permettano di eseguire queste chiamate. Magari resterà da proteggere i dati e le reti, ma almeno si risparmieranno un po’ di soldi. Il discorso è poi spaziato agli attacchi diretti all’infrastruttura del carrier ma lì, tra Femtocell e SS7 mi sono un po’ perso. Ammetto la mia ignoranza in materia e mi sto già aggiornando…

Application security dal modello tradizionale al Cloud: la presentazione di Riccetti/Gai ha posto enfasi su un argomento che mi interessa particolarmente, ovvero i processi di sviluppo di applicazioni sicure, in ambito cloud computing. In particolare il concetto di secure engineering, quando parliamo di software sicuro, è ancora più attuale se si sta progettando un’applicazione in-the-cloud. Anche se possiamo sparare un insieme di buzzwords (IaaS, PaaS, Private Cloud, ecc.), il punto da tenere a mente è che sono fondamentali ancora una volta un’ottima analisi dei requisiti e una seria progettazione architetturale. Perché possiamo continuare a parlare di parole in aria (o nella nuvola) quanto vogliamo, ma se non vengono recepiti correttamente i requisiti che l’applicazione deve soddisfare, e se non viene progettata in modo sicuro by-design e ragionato, allora i rischi sono tanti: lock-in, loss of governance, data leakage, dos applicativi, ecc. Insomma non bastano i tool e i prodotti, bisogna metterci la testa e non fidarsi mai dei vendor!

Cloud, Security, SaaS, ed altre meraviglie: come uscirne illesi! ancora Alessio Pennasilico e Antonio Ieranò parlano di sicurezza del cloud e degli altri servizi (il tema era molto presente, come prevedibile, durante tutto il Summit). Ancora una volta analisi dei pro e dei contro ma, appunto, ancora una volta viene ripetuto che bisogna fare analisi prima di imbarcarsi in un’impresa che potrebbe solo creare problemi. E non va fatto perché “è di moda“, “quegli altri ce l’hanno” o cose del genere (e si sentono…).

Seminario a cura del Capitolo Italiano di OWASP: oltre al riepilogo delle attività del progetto e del capitolo italiano fatte da Matteo Meucci, c’è stato un’illuminante talk di Giorgio Fedon sui Falsi miti nell’uso dei tool automatici, per l’analisi delle applicazioni web. Illuminante non tanto per chi, come me, è abbastanza conscio delle problematiche dell’analisi delle applicazioni, quanto per una platea generale ed molto vendor-oriented come può essere quella del Summit. E in fatti molti nasi si sono storti, mentre Giorgio parlava… Il succo in sostanza è che un’azienda che ha le risorse per acquistare questo tipo di tool (che costano molto) non può poi limitarsi semplicemente a farli girare ed aspettare i risultati, come se fossero un’enorme lavatrice di vulnerabilità. Deve invece analizzare molto criticamente i risultati che tirano fuori, scremarli con personale addestrato e, comunque, non scordare mai che un code review manuale e un pentest effettuato da specialisti non può essere sostituito da questi strumenti. Le argomentazioni sono senza dubbio interessanti, la mia opinione è che comunque questo tipo di strumenti in una realtà grande non può mancare. Vuoi perché un team di penetration tester non è proprio disponibile sempre, vuoi perché, se implementati con criterio, possono comunque aiutare parecchio. Importante anche il talk di Paolo @thesp0nge Perego, che ha purtroppo annunciato la prossima deadline del progetto Owasp Orizon, e sta quindi ricercando collaboratori. Se potete e volete aiutare, fatelo.

Infrastrutture Critiche vs Cyberthreats: Chiesa e Fabio Guasconi hanno riportato le ultime novità sulle minacce del cyber-warfare, riprendendo un po’ quanto detto da Schneier, e ricollegando il tutto al lavoro svolto dagli enti internazionali per emettere degli standard (ISO 27001 e seguenti) capaci di recepire e normare le procedure da effettuare in ambito sicurezza informatica. Molto interessanti gli argomenti di Raoul, soprattutto sapere che c’è una nazione, l’India, che prevede esplicitamente in una legge di usare tecniche di hacking per difendere le strutture critiche nazionali in caso di cyber attacco. Molto interessante anche la classificazione fatta da Chiesa dei rischi provenienti da determinate nazioni: la Russia è il paradiso dei cyber criminali, mentre dall’Ucraina vengono molte botnet, ecc. E che tutte le principali nazioni “a rischio” hanno comunque precise politiche di cyberwarfare già in essere da più di dieci anni. Considerato questo e considerato che gli hacker più pericolosi individuati dall’Hacker Profiling Project sono proprio quelli militari/governativi non è proprio una situazione in cui stare tranquilli. Soprattutto non stiamo proprio parlando di fantascienza… anche perché il paragone fatto da Chiesa tra armi tradizionali e cyber-armi è stato parecchio inquietante, considerati soprattutto i danni già fatti da queste ultime.

Spero di aver fatto un discreto riassunto delle sessioni più rilevanti, almeno per me.

Tutti gli altri atti sono sul sito e, se ci riesco, sarò anche a giugno al Security Summit Roma Sperando soprattutto che ci siano cose nuove.

Bye!

Security is all about trust

Security is all about trust, and when trust is lost there is no security.
Bruce Schneier

Recentemente sono successi un po’ di eventi che hanno avuto molta eco nel mondo della sicurezza informatica. E la frase di Schneier qui sopra riassume il sentimento che gira, e che condivido appieno.

Si è iniziato qualche tempo fa con lo sputtanamento totale di HBGary ad opera di Anonymous. Quello che poteva essere un atto di vendetta, e che comunque ha praticamente fatto chiudere un’azienda, si sta però spargendo ad altre realtà in un modo abbastanza preoccupante.

Qualche giorno fa RSA ha comunicato ai propri clienti di aver subito un attacco mirato a colpire il proprio prodotto SecurID. Questo è stato senza dubbio un colpo molto forte, sia alla credibilità (leggi: fiducia) dell’azienda, sia a molti suoi clienti che pensavano di aver trovato la panacea di tutti i mali. L’azienda infatti, dopo qualche tentennamento tendente al FUD iniziale, ha inviato ai suoi clienti delle FAQ dettagliate sull’incidente. Incidente di cui comunque al momento si sa poco e, se non sono state colpite delle banche, si saprà ancora meno.

Questo attacco mira a distruggere il (falso) senso di sicurezza dato agli utenti insieme al loro piccolo token. Perché il pensare che l’OTP sia mettere in sicurezza il sistema è un mantra che ho sentito, diverse volte, da chi ritiene riteneva che inserire questo tipo di password dispositive sia garantire un adeguato livello di sicurezza. Magari fregandosene di password policy, fregandosene di fare hardening o di controllare i log di accesso… ma andiamo avanti.

Dopo RSA, è stata colpita un’altra azienda cardine nel mondo dell’industria InfoSec: Comodo. Passando apparentemente tramite server italiani, qualcuno è riuscito a violare la struttura di Registration Authority, arrivando addirittura a generare certificati validi da usare a suo piacimento su alcuni siti molto noti. Proprio di queste ore è la notizia che l’azione è stata compiuta da una persona sola, iraniana (e infatti l’IP segnalato da Comodo era in Iran, anche se ovviamente questa informazione da sola non vale nulla) e in grado di ultimare l’attacco facendo reverse engineering di una libreria messa a disposizione da Comodo ai suoi clienti.

Questo evento è forse il più grave di quelli successi recentemente, anzi direi che un attacco con un impatto così grande non si sentiva da tempo. Attaccare la generazione dei certificati infatti mira direttamente a rompere la fiducia tra utente ed erogatore del servizio. Perché se lucchettino lì sotto mi dice che è tutto ok, che sto parlando con Google, o PayPal o la mia banca, e in realtà c’è di mezzo qualcun altro, allora tutto crolla. L’identità è uno dei punti chiave su cui si basa la fiducia in rete, e senza quella chiunque eroghi un servizio non farà mai più affari. E mentre gli attacchi MitM erano già pericolosi, ma si potevano in qualche modo bloccare, generare un certificato valido, da una RA ufficiale, vuol dire essere Google o PayPal.

Ciliegina sulla torta degli incidenti di questi giorni: MySQL.com (ma anche Sun.com) è vulnerabile ad attacchi di tipo SQL injection. Più che un rischio vero e proprio, questo evento è soprattutto un esempio.

Esempio che mi permette di riassumere tutti gli eventi discussi finora. Già perché una domanda mi sembra fondamentale: ma queste società come gestiscono la propria sicurezza? Possibile che realmente una persona, per quanto brava sia, riesca ad arrivare fino all’RA di uno dei più importanti certificatori di Internet, senza che nessuno si sia accorto di cosa c’era in quella DLL? Possibile che un attacco persistente permetta di mettere le mani su segreti e brevetti sui cui risiede la vita stessa dell’azienda, senza che nessuno controlli cosa sta succedendo? Perché quelli sono i bersagli a cui i criminali (e non gli hacker) stanno puntando: i segreti.

Parliamoci chiaro, RSA e Comodo non saranno mai più trusted come prima. Soprattutto in un mondo pieno di produttori di OTP o emettitori di certificati. Perché la fiducia è passata, perché hanno dimostrato di non sapere difendere i propri asset più importanti.

Ma la medaglia ha due lati, l’altro è cercare di analizzare quello che è successo per impararne qualcosa, quindi mi pongo un’altra domanda: sono gli asset più importanti difendibili?

Perché la domanda che un responsabile della sicurezza si deve fare è questa. E una risposta possibile ritengo sia la classica (un po’ abusata e spesso fraintesa): trust no one. Non fidarsi di nessuno non vuol dire entrare in paranoia o, peggio, scivolare nella sindrome di Fort Apache.

Vuol dire invece porsi domande, avere sempre dubbi, non fidarsi di questo o quel vendor per “metterci una pezza”, ma capire cosa si sta facendo per proteggere le proprie informazioni. Vuol dire calcolare quanto più possibile i rischi e cercare di avere delle contromisure adatte, cercare di prevedere uno scenario di incidente possibile (verifico *sempre* le CRL? (ehh….)? Uso solo il token OTP senza una forte password policy? Ho delle procedure di blocco in caso di incidente? Faccio penetration test periodici per verificare la sicurezza delle mie applicazioni web?). E poi, ultimo ma non per importanza, so (ri)guadagnarmi la fiducia dei miei clienti? So comunicare correttamente quello che è successo? Perché molte banche usano un token RSA ad esempio, quante hanno informato i loro clienti dei rischi, o preso contromisure tipo far cambiare le credenziali? A me non risulta molto…

Insomma, non fidarsi vuol dire soprattutto fare bene il proprio mestiere. Perché alla fine di quello si dovrà rendere conto, quando le cose andranno male. Ed è molto probabile che ci vadano, quindi chissà cosa stanno raccontando ora ai loro capi i responsabili della sicurezza di RSA, Comodo e Oracle… Avranno fatto bene il loro mestiere?

Bye!

P.S.: Ah, ovviamente nel frattempo ci sono stati anche un pesantissimo DDOS a WordPress.com (forse per colpire un singolo sito) e un furto di email di utenti di Play.com da una società di servizi, tra gli altri… la storia avanza…

Security Summit 2011 – I keynote

Logo Security SummitTerminato il Security Summit di cui avevo già parlato, si possono trarre le conseguenze e riflettere su quanto discusso nei tre, intensi, giorni del convegno.

Premetto che questa terza edizione ha confermato la qualità di questo evento. Grande partecipazione di pubblico, e un’agenda davvero ricca di percorsi adatti alla professionalità di molti.

Detto questo vorrei discutere dei tre keynote del Summit, con ospiti internazionali portati come al solito da nobody.

Aggiornamento: il Security Summit ha pubblicato i propri atti, ho aggiunto le slide dei keynote, cliccate sui nomi degli speakers.

Jon Orbeton

Uno degli esperti del team anticrimine di PayPal ha aperto il Summit con quello che ritengo essere il keynote più interessante. Orbeton ha presentato i metodi e gli strumenti con cui eBay/PayPal proteggono i propri interessi e i propri clienti. Quella che potrebbe essere una cosa inventata, alla Penelope Garcia per intendersi, è in realtà un’attività quotidiana e molto, molto interessante. Orbeton ha illustrato le principali tecniche di OSINT, mostrando il loro utilizzo in casi reali, che molto spesso hanno portato ad arresti da parte delle forze dell’ordine.

Questo è stato uno dei punti chiave del suo intervento: la collaborazione con le forze dell’ordine. Negli Stati Uniti tale tipo di collaborazione è molto diffusa, sia perché strutture come FBI sono molto ricettive in tal senso, sia perché le società hanno una forte spinta a sopperire alle scarse risorse delle polizie, e raggiungere più velocemente l’obiettivo di fermare il truffatore/spammer/cyber-criminale che sia.

Questo tipo di interventi avviene molto più spesso di quanto non possiamo pensare noi, nemmeno a farlo apposta proprio in questi giorni è uscita la notizia che l’anticrimine di Microsoft, in collaborazione ovviamente con le forze dell’ordine USA, ha pesantemente colpito la botnet Rustock. Quindi non stiamo parlando di fantascienza, ma di mondo reale.

Le tecniche presentate, che vanno dal reverse engineering all’analisi di dati presenti e soprattutto passati su forum, domini, informazioni su società e molto altro, non sono in sé complesse da padroneggiare, ma prevedono soprattutto una forma mentis molto avanzata.

Questa è infatti la nota dolente, sia che le società IT italiane (europee?) non hanno un team che si occupa di questo ( per lo meno non lo fanno in modo palese, e la collaborazione in questo senso, come detto da Orbeton, è essenziale), e comunque le polizie nazionali non sono così reattive. Come fatto emergere da Chiesa stesso, quando ha chiesto se c’erano esponenti delle forze dell’ordine in sala. Nessuno ovviamente.

Bruce Schneier

L’intervento della Security Rockstar era sicuramente quello più atteso del Summit, e quello con più affluenza (erano state unite più sale). E, amaramente, è stato quello che mi ha deluso di più.

L’intervento di Schneier è stato poco più di un’intervista o, peggio, una conversazione. Focalizzato sullo stato del Cyber Warfare o guerra cibernetica, Bruce non ha illuminato così tanto la platea come ci si sarebbe atteso da una personalità di tale livello. Certo non chi segue quotidianamente il suo blog. Ma forse il punto è proprio questo, l’intervento era destinato ad ascoltatori di un livello un po’ troppo alto.

Allo stesso tempo non hanno aiutato la mancanza di interazione (ha parlato da solo) e soprattutto la mancanza di slide, che avrebbero aiutato a fissare meglio certi concetti. Anche lo spazio dato alle domande non è stato molto ampio, tanto che l’intervento è terminato con qualche minuto di anticipo (!!).

Veniamo comunque ai contenuti. Uno dei punti chiave presentati è stato senza dubbio il fatto che, a differenza delle guerre tradizionali, la cyber war può (ed è) essere portata avanti non solo da nazioni. Questo perché necessita di relativamente pochi mezzi, ma di molte conoscenze e molta determinazione. Non necessita invece di centinaia di migliaia di soldati, aerei, carri e munizioni.

L’effetto però non è tanto diverso, per lo meno in un’ottica di prevenzione di altre attività, ovvero se si vuole bloccare una nazione, o impresa, da fare una determinata azione.

Prendiamo ad esempio quello che è successo in Estonia qualche anno fa. Un’azione di questo tipo, fatta ad esempio da un gruppo di hacktivist, può realmente cambiare la rotta politica di una nazione. E questo può essere molto più efficace di una guerra “tradizionale”.

La cosa grave, ovviamente, è che azioni di questo tipo possono essere effettuate sia da nazioni, ovviamente, ma anche da grosse corporation. Magari per influenzare un governo a fare certi contratti… La situazione è abbastanza grave.

Il paragone infatti è proprio con le classiche azioni di guerriglia, ovvero piccole azioni tattiche che però possono creare da un lieve fastidio ad un danno enorme come bloccare un paese.

Schneier ha poi ricordato come questo tipo di attacchi, come lo Stuxnet che tanto ha girato sui giornali nei mesi passati, non è assolutamente nuovo. Un attacco di questo tipo è stato sferrato contro la Russia già nel 1982, ad opera del governo americano. E se ora questa cosa la potessero fare semplici gruppi di interesse?

Gli attacchi contro le infrastrutture SCADA ormai sono all’ordine del giorno, anche fortunatamente sui media generalisti, e temo che ne sentiremo sempre più parlare in futuro…

Philippe Langlois

Il keynote conclusivo è stato affidato al fondatore di P1 Security, ed esperto imprenditore e speaker su temi di sicurezza. Langlois a dire il vero era presente già dal primo giorno, come guest star di diversi talk di Chiesa e altri, avendo competenze trasversali su diversi argomenti.

La parte che ho trovato più interessante della sua analisi è stata l’attenzione posta sul livello di ricerca che ha raggiunto la criminalità informatica. Le dinamiche dell’underground criminale hanno portato infatti ad una vera criminalizzazione della ricerca.

Fin troppo spesso infatti un bravo ricercatore di sicurezza, magari se sottostimato o poco considerato, può rivolgersi a gruppi criminali. Anche qui non stiamo parlando di ipotesi, ma di fatti. Gli elementi portati, sia in questo intervento che in altri del Summit, hanno mostrato come le tecnologie che ora si diffondono dappertutto sono utilizzate da anni nel cyber crime. A partire dal cloud ad esempio, che sia per preparare e diffondere un malware o noleggiare una botnet (50$ al giorno!).

Servizi come VirusTotal, ad esempio, vengono usati per quotare un determinato malware. Ovviamente meno viene identificato, più aumenta il suo valore…

Anche qui insomma le prospettive non sono buone, e se non vengono condivise queste analisi, si potrebbe rimanere troppo indietro nel tentare di difendere le proprie infrastrutture.

Questa era quindi l’analisi dei keynote del Security Summit, presto anche un commento sugli altri interventi a cui ho assistito.

Bye!

E alla fine caddero entrambi…

… ma Safari per primo.

Avevo parlato qualche giorno fa del pwn2own e della strategia di Microsoft, ora a evento concluso si possono analizzare i risultati, con un occhio di riguardo ad Apple.

Sì perché anche stavolta il primo a cadere è stato il browser della mela, non sotto i colpi della coppia Miller/Dai Zovi, ma da parte del team di Vupen Security. Nonostante i disperati tentativi di Apple di inviare un gran numero di patch, Vupen scriveva sul suo Twitter:

Apple has just released Safari 5.0.4 and iOS 4.3 a few minutes before the pwn2own contest. This breaks some exploits but not all !!

Chiarisco una cosa. I browser vengono “freezati” qualche giorno prima della gara, questo per permettere ai partecipanti di avere una piattaforma certa su cui fare i test. Ora i rilasci massivi di patch non servono ovviamente ad impedire il pwn, ma piuttosto a far dire al produttore “ah, vedi, quello 0day l’ho già risolto ieri!“. Questa è ovviamente un’utopia, poiché un ricercatore ha diverse vulnerabilità nel caricatore, quindi alla fine riuscirà lo stesso a bucare il sistema. Magari ci metterà solo più tempo (o magari no, se usa subito quella buona). Quindi anche qui la corsa al fix è totalmente inutile, se non dannosa per l’immagine.

Per quanto riguarda la sicurezza infatti, Apple non è mai stata molto attenta aperta. Questo nasce principalmente dal fatto che fino a OS X, MacOS è stato un sistema molto chiuso e particolarmente sicuro. Anche perché non c’era molto hype attorno all’azienda di Cupertino.

Poi torna Jobs, c’è l’esplosione nel mercato consumer e tutti iniziano a sfoggiare il logo della mela argentata. E tutti iniziano ad interessarsi ai sistemi Apple, che nel frattempo sono diventati Unix-like, quindi più aperti, più a rischio…

Proprio i due ricercatori citati sopra, Charlie Miller e Dino Dai Zovi, vincitori dei tre precedenti pwn2own contro i sistemi Apple, hanno recentemente rilasciato una lunga e dettagliatissima intervista al sito The H Security, in cui partono subito dicendo:

From a targeted attack, however, it has been my experience that finding and exploiting vulnerabilities in Mac OS X is significantly easier than doing so in modern Windows systems (Vista and 7).

E questo è il primo problema. Perché magari è più “sicuro” Mac OS relativamente allo share di mercato inferiore a Windows, ma Microsoft ha fatto sicuramente più passi avanti nella sicurezza dei suoi software.

Parliamoci chiaro Apple dettaglia bene le falle di sicurezza coperte da un aggiornamento, però nel contempo, puntando come sempre a lanci di marketing, non riesce a trasmettere un immagine trasparente agli utenti. Non ci sono bollettini, non ci sono blog e comunità.
Questo porta spesso a pensare di essere più sicuri di quanto in realtà non sia, se poi aggiungiamo qualche passo falso dovuto a mancanza di strategia, appunto, la situazione non è delle migliori.

Il vivere di rendita spesso può provocare molti più danni di quanto non sembri, sia perché se si espongono troppe superfici di attacco prima o poi si viene bucati, sia perché cullarsi sugli allori spesso fa scordare che bisogna lavorare sempre duro.

La chiusura totale può tuttavia anche portare dei vantaggi. Penso all’AppStore ad esempio. Per accedere alla vetrina delle applicazioni per iOS bisogna sottoporre l’applicazione al vaglio di Apple, che ne certifica la bontà. Questa, parliamoci chiaro, è una feature di sicurezza, vedi quello che è successo all’Android Market. Certo, come al solito la chiusura di Apple ha portato numerosi problemi in passato (e molti malumori tra gli sviluppatori anche oggi), però come dicono gli stessi Miller/Dai Zovi:

Having a central location for applications that is monitored in some way by Apple makes it harder for malware authors to get their code out if users start only using the Mac App Store for downloads.

Certo, se poi andiamo di jailbreak e programmi craccati, allora fatti vostri… perché alla fine l’utente è sempre la minaccia più grave.

Quello che mi auguro di vedere da Apple è una maggiore apertura sui temi di sicurezza, perché l’obscurity, ha i suoi vantaggi, ma secondo me continua a dimostrare un timore di fondo nell’affrontare la materia. E questo è indice di scarsa maturità.

Bye!

Spiegare la sicurezza al top mangement

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…