Un Internet più sicuro farebbe comodo a tutti e questo Google lo sa. Per questo una parte dei suoi ricercatori lavorano proprio nel settore della sicurezza, cercando falle e informando poi i vari vendor dei risultati e delle possibili contromisure da adottare.
Il problema è che spesso, poi, le società di software contattate e messe al corrente del problema non reagiscono prontamente come sarebbe necessario e allora Google spinge perché i tempi di intervento diventino brevissimi.
Sapere che nel proprio software c'è una falla di sicurezza e non correre ai ripari in tempi brevissimi è una tecnica abbastanza suicida. Prima o poi arriverà il momento in cui una vulnerabilità verrà sfruttata e allora ci si renderà conto che, tutto sommato, gli avvertimenti di Google non erano poi tanto campati in aria...
"Sette giorni sono pochi per aggiornare i software, ma dovrebbe essere un tempo sufficiente almeno per pubblicare avvisi o possibili soluzioni tampone, come il disabilitare temporaneamente un servizio, circostanziare gli accessi o contattare il produttore per maggiori informazioni", si legge nel blog.
La prima reazione a queste affermazioni è venuta da Gunter Ollman, CTO di IOActive, che ha dichiarato che per una web company come Google, sia facile sviluppare e rilasciare patch a tempo record, ma anche che "nel 95% delle altre aziende di sviluppo software tutto ciò è impossibile da realizzare per via dei rapporti tra server, device ed esigenze specifiche dei clienti". Ollman addirittura vorrebbe che Google ed altri web service intervenissero con patch entro dodici ore dalla scoperta di vulnerabilità 0-day, ma al tempo stesso darebbe ben più di 7 giorni alle compagnie di software tradizionali che vendono prodotti a livello enterprise per sistemare gli eventuali problemi.
Di diverso parere è Alex Stamos, esperto in infrastrutture network e sicurezza: "penso che le deadline proposte (da Google) siano ragionevoli e che l'articolo di Ollman non abbia compreso il nocciolo del problema. È vero che sette giorni non sono sufficienti per risolvere falle su prodotti embedded e fatti su misura di ciascun cliente, ma per prendere le prime contromisure sì".
E prosegue: "l'obbiettivo dei sette giorni è quello di dare alle vittime potenziali, la capacità di individuare e mitigare le vulnerabilità tramite meccanismi che non siano necessariamente lo sviluppo repentino di una patch, ed al tempo stesso di misurare le responsabilità del ricercatore verso i bisogni dell'utente finale". Del resto, qui non si tratta di dare o meno sette giorni di tempo, qui si parla di vulnerabilità: più tempo restano aperte, maggiori sono le possibilità che vengano sfruttate. Sette giorni non sono poi così pochi per dire ai propri clienti: "aspettate un paio di settimane per utilizzare questa parte del servizio".