Prima di accettare un ingaggio per un penetration test o per un vulnerability assessment non solo risulta prudente ma anche doveroso accertarsi che il cliente sappia effettivamente cosa vuole… giacché non gli è sempre così chiaro, anche perché penetration test è ormai diventato un termine abusato per svariate problematiche:
– sta cercando solo un audit del codice e in realtà confonde i termini?
– forse è alla ricerca solo di una Code Review?
– il cliente si aspetta che lavoriamo in ambito Blackbox, Whitebox o Greybox?
– l’analisi dovrà essere circoscritta al perimetro ICT oppure dovrà coinvolgere anche gli apparati e i sistemi del mondo ICS?
– il cliente si aspetta che venga incluso anche il perimetro VoIP/IoT nell’assessment?
…e oltre alle variabili ad alto livello indicate nel grafico, aggiungo fattori contestuali non banali:
– i sistemisti che gestiscono l’infrastruttura del cliente sono dipendenti interni o consulenti esterni del cliente?
– la società che ci sta commissionando l’attività, effettivamente è la società proprietaria dei sistemi da scansionare ed attaccare?
– chi di dovere ci ha firmato le necessarie manleve a norma di legge?
– i sistemi da testare sono pubblicamente raggiungibili da Internet oppure per testarli occorre necessariamente essere collegati alla LAN/WLAN del cliente?
– chi di dovere ci ha fornito la lista aggiornata delle sottoreti da sottoporre a scansione oppure dovrà essere nostra cura scoprire quali siano gli indirizzi IP associati ai sistemi?
– il target fa uso anche di sistemi o servizi in Cloud? e se sì, quali?
– gli utenti operativi nell’eventuale rete on-premises del target adottano abitualmente smart card per le loro operazioni?
– il target è una piccola azienda, una media realtà o addirittura un S.O.C. / M.S.S.P. di portata nazionale?
– il cliente è interessato a qualunque vulnerabilità eventualmente presente nei suoi servizi e sistemi oppure solo al mondo OWASP?
.
.
…ecc.. ecc..
dmzware.com 