Spectre e Meltdown sono solo sensazionalismo?

L’inizio dell’anno è stato sicuramente dominato dal caso Spectre e Meltdown: annunciato al pubblico l’ultima settimana del 2017, ha causato delle correzioni da applicare a tutti i sistemi operativi; l’essere un bug hardware, e pure diffuso tra varie piattaforme (Intel ed AMD, x86 ed ARM), implicava che nessuno era al sicuro.

Ma forse tutta questa furia non era giustificata. O meglio: il bug è sicuramente presente, e le conseguenze sono accertate, ma è la pericolosità effettiva da dover essere rivalutata. O almeno questo è quanto sostiene Hugh Darvall, direttore delle vendite di Flexera (società software Americana che produce anche InstallShield), in un post intitolato -non a caso- come questo: “Are Spectre and Meltdown just hype?”

Il post è breve, ed incentrato su una considerazione:

Through Secunia Research at Flexera, more than 121 vulnerability intelligence advisories were issued on Spectre and Meltdown. However, most advisories were scored below “Moderately Critical” (one to three out of a maximum score of five). As a matter of fact, 5 advisories scored “Highly Critical” (four out of five).

To put this in perspective, Secunia Research issued another 52 unrelated advisories scored “Highly Critical” in the two weeks following the public disclosure of Meltdown and Spectre. The vulnerabilities were found in widely used software.

Tramite Secunia Research, di Flexera, sono stati esposti più di 121 avvisi di vulnerabilità delle informazioni riguardanti Spectre e Meltdown. Tuttavia, molti degli avvisi avevano punteggio sotto il “Moderatamente Critico” (da 1 a 3 su una scala di massimo 5). Per dovere di cronaca, 5 avvisi erano “Altamente Critici” (4 su 5).

Per mettere la cosa in prospettiva, Secunia Resarch ha esposto altri 52 avvisi non correlati di livello “Altamente Critico” nelle due settimane seguenti l’annuncio al pubblico di Meltdown e Spectre. Le vulnerabilità sono state trovate in software di largo uso.

Quindi, il clamore mediatico è stato eccessivo, ma soprattutto la fretta – o la furia – per scrivere e rilasciare le patch non erano giustificate: il pericolo è (ed era) tutto sommato basso, o almeno non eccezionale.

L’articolo procede quindi a spiegare i tre passi da seguire per essere efficaci nell’affrontare un problema di sicurezza, soprattutto in ambito enterprise:

1. identificare i pericoli con spirito critico, valutando anche la fonte delle informazioni; identificare quindi la vulnerabilità maggiore, su cui concentrarsi
2. non cedere all’ansia e creare delle priorità;
3. approccio conservativo: applicare le patch in ambiente controllato, su un numero limitato di macchine di cui valutare le prestazioni pre e post. Questo serve anche per sapere se la patch non introduce problemi maggiori di quello che deve essere risolto…

E voi, cosa ne pensate?

Leggi il contenuto originale su Mia mamma usa Linux!