Anche le più moderne infrastrutture di rete provviste di tecnologie e sistemi di sicurezza all’avanguardia possiedono al loro interno punti deboli: per tale motivo, tutte le grandi aziende necessitano di una periodica di attività di vulnerability assessment per scoprire eventuali falle di sicurezza e verificare la compliance alle policies e procedure interne in tutte le aree di interesse.
Le dimensioni dell’azienda influiscono in maniera preponderante sul modo in cui tali attività devono essere condotte. Maggiore è il numero di reti e sistemi da testare, più difficoltosa risulta la gestione centralizzata di tali asset, con conseguenti discostamenti dagli standard di sicurezza che si vogliono raggiungere.
Una procedura definita e uniforme per l’esecuzione dei vulnerability assessment risulta dunque necessaria per poter procedere in maniera efficiente e rispettare le scadenze imposte dal cliente.
Indice degli argomenti
Vulnerability assessment nelle grandi aziende: cos’è, a cosa serve
Il vulnerability assessment (VA) nelle grandi aziende mira a identificare le criticità connesse agli asset aziendali in analisi, dando evidenza del modo in cui queste possono causare un danno alla società e fornendo valide azioni di rimedio.
Non esiste una procedura universalmente definita per il loro svolgimento, poiché le attività svolte dall’analista dipendono dalla tipologia e dal numero di servizi previsti dal contratto stipulato con il cliente.
Queste possono includere esclusivamente un vulnerability scanning delle reti o andare più in profondità, prevedendo assessment dei sistemi operativi (OSSA) e dei database.
A questi possono aggiungersi analisi delle reti wireless e delle web application, fino ad arrivare all’esecuzione di penetration test al fine di testare la resistenza delle reti ad attacchi tramite tecniche di exploitation.
Si raccomanda, dunque, di esplicitare nel contratto che viene stipulato quali servizi vengono offerti per le attività di Vulnerability Assessment, anche per facilitarne la comprensione ed evitare qualsiasi equivoco.
Un piano di vulnerability assessment nelle grandi aziende
Sebbene non esista una procedura tecnica univoca per l’esecuzione del vulnerability assessment nelle grandi aziende, è comunque possibile definire una metodologia standard, modellabile in base alle esigenze del business e nel rispetto dei controlli contenuti all’interno degli standard di sicurezza IT universalmente riconosciuti.
Tale metodologia si compone di tre fasi basilari, di seguito riportate:
- primo incontro con il cliente e compilazione del questionario;
- esecuzione delle attività tecniche;
- stesura del piano di rimedio.
Un framework operativo di riferimento
A questo scopo, viene definito un framework di riferimento al fine di schematizzare le azioni che compongono tutte le fasi del vulnerability assessment.
Le aree che sintetizzano il framework possono essere rimodellate in base alle esigenze del cliente che ne richiede l’esecuzione, tenendo conto dei controlli previsti dagli standard di sicurezza.
A titolo esemplificativo, viene riportato il seguente framework adattato in base a delle ipotetiche esigenze contrattuali:
Area A: Information Security | Area B: Endpoint Security | Area C: Infrastructure Security |
A.1 Data Classification | B.1 Endpoint Protection Platform (EPP) | C.1 Firewall |
A.2 Data Encryption | B.2 Endpoint Detection and Response (EDR) | C.2 Remote Access (e.g., SSH, VPN) |
A.3 Data Loss Prevention (DLP) | B.3 Patch management | C.3 Intrusion Prevention and Detection Systems (IDS/IPS) |
– | B.4 Log management (SIEM) | C.4 Web Content Filtering (proxy) |
La suddivisione del framework in cluster semplifica inoltre la comprensione del piano di rimedio che verrà consegnato al cliente, il quale può non possedere adeguate conoscenze in ambito cyber security.
Tale struttura facilita altresì l’identificazione delle vulnerabilità emerse in fase di assessment, le quali vengono in tal modo catalogate ed inserite nella rispettiva area di competenza.
Tutte le fasi di un vulnerability assessment
Vengono ora descritte le tre fasi del Vulnerability Assessment precedentemente elencate.
Il primo incontro con il cliente e la compilazione del questionario
Il vulnerability assessment non si compone di sole attività tecniche. Prima di queste, è utile possedere una conoscenza di alto livello delle reti e dei sistemi da sottoporre ad analisi.
Un meeting tecnico con un responsabile del laboratorio da esaminare e i relativi amministratori di rete e di sistema, antecedente al giorno dell’assessment, ha numerosi vantaggi. In primo luogo, la riunione concede un’opportunità all’analista di illustrare preventivamente tutte le attività tecniche che egli dovrà condurre nel laboratorio in fase di VA.
I responsabili di laboratorio hanno così modo di predisporre l’ambiente all’esecuzione dell’assessment e pianificare le funzioni svolte in loco evitando che quest’ultimo abbia impatti sul processo produttivo.
Inoltre, l’analista ha modo di prendere visione dell’infrastruttura di rete nel laboratorio, venendo a conoscenza del modo in cui questo si interfaccia ad Internet o alla rete aziendale, se sono presenti dispositivi network di archiviazione, e molto altro.
Risulta utile, in questa fase, sottoporre un questionario ai referenti intervistati, scritto coerentemente in base alle aree del framework utilizzato.
Tutte le informazioni che non è possibile acquisire durante le attività tecniche devono essere richieste a tu-per-tu durante un colloquio tecnico.
Si parla ad esempio del livello di classificazione del dato trattato, dell’esposizione su reti esterne, dei software in uso, della frequenza di vulnerability scan, delle modalità di collezionamento dei log, e molto altro. Una o più domande per ogni area del framework precedentemente descritto compongono il questionario da sottoporre ai responsabili del laboratorio.
Malgrado si tratti di attività prettamente tecniche, l’analista deve cercare di non invadere la “comfort zone” dei responsabili con cui sta svolgendo questa prima fase del vulnerability assessment.
Si noti che ci si può trovare di fronte a personale che non possieda adeguate conoscenze in ambito cyber security. Dunque, è sempre un ottimo punto di partenza cercare di partire dal basso essendo il più chiari possibile quando vengono illustrate le azioni tecniche.
Oltre a ciò, bisogna evitare qualsiasi domanda “sgradevole” che possa mettere in imbarazzo il cliente. Ad esempio, è inopportuno chiedere se venga rispettata la password policy aziendale.
In alternativa, potrebbe essere domandato se le password utilizzate sui sistemi sono robuste e regolarmente aggiornate, inserendo poi in allegato nel piano di rimedio alla relativa sezione (Data Encryption) un link alla procedura aziendale in essere.
Dopo aver sottoposto l’interlocutore a tale sondaggio, è opportuno richiedere anticipatamente ove possibile l’asset inventory dei sistemi in gestione nel laboratorio, oltre ai piani di indirizzamento e i disegni di rete.
Tutti questi sono “nice-to-have” dei quali l’analista può fare tesoro, poiché semplificano di molto le attività da svolgere il giorno del vulnerability assessment.
Esecuzione delle attività tecniche
Una volta reperite tutte le informazioni necessarie, non resta che entrare in campo e iniziare a svolgere le attività tecniche. In base a quanto stipulato durante il contratto, i servizi offerti possono essere molteplici e variegati.
Nel caso in cui si debba condurre anche un OSSA (Operating System Security Assessment), l’analista ha il compito di analizzare nel dettaglio i sistemi presenti nel laboratorio.
Per velocizzare le operazioni e svolgere il compito in parallelo con le analisi di rete, egli può servirsi di alcune chiavette USB. Su di esse sono da inserire degli script in grado di acquisire il maggior numero di informazioni possibili dai sistemi su cui sono lanciati.
Normalmente, i codici con cui questi programmi di information gathering vengono scritti prevedono la creazione di file text su sui viene reindirizzato l’output dei comandi automatici eseguiti sulle shell di sistema.
Si tratta dunque di file batch per sistemi Windows e shell script per sistemi UNIX-based. L’analista può scrivere personalmente il loro codice o cercare tra le più famose repository di codice in Internet, le quali devono essere vagliate attentamente.
Pur potendo prevedere analisi di sistemi operativi, database o altro, il servizio cardine che non può mancare nel VA è la scansione delle vulnerabilità. Senza quest’ultimo, non si può parlare di vulnerability assessment.
Tuttavia, per essere valido, questo deve essere anticipato da attività di network mapping, OS fingerprinting e port scanning specifiche, se non già previste dalla scansione. Si può optare per soluzioni open source come il noto scanner OpenVAS, o i più moderni prodotti a pagamento come Nexpose e Nessus. L’importante è che i sistemi in rete vengano scansionati accuratamente.
Se presenti reti wireless, l’analista si può munire di un’antenna da collegare alla propria sonda e lanciare Kismet, il packet sniffer per le reti 802.11 senza fili. Altri tipi di assessment per aumentare il raggio di azione del VA sono analisi sulle Web application e i phishing assessment, fino ad arrivare ad attività di penetration test.
Stesura del piano di rimedio
L’analista è ora in grado di fotografare la postura di sicurezza del laboratorio e progettare un piano di rimedio per colmare tutti i discostamenti dalle policy aziendali ed evitare che accadano incidenti informatici.
Tutte le criticità emerse e le vulnerabilità riscontrate dallo scanner devono essere catalogate ed inserite nella rispettiva area di competenza presente nel framework.
Ad esempio, l’utilizzo di protocolli non cifrati rientra in “Data Encryption”, un filtraggio delle URL non adeguato e blacklist non aggiornate in “Web Content Filtering”, licenze antivirus scadute in “Endpoint Protection Platform”, la mancanza di software DLP in “Data Loss Prevention”, e così via.
A ogni vulnerabilità dovrà poi essere associata una possibile soluzione, un metodo per diminuire il rischio identificato, o anche solo un link a del contenuto informativo da consultare o software aziendale da scaricare.
Il documento da consegnare al business deve essere chiaro e ben leggibile. Una struttura definita come quella appena descritta rende la comprensione di questo accessibile e le misure applicabili da chiunque.
Se l’analista lo ritiene necessario, può inserire l’infrastruttura di rete AS-IS e la relativa nuova soluzione TO-BE proposta, accompagnata da una spiegazione di tutti i motivi per i quali l’attuale contesto è considerato insicuro e da rimodellare.
Seguendo una procedura standardizzata come quella descritta, una volta terminati tutti i Vulnerability Assessment nei laboratori del cliente, l’analista ha la possibilità di confrontare tutti gli scenari incontrati grazie alla base comune appena costituita.
Questa può inoltre essere utilizzata per effettuare GAP analysis e definire nuove infrastrutture di rete globali che raggruppino tutti gli ambienti precedentemente incontrati, in base alle esigenze del cliente.
