hit counter
Un po' di teoria sull'analisi di rischio delle vulnerabilità Microsoft - 1a puntata - NonSoloSecurity Blog di Feliciano Intini - Site Home - TechNet Blogs

NonSoloSecurity Blog di Feliciano Intini

Notizie, best practice, strategie ed innovazioni di Sicurezza (e non solo) su tecnologia Microsoft

Un po' di teoria sull'analisi di rischio delle vulnerabilità Microsoft - 1a puntata

Un po' di teoria sull'analisi di rischio delle vulnerabilità Microsoft - 1a puntata

  • Comments 13
  • Likes
 

A fronte del bel pacchetto di bollettini di sicurezza emessi ieri sera, conto di fornirvi le considerazioni sintetiche per supportarvi nell'analisi di rischio. Prima però di poter procedere in tal senso credo sia opportuno anticiparvi in questo post i criteri di analisi che utilizziamo nel PCfS (in attesa di raccontarvi di più del mio team trovate la definizione in questo post) per stimare la criticità di una data vulnerabilità Microsoft, in modo che possiate comprendere meglio le indicazioni che vi darò nel prossimo post.

Il punto di partenza è definire un range di criticità e individuare l'estremo superiore di questa scala: qual è la vulnerabilità teorica più critica a cui si possa pensare ? Facile: è quella in grado di avere un impatto significativo in termini di danno causabile, su un numero elevatissimo di sistemi (tipicamente su scala internazionale), con la massima velocità di propagazione immaginabile e nel modo più automatico possibile. Abbiamo già avuto un esempio di malware con molte di queste caratteristiche: ricordate SQL Slammer ? E' stato calcolato che quando apparve SQL Slammer nel gennaio 2003 furono infettate circa 75.000 sistemi nel primo minuto e il 90% dei sistemi vulnerabili a livello mondiale fu infettato nei primi 10 minuti di vita del malware. Per fortuna il numero assoluto dei sistemi vulnerabili non era elevatissimo, trattandosi di una vulnerabilità di SQL/MSDE.

Ecco, definite le caratteristiche della vulnerabilità peggiore in assoluto, deriviamo i parametri che ci permettono di misurare questa pericolosità: i principali elementi che ci permettono di fare una prima valutazione del rischio sono i seguenti

 

  • Impatto della vulnerabilità: remote code execution (il peggiore), privilege elevation, information disclosure, spoofing…
  • Sfruttabilità da remoto: remote exploit (il peggiore), local exploit
  • Attacco autenticato o meno, e con quali privilegi: anonymous attack (il peggiore), authenticated attack con bassi privilegi, e authenticated attack con alti privilegi
  • Privilegi sfruttabili: Local System (il peggiore), Local/Network Service, quelli dell'utente loggato interattivamente, nessuno

 

Ve ne sono ovviamente altri che permettono di qualificare ancora meglio la gravità di una vulnerabilità, ma questa quaterna di parametri da sola è già un ottimo indicatore: se, per esempio, avessimo una vulnerabilità con i peggiori valori per tutti e quattro i parametri indicati … potremmo cominciare a preoccuparci seriamente! Certo prima di entrare in fibrillazione (… in realtà un security professional dovrebbe sempre avere la virtù del self-control più sviluppata degli altri …) dovremmo verificare la presenza di eventuali fattori che mitigano il rischio (sono gli altri parametri di cui parleremo una prossima volta), ma intanto questa sarebbe una vulnerabilità da tenere in buona considerazione!

Detto questo vi lascio alla lettura del prossimo post (spero di ultimarlo in fretta in modo che possa esservi subito d'aiuto) … A presto !

Comments
  • L'obiettivo che tipicamente mi prefiggo con i post di analisi sui bollettini è quello di aiutarvi a valutare il livello di rischio degli stessi, in modo che possiate meglio decidere con quale urgenza operare gli aggiornamenti dei sistemi. Nel caso del

  • Cosa c'è di meglio di un bel ciuffo (stavo per dire un altro termine ...) di bollettini di sicurezza da analizzare al rientro dalle tanto desiderate (brevi) vacanze pasquali per far risalire l'adrenalina al 100% ed evitare la "sindrome da rientro" ? Scherzo,

  • Rieccoci all'appuntamento mensile con i bollettini di sicurezza di Microsoft. Come al solito cercherò di analizzarli in modo da aiutarvi a valutare se vi possa essere un diverso livello di urgenza nella loro installazione: a prima vista il fatto che questi

  • Scusate il ritardo: questo mese la concomitanza dell'evento Technet Security Day a Roma di ieri e il tradizionale Patch Tuesday (ormai è chiamato così il giorno di emissione dei bollettini di sicurezza) mi hanno creato qualche problema logistico, visto

  • Periodicamente Microsoft crea delle fix di sicurezza (se necessarie) a fronte di vulnerabilità riscontrate.

  • Eccovi le considerazioni rilevanti per i bollettini di luglio, con il solito riferimento al mio post N°10 per un background sull'approccio all'analisi di rischio e alla tabella seguente che sintetizza le 11 vulnerabilità corrette dai 6 bollettini:

  • Esaminiamo i bollettini in due gruppi e incominciamo ad analizzare quelli correlati con la famiglia Windows.

  • Starete pensando, ma Feliciano cos'ha mangiato oggi ?? Sta sparando post a raffica … va bene aumentare la frequenza … ma così è un po' troppo ! Tranquilli: ho solo pensato che queste brevi analisi di rischio magari servono subito per esservi d'aiuto,

  • Eccovi le considerazioni rilevanti per i bollettini di agosto, con il solito riferimento al mio post

  • Sintesi : nonostante la significativa serietà dei 2 bollettini di questo mese che risolvono 3 vulnerabilità

  • La parola che molti clienti diranno alla vista di questo annuncio è: finalmente! L'attività

  • Da quando mi occupo di analizzare e fornire consulenza sui bollettini di sicurezza Microsoft (quindi

  • Come anticipato lo scorso venerdì, questa emissione di sicurezza di febbraio 2009 vede la pubblicazione

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment