2009/10/16 Giuseppe "Gippa" Paterno' <[email protected]>: > Ciao a tutti! > > Volevo dire il mio punto di vista sulla vicenda defacing di Poste. Non > voglio prendere le difese di alcune persone, ma vedo spesso entrambe le > facce della medaglia. Secondo me fino ad adesso abbiamo affrontato il > discorso come appassionati/grandi esperti di sicurezza, ma per la prima > volta pubblicamente faro' l'avvocato del diavolo. > > E' da un po' di anni che "bazzico" alcune grosse aziende e penso che sia > piu' facile individuare da solo un buffer overflow, scrivere uno 0-day e > "entrare" su un sistema che installare una singola, insignificante patch > di sicurezza in una grossa azienda. Non sempre fortunatamente. Io lavoro in una grande azienda nella quale sui 600 circa sistemi Linux in produzione si installano le patch del sistema operativo giornalmente e automaticamente. Questo è possibile farlo in sicurezza per tutto ciò di cui viene fatto o fornito un package (RPM in questo caso). Chiaramente vi sono pletore di prodotti commerciali che non lo fanno e purtroppo per questi non è possibile applicare le patch automaticamente ma solo a cicli di major release (3-4 mesi iirc) . Nessuno di questi ultimi sistemi è naturalmente in diretto contatto con Internet. Proprio per risolvere problemi del genere stiamo cercando di portare, laddove possibile, tutti i vendor commerciali - e non solo - a fornirci tutti i software in RPM, qualora non lo facciamo direttamente noi (per ora io)
Ciao Elia > > Mi rendo conto che non tutti hanno la "fortuna" come me di frequentare > grosse banche e grandi telco. Quello che succede e' che spesso una > applicazione e' scritta da una azienda che ha vinto un appalto (prime > contractor) e subappalta ad altre aziendine (subcontractors) pezzi di > progetto. Per evitare "rogne varie", le aziende (clienti e prime > contractor) vogliono tutto certificato. I vari hardware e software > vendor, oltre che i developer, per una questione di tempo (e quindi > soldi) certifica la piattaforma per una determinata release di > prodotto/patch level. > Si ha quindi che: > > * L'hardware deve avere un determinato firmware per essere certificato. > * La piattaforma hardware, ovvero server, storage, hba, switch SAN, > switch di rete (e quant'altro manca) sono solo certificate a determinate > release di sistema operativo e patch level. > * L'applcation server e il database ha determinati requisiti di > certificazione di os level/patchlevel > * Chi "certifica" l'applicazione la fa sulla base di un'architettura > provata in casa al momento del development/integration tests (prime > contractor). > * Gli sviluppatori, del subcontractor, sono spesso persone che magari > sono brave a programmare (java/asp) ma hanno poca conoscenza > dell'infrastruttura globale, focalizzandosi solo sul loro pezzettino e > sulla funzionalita' .... sappiamo come vanno le cose: come al solito > vanno fatte "per ieri" e spesso x velocizzare si fanno "spaghetti code". > > Quando una piattaforma viene testata in test e pre-prodizione, qundi > rilasciata per la produzione viene congelata, certificata e "non si > tocca piu'". > > Peggio che peggio, spesso il dipartimento di sicurezza viene solo > interpellato quando si aprono le regole del firewall e mai durante la > stesura del progetto. > > Cosa cambia installare una singola, insignificante patch magari sul web > server di produzione? Succede che se qualcosa non funziona, anche se non > c'entra niente con l'applicazione (magari si tratta di un buco su SSL, > invento!), inizia il rimpallo di responsabilia' tra cliente/prime > contractor/subcontractor e vendor hardware e software. Ognuno dicendo > che questo o quel pezzo non e' certificato... > > Per cui vai a finire che installi le patch due/tre volte l'anno. Anche > se vuoi installare una "critical patch" di urgenza, devi fare le cose > secondo le regole, installando cioe' prima in test e sviluppo, facendo > gli appositi test (qa/carico/...), installare in preproduzione e > produzione poi: i tempi sono biblici e l'ethical hacker/cracker di turno > fa in tempo a sguazzarci alla grande :))) > > Fa niente che in alcuni casi "basterebbe mettere a posto i permessi su > filesystem", ma ti ritrovi con fornitori che ti dicono "se non gira come > root/Administrator non te lo certifichiamo". Ci si chiede: ma che > diavolo di necessita' avrai a far girare tomcat come root, poi?? Mah... > > Spesso i Security Manager di grosse aziende si ritrovano in questo > "malsano" meccanismo di fornitori vari, dove tentare di fare coesistere > la sicurezza con i fornitori e' un inferno ed avere a che fare con l'IT > Manager che hanno degli SLA di servizio e che ti danno addosso perche' > vedono la sicurezza come un "male necessario" (se ci va bene) che > rallenta i progetti e aumenta i costi. > > Se hai la fortuna di avere un IT manager visionario a cui interessa > veramente la sicurezza, allora considerati fortunato. In quelle aziende > in cui ho girato, solo in una mi sembra di aver visto una realta' di > sicurezza in cui il dipartimento viene coinvolto nelle varie fasi... e > indovinate un po': il manager non e' italiano. > > Ho ovviamente esasperato, ma in molte aziende un po' piu' > "conservatrici" e' veramente cosi'. Per assurdo, le piccole/medie > aziende sono spesso piu' protette di quelle grandi! Ora che ho parlato > dell'altra faccia medaglia faccio un mea culpa anche a nome di altri > vendor/fornitori: dovremmo essere noi in prima persona a pensare di dare > al cliente finale una soluzione che sia intrinsecamente sicura. Peccato > che anche il vendor e' soggetto ai quarter e fiscal year, per cui il > modo di pensare "sicuro" rallenta le vendite e la fatturazione .... ;-) > > Un Gippa che sta gia' scappando in brasile :))) > > ________________________________________________________ > http://www.sikurezza.org - Italian Security Mailing List > ________________________________________________________ http://www.sikurezza.org - Italian Security Mailing List
