Sul fronte sicurezza, gli utenti stanno cambiando atteggiamento nella scelta delle aziende a cui affidare la valutazione della propria architettura di rete e procedono attraverso interventi mirati
Se si effettua una comparazione tra quello che avveniva tre anni fa nel mondo
It e quello che succede ora troviamo una differenza fondamentale: adesso è
il cliente a decidere cosa fare e soprattutto con i tempi e modi da lui previsti.
Questo succede anche nel settore delle vulnerabilità, ove le scansioni
indiscriminate effettuate su migliaia di indirizzi Ip hanno lasciato il posto
a interventi mirati, con una attenzione molto alta verso l’organizzazione
dei processi di analisi.
Ma cosa chiede il cliente nel dettaglio? Le richieste sono fondamentalmente
di due tipi: vulnerability assessment infrastrutturale e check applicativo.
Con il primo termine si indica un processo di scansione finalizzato alla verifica
delle vulnerabilità presenti su reti, sistemi e workstation (in questi
ultimi tempi anche mobile device). Di solito l’attività viene intrapresa
per due motivi: compliance con le normative vigenti (italiane e straniere) e
necessità di gestione del rischio. Per quanto concerne la compliance,
esistono, a seconda delle aziende impegnate nel processo, una o più normative
di riferimento. Alcune aziende con business negli Stati Uniti, per esempio,
intraprendono progetti di questo genere su ordine della sede centrale, per aderire
a normative quali la Sarbanes Oxley, o a progetti di normative a latere imposte
da business partner (ma anche da direttive specifiche) quali la Pci. Quest’ultima
viene richiesta sempre più non solo negli Usa (dove di fatto è
obbligatoria dal 2004) ma anche nel nostro paese, per chi deve gestire un elevato
numero di transazioni di carte di credito. Di solito in questi casi si agisce
secondo una procedura operativa generale, la quale diventa poi estremamente
approfondita e ripetuta ciclicamente secondo procedure decisamente più
rigide rispetto all’ordinario. Il motivo è che tutte le normative,
direttamente o indirettamente, richiedono un reporting estremamente dettagliato
e un conseguente (e appropriato) livello di controllo.
Leggermente diverso (sia pur compatibile con il precedente) l’approccio
alla vulnerabilità in un’ottica di risk management. In questo caso
si opera solitamente effettuando una prioritarizzazione degli asset da sottoporre
a scansione, da mantenere secondo un piano ben preciso. Se gli asset da valutare
sono in proporzione più importanti rispetto al primo caso, il cliente
è disposto a pagare anche un prezzo superiore alla media, ma richiede
un servizio parimenti di qualità. Esiste poi una categoria allo stato
residuale ma sicuramente in aumento: quella degli assessment verticali su applicazioni
proprietarie (o custom). Si tratta di richieste estremamente specifiche, formulate
da clienti che necessitano di assessment su determinati oggetti ad alto rischio.
Questo tipo di verifica di vulnerabilità non segue i canoni ordinari,
bensì richiede l’applicazione di tecniche associate di audit del
codice e verifica delle vulnerabilità verticali dei sistemi sottostanti
l’oggetto che si desidera esaminare.
Il metodo e gli standard
Un ruolo di una certa importanza viene attribuito ai metodi da seguire per l’effettuazione
delle analisi. Anche in questo caso stiamo assistendo a una evoluzione delle
metodologie rispetto al triennio precedente. Se prima si utilizzavano metodi
proprietari o comunque “chiusi/personalizzati”, adesso si inizia
ad assistere alla definitiva affermazione dei metodi “open” o comunque
liberamente distribuiti.
In questo momento si nota l’incremento dell’interesse generale nei
confronti di metodologie opensource quali Open-source security testing methodology
manual (Osstmm) e Open Web application security project (Owasp).
Il primo è dedicato all’effettuazione trasversale di test per
la sicurezza di reti e sistemi. È diviso in sezioni ognuna delle quali
corrisponde a un determinato argomento, con particolare riferimento a reti,
sistemi, organizzazione e comportamenti. È altresì interessante
notare come parte del metodo sia dedicata alla verifica dell’organizzazione
e ad argomenti quail il social engineering.
Owasp, invece, è un progetto finalizzato alla verifica delle vulnerabilità
del software in generale. I due progetti sono differenti ma complementari tra
loro. Probabilmente Owasp è più ambizioso e strategico per alcune
tipologie di clientela. Pur essendo leader nella comunità opensource,
Owasp non è il solo progetto ad avere queste finalità. Anche il
Cert Cc di Carnegie Mellon University è attivo in questo settore con
il suo Sei (Software engineering institute) che offre anche delle particolari
certificazioni per i singoli.
Un altro strumento metodologico utilizzato in comunità fa capo ai white
papers del Nist (National Institute for Standard and Technologies) i quali contengono
una serie di indicazioni sul security management, incluso quello degli assessment
di vulnerabilità. Per ulteriori informazioni è possibile contattare
il sito www.nist.gov
In or outsourcing?
Una domanda che l’utenza finale si pone in questo periodo è se
affidare questi task a un team interno o a una società esterna. Le domande
sono legate a quattro fattori principali: le risorse disponibili, i costi, il
livello qualitativo dell’offerta, la riservatezza delle informazioni acquisite
a seguito dell’assessment.
Le risorse disponibili. Alcune aziende del segmento enterprise hanno percorso
la strada dell’insourcing. Tuttavia hanno dovuto valutare un problema
di gestione delle risorse interne, sotto due punti di vista: la composizione
e la preparazione dello staff. La gestione in insourcing delle vulnerabilità,
per essere efficace, è un task a tempo pieno, che richiede un organico
di almeno due persone con un supervisore. Non è possibile avere un team
“part time”; ne risentirebbe la qualità dei risultati.
- I costi. Durante un recente scambio informazioni con un cliente inglese,
è emerso che il budgeting annuale da lui programmato per un team è
l’equivalente di circa duecentomila euro, suddivisi tra: compensi annuali
dei tre componenti il team, costo degli aggiornamenti professionali, costo
del licensing degli strumenti di pentest, costo delle ore uomo sottratte a
task ordinari per gestire gli impatti del processo. Questo limita l’insourcing
a poche e danarose realtà. Sempre che il bilanciamento tra gli investimenti
interni e il costo di un outsourcing sia a favore del primo. - Il livello qualitativo dell’offerta. Qualora si scelga di optare
per un fornitore esterno, sussisterà l’esigenza di verificarne
la qualità. Questo di solito viene effettuato o dal team interno o
con il supporto di un advisor. È un po’ il rovescio della medaglia.
A ogni modo è imprescindibile, al fine di evitare scelte non coerenti. - La riservatezza delle informazioni. Quando si effettua un vulnerability
assessement sono due le categorie di informazioni esposte: quelle relative
ai target da sottoporre a controllo e quelle che emergono dall’assesment.
Trattandosi di informazioni estremamente sensibili, spesso frutto di un’attività
di audit, è possibile che i controlli interni (internal audit) richiedano
giustamente di avere visibilità sull’intero processo. Questo
fattore costituisce un elemento importante durante la scelta.
L’esposizione legale
Un’altra componente da valutare nella gestione delle vulnerabilità
e dei relativi assessment è quella legale. L’impatto di tipo legale
su queste operazioni viene valutato in relazione a tre casistiche: esposizione
legale in caso di non effettuazione dei test, rischio in caso di effettuazione
del test e rischio nei confronti di terze parti.
Se non si adotta un programma di vulnerability management, il rischio legale
basilare è quello di non compliance con le normative che richiedono l’analisi
del rischio. Come la legge 196/2003 (privacy), la Sarbanes Oxley e via dicendo.
Se lo si adotta, e non si seguono comunque dei principi di due diligente obiettivamente
riconosciuta, si è esposti comunque, anche nei confronti dei terzi, per
esempio coloro che gestiscono gli Indirizzi Ip degli asset da sottoporre ad
analisi.
Quando, poi, su una macchina di un outsourcer (per esempio un Isp – Internet
service provider o un servizio di hosting/housing/Asp) coesistono più
asset di aziende differenti e separate tra loro, l’esposizione legale
è evidente.
Ad ogni modo, le aziende interessate a questo tipo di processo si stanno avvicinando
sempre più all’approccio misto, dove la componente legale è
comunque sempre più importante, a testimonianza della cognizione di causa
sempre maggiore da parte del cliente finale.
Conclusioni
L’esperienza diretta presso i clienti ha dato a chi scrive una serie di
elementi di valutazione decisamente corposa. In questo momento storico l’utenza
fruitrice dei servizi di sicurezza, specie quelli di vulnerability management,
è più smaliziata rispetto a prima.
Il motivo è fondamentalmente di tipo economico. La gestione delle vulnerabilità
viene vista come un asset di tipo tecnologico, quindi sotto il perimetro dei
Cio e manager di linea.
Questi hanno, ormai da un biennio, il mandato comune di razionalizzare i costi,
con un effetto visibile sulla compressione dei margini e dei prezzi in generale.
Anche a fronte di quanto abbiamo scritto in questo articolo e a prescindere
dalla metodica utilizzata, è da ritenersi che i vincitori di questo contraddittorio
siano potenzialmente due: l’impresa fornitrice specializzata nello specifico
settore (che quando non può erogare direttamemte presso il cliente, riesce
comunque a garantire un servizio di tipo sell thru) e il cliente finale, che
ha l’ultima parola sul processo di scelta di quello che, a tutti gli effeti,
diventa un vero e proprio partner sul fronte sicurezza.
