IMHO tool di VA devono essere lanciati contro tutta l’infrastruttura: produzione, test, ecc. Scegliere solo un ambiente perché si ha il timore di rompere qualcosa non ha molto senso perché chi ti vuole bucare non ti chiede dove preferisci essere attaccato. Magari all’inizio, in fase di valutazione, potrebbe avere senso cominciare dall’ambiente di test per capire cosa succede, ma poi si dovrebbe coprire tutto l’esposto, idealmente sia verso l’interno che verso l’esterno.
Per quanto riguarda la scelta del tool, sicuramente è meglio affidarsi a tool consolidati: i tool di VA si limitano a raschiare la superficie, se si scelgono tool “beta” o poco supportati l'elevato falso senso di sicurezza è assolutamente controproducente. E se un tool qualsiasi sfascia un prodotto in produzione forse è meglio sostituirlo quel prodotto… My $.02 Gerardo > On Mar 17, 2018, at 1:59 AM, h...@libero.it wrote: > > Se lavori in ambito enterprise e sono scansioni interne, quindi non eseguite > da terze parti per cui ci sarebbe tutta una trafila diversa ad esempio > banalmente di firme per nda e altro, fatte per validare ambienti sviluppati > in casa o acquistati da fornitori esterni la best practice minima sarebbe di > lanciare i tools verso ambienti di collaudo / sviluppo. > > Per inciso ricordo ancora il lancio da parte di uno sviluppatore di uno scan > acunetix verso la nuova release del prodotto software fatta in produzione, > santo rman di oracle..... > >> Il 15 settembre 2017 alle 8.44 ED <mailing23462...@edlabs.it> ha scritto: >> >> >> Un articolo di ieri relativo all'ennesima shell PHP con annessa backdoor >> [1], ha rafforzato i miei timori sull'uso di tool poco conosciuti >> durante i test di sicurezza verso ambienti di produzione. >> >> Lavoro in un ambiente "enterprise", in cui mi limito ad usare tool >> commerciali di grosse case o open source rinomati (Nmap, Nikto ecc). >> Salvo rare eccezioni, i tool poco conosciuti che vanno oltre la mia >> capacita' di analisi (es. script ExploitDB con blob binari, framework >> PowerShell che nascono e muoiono come meteore) sono esclusi, >> specialmente se necessitano di privilegi local elevati o di credenziali >> sull'obiettivo. Non avendo io tempo e competenze per scrivere exploit, >> cio' naturalmente limita di molto i risultati. >> >> Come fate voi? Qual'e' il confine fra un tool sicuro ed uno pericoloso? >> Dipende dall'obiettivo? Che precauzioni prendete quando eseguite tool >> nuovi? Sono mai state formalizzate best practice a riguardo? >> >> Saluti >> ED >> >> >> [1] >> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fisc.sans.edu%2Fforums%2Fdiary%2FAnother%2Bwebshell%2Banother%2Bbackdoor%2F22826%2F&data=02%7C01%7C%7C322428deb128417aa66c08d58ce48877%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636569835516193246&sdata=h9FBMlbmFd16ahhPqkmVvplKv2vZBJCrdv5zH1pK2PU%3D&reserved=0 >> ________________________________________________________ >> https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sikurezza.org&data=02%7C01%7C%7C322428deb128417aa66c08d58ce48877%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636569835516193246&sdata=sweDk5MkHoQxTMyqs%2BNRsfFn1LR0TkD3Gve%2BF7ZO7Ks%3D&reserved=0 >> - Italian Security Mailing List >> > ________________________________________________________ > https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sikurezza.org&data=02%7C01%7C%7C322428deb128417aa66c08d58ce48877%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636569835516193246&sdata=sweDk5MkHoQxTMyqs%2BNRsfFn1LR0TkD3Gve%2BF7ZO7Ks%3D&reserved=0 > - Italian Security Mailing List > ��i��0�Ȥ���ͪ+��Z�&�I�.�+r1���x ��
