Figurati, e' un piacere parlare in modo costruttivo. Dalla mia risposta non vorrei che tu pensassi che sono contro il cloud (altrimenti sarei tagliato fuori), ma le mie sono considerazioni di security architecture, indipendenti dal fatto che il VA sia fatto su infrastruttura fisica o cloud.
Ti spiego cosa intendo. Tu accedi ad un'infrastruttura da: - frontnet (WAN/internet) - management Vlan - MPLS o similar - VPN end points questi sono gli entry point che 90% delle volte devi considerare, ogni server o device ha di sicuro: - frontnet - lan - management ma a queste dobbiamo aggiungere - storage via IP - bkp/replication vlan - network TAP - IDS/IPS - etc Vedo un'attenzione esagerata nel VA, ma poi vengono disegnati male, soprattutto considerando che il risultato non e' assolutamente il quadro generale dell'infrastruttura, ma solo un'esigua porzione. Tanti si concentrano sulla frontnet, ma poi si dimenticano tutti gli altri entry point... MPLS, management Vlan, etc. Se un server in DMZ ha una interfaccia su una management vlan, un attacker, per fare una lateral move, perche' dovrebbe complicarsi la vita con un double hop su una frontnet, invece di una backnet di management? Facendola breve, le mie considerazioni sono che VA, molto spesso sono parziali implementazioni e quelle fatte con servizi cloud lo sono di definizione.... non mi dire che fai uno scan della management via frontnet. Alcuni vendor usano un approccio misto con scan engine frontnet via cloud, piu' boxes inside che fanno l'upload, ma anche spesso in questi modi manca un po' di testa, nel pensare che il lateral move non e' obbligatorio sia fatto tramite un payload sempre e solo via la stessa interfaccia, aggiungere una static route quando hai una shell non e' una fatica. IP KVM controllers, sono un altra cosa sottovalutata. Anche se trovi un buon design, purtroppo perde in traduzione quando hai management Vlan routing oppure un bello switch a L3, che ha un bel trunk di tutte le Vlan in un colpo solo....tutta roba che non scopri se non fai configuration review, non lo scoprirai via VA, altro motivo per cui gia' di design VA non e' una panacea, come a volte neanche pent testing e'. In breve, quando pensi a VA, non pensare a quanto e' carino il report, ma se quello che vedi e' davvero tutto quello che useresti per attaccare l'infrastruttura.... VOIP, etc. Se hai un VA frontnet da esterno, via cloud, stai dando accesso a zone interne direttamente bypassando DMZ? Sei sicuro tu stia facendo la stessa foto di quello che l'attaccante che ha compromesso DMZ vede (esempio regole firewall_? In poche parole, stai veramente vedendo tutto quello che un attaccante puo' usare per un lateral move. Nella mia esperienza, trovare dove ti hanno bucato nella frontnet e' facile, fare forensics sull'host da dove arrivano i dati e' facile, capire che strada hanno fatto e' il vero casino, lateral move e' la piu' complicata anche se hai un SIEM con un buon tuning. Load balancer a volte vengono bypassati da VA, con accesso diretto al pool dietro il VIP del LB, anche queste cose vanno considerate quando disegni un VA, rischi di dare un percorso alternativo ad un attaccante, infatti un load balancer protegge anche il pool, ma se tu apri una via per arrivarci diretto, per fare VA, ti sei fatto un buco enorme. Se hai soluzioni streaming app, tipo Citrix, VA va disegnato bene perche' perde davvero significato, infatti diventa un puro esercizio di compliance e basta. Se usi MPLS, molte volte stai connettendo due trusted domain ma sotto due differenti VA che non si parlano. Molte volte i firewall di MPLS NATtano e non viene fatto un vero VA da un trusted domain all'altro, ma magari l'altro viene bucato e diventa un lateral move nella tua infrastruttura....non venendo da frontnet, magari bypassa tanti dei tuoi SIEM feed e piangi. Vulnerability management e' venduto con leggerezza come soluzione stand alone, come se fosse un'aspirina per il mal di testa, implementato facendo felice il manager con tanti report colorati e un giorno si scopre che guardava solo 30% di quello che serviva. Questo era il punto che cercavo di fare, non e' cosa usi, open source o meno, ma che valore ti da, in termini di gestione di tutto il loop (diff tra scans, re-test, etc) oppure di visibilita' di tutti gli entry points, anche di quelli non conosciuti o considerati da $vendor. Per la Kali, ho detto il mio pensiero, su un data center, voglio uno standard con templates, per semplificarmi il patching, specialmente se non hai infrastrutture miste client/servers. Non esiste niente che tu non possa far girare su una debian o un RHEL standard, Kali io la terrei per un laptop tuo per PT, poi ognuno fa quel che ritiene, ma solo considerando tutta la roba che ha per SMB, etc la fa vulnerabile di design. Considera anche che se proprio vuoi, puoi anche usare Kali in docker, automatizzare il deployment, fare regola firewall con API (metti leva), fare e chiudere. Viviamo nell'era di SecDevOps, ci sono molti modi per fare le cose. My 2 cents ciao Mi fa moltro piacere che siano stati portati alla luce dei nervi scoperti > di alcune delle mie indicazioni. Mi danno modo di capire che vi sono > miglioramenti da tenere in considerazione anche sul fronte delle > prestazioni network ... > >
