Valutare le vulnerabilità di un sistema con il diagramma V

Valutare le vulnerabilità di un sistema con il diagramma V

Valutare le vulnerabilità di un sistema con il diagramma V

Gli attacchi a un sistema informatico avvengono sfruttando una o più vulnerabilità presenti nel sistema. Come già discusso, le vulnerabilità spesso non sono note o non sono sotto il diretto controllo di chi ha il compito di amministrare la sicurezza del sistema.

La classificazione delle vulnerabilità che di seguito presento evidenzia in quale fase del ciclo di vita del sistema è stata introdotta una data vulnerabilità, permettendo quindi di attribuire con maggior chiarezza le responsabilità. Sono state individuate cinque classi di vulnerabilità, organizzate su tre diversi livelli di astrazione, che portano a un caratteristico diagramma a V.

Vulnerabilità funzionali (livello di specifica)

In ogni sistema operativo sono disponibili comandi potenzialmente pericolosi come ad esempio quelli per formattare un disco o per eliminare i file. Questi rappresentano una vulnerabilità per la loro intrinseca funzione, non perché siano stati progettati o implementati in modo scorretto. Analogamente qualsiasi altro programma o componente di rete che svolga compiti di questo genere costituisce una potenziale vulnerabilità per il sistema.

Vulnerabilità di progetto (livello progettista)

Queste vulnerabilità sono presenti a causa delle scelte prese in fase di progettazione. Ad esempio, la suite di protocolli TCP/IP, benché funzionalmente corretta, non è stata progettata tenendo conto delle esigenze di sicurezza che sarebbero emerse negli anni a venire: essa lascia spazio dunque ad un’ampia casistica di attacchi tra cui l’IP spoofing (la possibilità di falsificare l’indirizzo del mittente nei pacchetti IP) e il TCP SYN flooding (un particolare denial of service). Ancora, scegliendo un’architettura wireless nel progetto di una rete locale ci si espone a rischi di intercettazione. Più che “sviste” di progettazione, queste vulnerabilità sono il risultato di compromessi che il progettista ha compiuto tenendo conto oltre che dei requisiti di sicurezza, anche dei requisiti di efficienza, economicità e semplicità d’uso. Come abbiamo già avuto modo di puntualizzare, i primi sono spesso in conflitto con i secondi.

Vulnerabilità di implementazione (livello programmatore)

Un sistema, fosse anche privo di vulnerabilità a livello di progetto, può svilupparne durante l’implementazione, ovvero durante la scrittura del codice (se si tratta di software) o durante la realizzazione fisica (se si tratta di hardware). Questa è forse la categoria che contiene il numero più alto di vulnerabilità. Vi appartengono i cosiddetti bug di programmazione (buffer overflow, input non gestito correttamente, race conditions, ecc.), che opportunamente sfruttati possono causare comportamenti imprevedibili nel software e consentire all’attaccante di guadagnare accessi privilegiati al sistema o di provocarne il crash. Alla scoperta di una nuova vulnerabilità, le case produttrici di software solitamente si adoperano per rilasciare nel più breve tempo possibile una patch che corregge il problema. I bug possono essere presenti anche nell’hardware (ad es. nella CPU) o nel firmware di alcune periferiche (particolarmente critici sono i router e i modem).

Vulnerabilità di configurazione (livello amministratore di sistema)

Alle vulnerabilità già introdotte dai progettisti e dai programmatori, l’amministratore della rete può all’occorrenza aggiungere anche le proprie. Virtualmente, infatti, qualsiasi software può essere configurato per funzionare in un modo non sicuro. Le vulnerabilità più comuni in questa categoria, sono dovute a una inadeguata configurazione di router, firewall e server di rete, a una scorretta gestione degli account utente, al mancato aggiornamento dei pacchetti software, alla carenza delle attività di auditing e monitoring del sistema.

Vulnerabilità di utilizzo (livello utente)

Infine occorre prendere in considerazione le vulnerabilità introdotte dal comportamento degli utenti che accedono al sistema. Le più comuni sono: scelta di password facili da indovinare, gestione scorretta di informazioni critiche, mancato rispetto delle policy, esecuzione di software non sicuro o corrotto da virus o altro codice malizioso (come nel caso degli allegati di posta elettronica).

Standard per la classificazione delle vulnerabilità

Lo standard CVVS (Common Vulnerability Scoring System) fornisce un framework completo ed organico per descrivere le caratteristiche delle vulnerabilità e il loro impatto sul sistema informativo.

cvss_web

E’ attualmente utilizzato da migliaia di vendor (tra cui Oracle) all’interno dei loro periodici security bulletin.

Screenshot 07-2456491 alle 00.06.19