Come promuovere la sicurezza nei prodotti commerciali giovedì 9 febbraio 2012
Posted by andy in Information Security.Tags: qualità, riduzione costi, sicurezza all'origine, sicurezza nel codice
add a comment
Giorno dopo giorno le aziende ed i sistemi di organi istituzionali sono sempre più oggetto di attacchi da parte di malintenzionati e di attivisti politici.
Proteggersi da questi attacchi è divenuta un’attività sempre più onerosa, sia come competenze richieste, sia come costi da sostenere.
Approfondendo, ci si rende conto che i costi che l’azienda deve sostenere sono, in buona parte, alla necessità di mantenere allo stato dell’arte la configurazione dei propri sistemi e le competenze del proprio personale, oltre che alla necessità di ‘acquistare’ attacchi controllati sotto forma di assessments e penetration tests.
Un altro costo da mettere in conto, seppur difficilmente quantificabile, è il danno derivante da attacchi effettivamente riusciti e la difficoltà, se non l’impossibilità, di assicurarne il rischio, in quanto non sono disponibili sufficienti dati, e sufficientemente attendibili, perché le assicurazioni possano stabilire premi adeguati.
Se le aziende non sono di fatto in grado di proteggersi adeguatamente, e se le compagnie di assicurazione non possono essere d’aiuto in caso di incidente, esiste qualche modo per ridurre e/o trasferire il rischio, e se si, a chi?
Facendo mente locale sull’attuale ciclo di gestione della sicurezza delle informazioni, non possiamo non notare che in buona parte questa ruota intorno ad un gran numero di prodotti commerciali (i cosidetti ‘off the shelf‘: router, firewall, IDS, IPS, sistemi operativi, web server, RDBMS, …).
Di fatto, le organizzazioni spendono una notevole parte del proprio budget per la sicurezza non tanto nell’acquisto di prodotti, ma nella loro personalizzazione, aggiornamento e manutenzione.
E questo accade perché in realtà i produttori riducono i propri costi trasferendoli sul cliente.
Di fatto, distinguiamo tra prodotti consumer e professionali basandoci semplicemente sul prezzo e su qualche eventuale ‘bollino di qualità‘ eventualmente riportato sui manuali.
Come i giornali dimostrano, né il prezzo né i bollini risolvono i nostri problemi: dobbiamo per forza passare il nostro tempo ad informarci ed aggiornarci, a scaricare ed applicare patch, eventualmente fermando i sistemi e creando disservizi al nostro business, eventualmente sostenendo anche i costi per ambienti di test ove provare le patch prima dell’effettivo deployment negli ambienti di produzione.
Sarebbe quindi interessante invertire la tendenza a trasferire il rischio, riportandolo all’origine, là dove il prodotto nasce.
È vero che la perfezione non esiste, ma quante delle patch di sicurezza che applichiamo periodicamente avrebbero potuto essere implementate già durante la progettazione e realizzazione del prodotto?
L’ideale sarebbe quindi quello di innescare un circolo virtuoso, con l’obiettivo di realizzare prodotti talmente affidabili da poter tagliare drasticamente i costi di manutenzione, spostando le risorse verso la progettazione.
Ne consegue naturalmente la domanda: come incentivare l’implementazione della sicurezza già alla fonte, invece che rimandarla alle fasi post-market? Che tradotta in un’altra forma, potrebbe essere: come convincere i clienti a spendere di più al momento dell’acquisto?
Certamente qualsiasi organizzazione acquisterebbe molto volentieri, ed anche ad un prezzo superiore a quello attuale, prodotti che forniscano non solo garanzie sulla sostituzione dell’hardware guasto, ma anche sull’aggiornamento continuo a cura del fornitore, ed un’assicurazione per coprire i danni derivanti dallo sfruttamento di vulnerabilità dei propri prodotti.
All’organizzazione rimarrebbero, di fatto, soltanto i costi per la progettazione della propria sicurezza e per la personalizzazione dei prodotti acquistati.
Occorre quindi lavorare sui seguenti aspetti:
- aiutare i clienti (e specificamente il management) a valutare i costi complessivi (TCO) della sicurezza, fornendo degli strumenti per quantificare i costi di aggiornamento e patching nel tempo (senza dimenticare almeno una quota di rischio per eventuali breaches);
- aiutare le compagnie di assicurazione a sviluppare prodotti assicurativi specifici per i danni derivanti da violazioni dei sistemi informativi sfruttando le vulnerabilità degli apparati e del software in commercio, creando così un mercato nuovo ed aprendo grandi opportunità commerciali, considerando quanto le tecnologie dell’informazione siano diventate pervasive e fondamentali per il business;
- aiutare i produttori a perseguire l’obiettivo commerciale del ‘prodotto più sicuro‘ (un po’ come già avviene nel settore automobilistico), sia sviluppando strumenti di verifica sempre più completi, sia promuovendo la disclosure di tutti gli incidenti dipendenti dai propri prodotti;
- spingere i produttori a corredare i propri prodotti con polizze di assicurazione per il cliente: una maggior sicurezza del prodotto comporterà quindi premi sempre più bassi ed una maggior competitività commerciale, non solo per il brand, ma anche per i prezzi.
In qualche modo, l’Europa sta effettivamente andando nella direzione dell’obbligo della disclosure dei data breach per le aziende (cfr. proposta di revisione della normativa europea del 25 gennaio 2012); la proposta presentata in questo articolo in realtà mira a pubblicare le effettive responsabilità, almeno quando queste siano riconducibili ad apparati o a software.
In conclusione, il miglior bollino di qualità per il cliente è la fiducia che il produttore dimostra di avere nell’affidabilità dei propri prodotti, attraverso le garanzie e le responsabilità che conferma di volersi assumere.
Intorno a questa fiducia possono crearsi grandi opportunità di risparmio per i clienti, maggiori opportunità di revenue per i produttori, ed aprirsi nuovi mercati per le compagnie di assicurazione.
La sicurezza nello sviluppo SW: come incentivarla giovedì 31 marzo 2011
Posted by andy in Information Security, Miglioramento.Tags: incentivazione, qualità, secure coding, sicurezza, sviluppo software
add a comment
Sempre più spesso leggo notizie in cui emergono incidenti (informatici, naturalmente!) derivanti da software sviluppato con pochi, o nulli, criteri di sicurezza.
Le lamentele vanno sempre in varie direzioni: i programmatori che pensano a tutto tranne che alla sicurezza, i project manager incapaci, le aziende che tagliano selvaggiamente su tutto, in primis sulla sicurezza …
Insomma, comanda il Time To Market ed il ribasso selvaggio …
Giusto o sbagliato che sia, il mercato attuale è così: il cliente non sa nulla di sicurezza, non è capace di valutare e confrontare le offerte, e peggio ancora non è capace di valutare i possibili danni derivanti da ‘incidenti informatici’.
E visto che ‘occhio non vede, cuore non duole’, si risparmia su tutto ciò che non si vede o non si conosce.
Ma il problema non è dei programmatori, o dei project manager.
Il problema è quello ribadito mille volte in mille articoli e blog diversi: pay peanuts, get monkeys.
Quello che manca è un ‘rating’ delle società che sviluppano software e, perché no? anche dei programmatori free lance.
Occorre introdurre nel mercato un meccanismo che dia visibilità ai clienti del fatto che lo sviluppo SW tenga conto o meno della sicurezza, e quanto.
Senza imbarcarsi in certificazioni di terza parte, che sono costose, ed in qualche misura si possono aggirare.
Varrebbe la pena predisporre una check-list dei principali aspetti della gestione della sicurezza nello sviluppo SW, di cui i clienti potrebbero richiedere la compilazione ai fornitori, che sarebbero così tenuti ad ufficializzare quali ‘controlli’ (nell’accezione inglese) implementano nel proprio processo di produzione SW.
I clienti potrebbero così confrontare i fornitori, e potrebbero paragonare i prezzi offerti in relazione alla sicurezza offerta.
Inoltre, in caso di incidente, il cliente potrebbe richiedere o meno la correzione dell’errore in relazione al fatto che il fornitore abbia o meno dichiarato i relativi controlli.
E a guardare più lontano, si potrebbe anche pensare di coinvolgere le assicurazioni, per la riduzione dei premi (ove applicabile).
Insomma, perché non puntare sullo scarico delle responsabilità? Se paghi per la sicurezza, hai diritto alla risoluzione dei problemi di sicurezza, altrimenti no.