ICT security forum 2009, il grande giorno

Data:19 ottobre 2009
ICT security forum 2009, il grande giorno

Eccoci qui, trepidanti per l’attesissimo forum sulla sicurezza che si svolgerà a Roma il 22 ottobre.

Commerciali adorabili si accalcheranno sull’arena dello sheraton hotel per mostrare al mondo i loro ultimi giocattoli tecnologici in momenti di estasi catartica per l’inutilità della maggior parte di questi.

Io sarò lì con un collega a fare qualche video, e giusto per tirarsi su il morale farò una breve cronaca dell’evento.

Stay tuned!

Il piano di rischio per le web applications

Data:25 maggio 2009
Tag:Si parla di:

Il rischio in ambito informatico è un concetto legato alla probabilità che un evento possa influenzare negativamente il business per cui un’infrastruttura è stata realizzata.

La definizione di un piano di rischio nell’ambito web è un’operazione complessa e articolata, che prevede una profonda conoscenza del tipo di business trattato dalle web application, delle vulnerabilità e delle classi di attacco.

L’analisi e la stesura del piano di rischio non possono essere sviluppate secondo i tradizionali criteri e fattori di cui tiene conto la “security governance”, limitando la considerazione dell’analisi della frequenza e della quantità di rischi avvenuti in precedenza, ritenendo opportuno orientare il modello di rischio al business e non all’incidentalità.

Molte aziende possiedono una classificazione dei loro asset, in modo da formalizzare quali siano gli asset prioritari nel loro business. Nel caso in cui queste priorità non siano formalizzate è compito della direzione aziendale definirle. La valutazione dei rischi dovrebbe essere un’operazione ciclica e continuativa, tale da permettere una definizione delle priorità in concretezza con l’evoluzione del business nel tempo.

RISCHIO = Probabilità di rischio * impatto sul business

Nell’identificazione della probabilità di rischio le due componenti principali sono i fattori legati alla vulnerabilità e alle figure che potrebbero sfruttare la vulnerabilità:
- Facilità di scoperta della vulnerabilità (è possibile individuarla con sistemi di scansione automatizzata?)
- Facilità di attacco (dispendioso in termini di tempo? Richiede skills elevati? Quante aree della struttura devono venire coinvolte per portare a termine l’attacco? Sono presenti tools per lo sfruttamento della vulnerabilità riscontrata? Numero di attaccanti necessari?)
- Appetibilità del dato (dati economici, dati industriali, dati personali, dati giudiziari, dati sensibili) L’impatto sul business è caratterizzato invece da un risvolto tecnico e uno funzionale Impatto tecnico – compromissione dell’integrità o della confidenzialità del dato
- Numero di asset coinvolti?
- L’attacco è tracciabile ai fini della sicurezza?
- Quanto tempo è necessario dedicare al ripristino dell’infrastruttura dopo l’attacco? Impatto funzionale – danno finanziario, perdita di immagine, mancanza di segretezza, diffusione di dati personali relativi a terzi – Sono stati trasferiti fondi economici?
- Ha impedito le vendite per un periodo considerevole?
- Ha reso impossibile l’accesso all’applicazione web in un momento cruciale per il business aziendale?
- L’attacco ha un risvolto economico nelle quotazioni aziendali? – Sono stati acquisiti piani di produzione coperti da segreto?
- Espone l’azienda a richieste di risarcimento da parte di terzi per violazione della privacy?

Una volta definito il rischio nella probabilità e nell’impatto sugli asset rispetto alle vulnerabilità di ogni classe di attacco (code injection, source code disclosure, special characters insertions, ssi, xxs, bypassing authentication schema, bypassing authorization schema, path traversal, command injection, crittanalisi, denial of service, man in the middle, etc), è necessario assegnare un risk rating alle singole casistiche identificate durante le fasi di test.

Questa operazione permetterà al gruppo di sviluppo di correggere le vulnerabilità riducendo il tempo di risoluzione tramite un indirizzamento prioritario per criticità. I valori da assegnare dovranno essere rappresentativi e chiara espressione della condizione di sicurezza dell’applicazione, ad esempio (null, low, medium, hight, critical), o tramite una scala di valori compresi in un range limitato e ben definito (1-5, 1-10).
Si renderà necessario archiviare i risultati di ogni WAPT su un database di “versioning”, inserendo:
- nome del tester
- data di verifica
- nome e versione dell’applicazione testata
- versione del report
- tools impiegati per l’analisi
- procedura dettagliata per la riproduzione di ogni evento rilevante ai fini della sicurezza rilevato
- report breve contenente link, variabile vulnerabile, tipo di vulnerabilità e attacco per il gruppo di sviluppo ed il cliente.

Il rischio nell’area business è ciò che giustifica un investimento nella sicurezza.

Spesso valutazioni superficiali e poco tecniche, sottovalutano il danno arrecato in termini di immagine rispetto ai propri clienti o le proprie responsabilità nei casi in cui del materiale contenente dati personali venga reso pubblico, andando incontro a spese maggiori a incidente avvenuto.

Stipendi e consulenze ICT

Data:15 aprile 2009
Stipendi e consulenze ICT

“Qualche anno fa, una famosa ditta americana di consegne, aveva la caratteristica di consegnare dei pacchi entro un tempo definito, altrimenti il cliente non avrebbe pagato la spedizione.

Si bloccò la catena dei macchianari… fu il PANICO! Non c’era una spiegazione a tutto questo! Nessuno ci capiva niente e non c’era versi di far ripartire le macchine: risultato, migliaia di dollari che venivano persi ogni minuto che passava!

Chiamarono il tecnico adetto alle macchine e dopo averci pensato su… egli ebbe un’illuminazione…

prese un cacciavite ed a colpo sicuro, girò una piccola vite nascosta. MIRACOLO! LE MACCHINE RIPARTIRONO.

Tutti a ringraziare il tecnico come salvatore dell’azienda.

Al momento che li fu chiesta la sua meritata parcella… il direttore, quasi svenì quando si sentì sparare l’esuberante cifra di 10.000$!
10.000$ per girare una vite? E’ un furto!, urlò il direttore indignato.

‘Pretendo che lei scriva i dettagli del suo operato!’ , continuò il direttore, sempre più indignato.

Il tecnico prese un foglio e la penna, scrisse i dettagli del suo lavoro e lo consegnò al direttore. Il direttore, dopo averlo visto, si rese conto….

ed ordinò alla sua segretaria di pagare 10.000$ al tecnico”.

Cosa c’era scritto di tanto straordinario in quel foglio, da far cambiare completamente idea al direttore?

“Girare la vite = 1$;

Sapere quale vite girare = 9999$”

Ricerca

Saverio Rizza

Consulente informatico, scrivo articoli "rancorosi" che spaccio per consigli sulla sicurezza su questo sito e gestisco il primo social network italiano sulla sicurezza su code inspection. Puoi trovarmi anche su Linkedin.

Abbonati al feed RSS

Icona del feed RSS Sottoscrivi il feed RSS per essere sempre aggiornato sulle novita' del blog.

Argomenti trattati


ICT Security e' basato sulla piattaforma di blogging WordPress.