MINACCE E MITIGAZIONI UNA GUIDA ALLA SICUREZZA WEB ... · 2013 COST OF CYBER CRIME STUDY: United...

Sicurezza web multilivello | 1

UNA GUIDA ALLA SICUREZZA WEB MULTILIVELLO

MINACCE E MITIGAZIONI

http://akamai.com


SOMMARIO

INTRODUZIONE: Fuori dalla fortezza e sotto tiro ...........................................................................4

CAPITOLO 1 - Definizione delle minacce web attuali ......................................................................5

• Attacchi DoS/DDoS contro la rete .......................................................................................... 6

- Attacchi di tipo flood semplice ........................................................................................ 8

- Attacchi basati sull'amplificazione ................................................................................... 9

- Strumenti per il lancio di attacchi DDoS ......................................................................... 10

• Attacchi DoS/DDoS a livello di applicazione ......................................................................... 13

- Attacchi a elevato consumo della larghezza di banda .................................................... 13

- Attacchi a basso consumo della larghezza di banda ...................................................... 14

• Attacchi di furto di dati ........................................................................................................ 15

• Attacchi al DNS .................................................................................................................... 17

CAPITOLO 2 - Un approccio multilivello alla sicurezza delle applicazioni web ...........................19

• Difesa dagli attacchi DoS a livello di rete .............................................................................. 20

• Protezione delle applicazioni dagli attacchi DoS e dal furto di dati ....................................... 21


CAPITOLO 3 - Analisi delle opzioni disponibili ..............................................................................22

• Hardware in loco ............................................................................................................. 23

• Servizi basati su cloud ..................................................................................................... 24

CAPITOLO 4 - Come scegliere una soluzione ............................................................................26

• Protezione dagli attacchi DoS/DDoS a livello di rete ......................................................... 27

• Protezione dagli attacchi a livello di applicazione ............................................................ 30

• Protezione dagli attacchi al DNS ..................................................................................... 33

CAPITOLO 5 - Igiene Internet: vulnerabilità comuni delle applicazioni web e come affrontarle ....................................................34

• Quali sono le vulnerabilità più diffuse? ............................................................................ 35

• Come gestire le vulnerabilità comuni delle applicazioni web ............................................ 36

CONCLUSIONE ..................................................................................................................... 40

APPENDICE: • Principali esperti della sicurezza web ............................................................................... 42

• Letture consigliate .......................................................................................................... 43

�Torna al sommario Sicurezza web multilivello | 4

PERCHÉ LEGGERE QUESTA GUIDA?

Il perimetro dei data center è ormai scomparso. Ma la sua memoria vive ancora nel modo in cui molti reparti IT continuano a proteggere la propria infrastruttura. Il rapidissimo sviluppo di Internet ha portato con sé un panorama costantemente mutevole di nuovi attacchi e ha completamente rivoluzionato i vecchi modelli di protezione dell'infrastruttura IT delle organizzazioni. In passato, le risorse informative che occorreva proteggere risiedevano tutte in una fortezza controllata dall'IT, ovvero in un data center protetto. Solitamente gli attacchi provenivano dall'esterno delle quattro mura del data center o da persone interne che approfittavano dei loro privilegi. Le aziende schieravano le proprie armi di protezione, ad esempio i firewall, ai valichi di frontiera e si proteggevano dagli attacchi interni tramite ruoli e privilegi di accesso rigorosi.

INTRODUZIONE - Fuori della fortezza e sotto tiro

CAPITOLO 1 Esamina i tipi di minacce alla sicurezza a cui si è esposti online.

CAPITOLO 2 Descrive i componenti necessari per proteggere siti e applicazioni web.

CAPITOLO 3 Analizza i tipi di soluzioni disponibili.

CAPITOLO 4 Esamina cosa ricercare in una soluzione per la sicurezza web.

CAPITOLO 5 Illustra come ridurre al minimo le vulnerabilità nei siti e nelle applicazioni web.

Oggi però i siti e le applicazioni web risiedono sempre più spesso nel cloud, all'esterno del data center.

Come si può proteggere un perimetro che non esiste più? Innanzitutto, è necessario comprendere quali risorse sono maggiormente a rischio e determinare la tolleranza al rischio della propria azienda. Occorre quindi gestire tale rischio estendendo i controlli di sicurezza al cloud e proteggendosi dai tipi di attacchi che hanno luogo in Internet. Questa guida descrive in dettaglio le minacce comuni ai siti e alle applicazioni web e le possibili misure da adottare per mitigarle.


COSTO DEL CYBERCRIMINE Ponemon Institute, ottobre 2013

$ 1.288.710 minimo

$ 11.559.057 medio

$ 58.094.571 massimo

I cybercrimini più costosi sono

quelli causati da attacchi di tipo

denial of service, codice dannoso

e attacchi basati sul web. Questi sono

responsabili di oltre il 55% di tutti

i costi annui del cybercrimine

sostenuti dalle organizzazioni.

LINK }

CAPITOLO 1

Al vertiginoso aumento di popolarità dei siti web e delle applicazioni basate sul web si è accompagnata una corrispondente crescita esponenziale del numero, dei tipi, dell'estensione e dei costi degli attacchi che puntano specificamente alle vulnerabilità di tali sistemi. In generale, questi attacchi rientrano in due categorie:

• DoS (Denial of Service) / DDoS (Distributed Denial of Service)

• Furto di dati, ad esempio attacchi SQL injection e altri attacchi di tipo command injection

Il CAPITOLO 1 di questo eBook definisce tali attacchi, il modo in cui operano e il loro impatto sui sistemi e sugli utenti.

Definizione delle MINACCE WEB ATTUALI

http://media.scmagazine.com/documents/54/2013_us_ccc_report_final_6-1_13455.pdf


Le dimensioni degli attacchi DoS e DDoS volumetrici crescono in maniera esponenziale.

Uno dei primi attacchi DoS documentati pubblicamente è avvenuto il 6 settembre 1996 contro Panix, un ISP di New York City. Gli autori non identificati dell'attacco hanno utilizzato un SYN flood per esaurire le connessioni di rete disponibili e impedire agli utenti legittimi di connettersi ai server Panix. L'attacco ha utilizzato tre computer per generare 48 Kbps di traffico di rete.

Per contro, un'organizzazione di hacktivisti nota sotto il nome di QCF (Izz ad-Din al-Qassam Cyber Fighters) ha sferrato una serie di attacchi contro istituzioni finanziarie statunitensi a partire dal 5 marzo 2013, utilizzando 3.200 bot per generare picchi di traffico di rete di 190 Gbps.

Akamai prevede che entro il 2020 un attacco DDoS genererà in media 1,5 Tbps di traffico di rete.

Patrikakis, Charalampos, Masikos, Michalis, Zouraraki, Olga (dicembre 2004). Distributed Denial of Service Attacks. The Internet Protocol Journal - Volume 7, numero 4. Informazioni tratte da http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-4/dos_attacks.html

Litan, Avivah (marzo 2013). Are the ongoing DDoS attacks against U.S. banks just the calm before the storm? Gartner. Informazioni tratte da http://blogs.gartner.com/avivah-litan/2013/03/14/are-the-ongoing-ddos-attacks-against-u-s-banks-just-the-calm-before-the-storm/

Attacchi DoS/DDoS contro la rete

Gli attacchi DoS sono tra le minacce più comuni alle operazioni Internet.

Questi attacchi saturano la larghezza di banda della rete in modo da renderla

non disponibile agli utenti desiderati. Il sito salta a causa del traffico che inonda

le connessioni tra Internet e l'azienda. In un attacco DDoS, spesso vengono

utilizzati più nodi per inviare il traffico a un sito. Gli attacchi DDoS riducono

la quantità di traffico che un sistema di attacco deve inviare, aumentando al

contempo l'impatto sull'obiettivo.

A livello di rete si verifica una serie incredibile di attacchi DoS e DDoS. Tali

attacchi possono essere raggruppati in due ampie categorie: attacchi di tipo

flood semplice e attacchi basati sull'amplificazione. Esistono vari strumenti che

automatizzano il processo di creazione di entrambi questi tipi di attacchi e che

pertanto consentono anche alle persone senza alcuna competenza tecnica di

mettere a repentaglio in modo facile e veloce il sito web scelto.

LE DIMENSIONI ESPLOSIVE DEGLI ATTACCHI DOS/DDOS Ponemon Institute, ottobre 2013


Chi sferra gli attacchi DoS/DDoS e perché? Per proteggere la propria infrastruttura in modo strategico, è necessario comprendere chi sono coloro che più probabilmente attaccheranno l'azienda e quali saranno le tattiche impiegate. I vari tipi di avversari sono:

• ESTORSORI: gli estorsori minacciano di disattivare o disattivano un sito web e quindi chiedono denaro per evitare o arrestare l'attacco.

• ESFILTRATORI: gli esfiltratori utilizzano un attacco DoS per distogliere l'attenzione dal loro reale obiettivo, sottraendo dati che possono mone-tizzare, siano essi una proprietà intellettuale o numeri di carte di credito.

• HACKTIVISTI: gli hacktivisti sono diversi dagli altri tipi di autori di attacchi. Sono persone in lotta che cercano di lanciare dichiarazioni politiche o dare risonanza a una causa. I loro attacchi possono sembrare casuali e sono spesso istigati da una particolare notizia. Ma ce l'hanno con la vostra azienda e di conseguenza, quando si imbattono nei vostri controlli di sicurezza, è difficile che si ritirino per trovare un bersaglio più facile. Talvolta gli hacktivisti vengono utilizzati come capri espiatori, permettendo ad altri tipi di avversari di nascondersi dietro i loro attacchi motivati politicamente.

• CONCORRENTI: i vostri concorrenti potrebbero disattivare il vostro sito per ottenerne un vantaggio oppure potrebbero sottrarre informazioni contenute sul vostro sito tramite tecniche di emulazione dello schermo, ad esempio, per determinare i vostri prezzi e battervi sul campo.

"Se conosci i tuoi nemici e conosci te stesso, potrai vincere centinaia di battaglie... Se non conosci i tuoi nemici né te stesso, sarai in pericolo in ogni singola battaglia."

Sun Tzu, L'arte della guerra

Nel 2013, metà delle aziende intervistate in occasione di un recente sondaggio del Ponemon Institute aveva subito un attacco DoS, con un aumento del 29% rispetto al 2012.

Gli attacchi DoS hanno rappresentato il 21% dei costi totali annui del cybercrimine.

2013 COST OF CYBER CRIME STUDY: United States

Ponemon Institute, ottobre 2013

LINK al rapporto }

Se la vostra azienda è stata bersaglio di un attacco DDoS, esiste una probabilità di 1 a 4 (25%) che sia nuovamente attaccata entro 3 mesi e una probabilità maggiore di 1 a 3

(36%) che sia nuovamente presa di mira entro l'anno.

- Ricerca Akamai

�Torna al sommario

http://media.scmagazine.com/documents/54/2013_us_ccc_report_final_6-1_13455.pdf


Attacchi di tipo flood sempliceLa maggior parte degli attacchi DoS satura la rete o l'infrastruttura inondandola. Gli attacchi di tipo flood sfruttano protocolli specifici, ad esempio TCP, ICMP o UDP, per inviare un numero elevato di richieste a un bersaglio e sovraccaricare le funzionalità di rete.

Ecco alcuni dei modi in cui gli attacchi DoS possono produrre danno:

• Consumo della larghezza di banda della rete

• Esaurimento delle risorse di elaborazione disponibili, della memoria, dello spazio su disco o del tempo del processore

• Danneggiamento delle informazioni di configurazione, ad esempio delle informazioni di routing

• Interruzione delle informazioni di stato, ad esempio tramite la reimpostazione delle sessioni TCP

Attacchi flood al DNS Il DNS (sistema dei nomi di dominio) è diventato il bersaglio preferito degli attacchi flood DoS. Il DNS mappa i nomi di dominio leggibili in chiaro all'indirizzo IP utilizzato dai computer per reperire le risorse necessarie. Ogni volta che si accede a un sito web, un server DNS cerca l'indirizzo IP del nome di dominio. I server DNS possono essere di due tipi: server autorevoli che contengono un database di indirizzi IP e server ricorsivi che interrogano il server autorevole per conto del client. Molte organizzazioni implementano solo un numero ridotto di server DNS. Questo li rende particolarmente vulnerabili agli attacchi volumetrici. Quando gli autori dell'attacco inondano il DNS, non hanno bisogno di danneggiare alcun server web. Rendono invece inattivo il server DNS, impedendo agli utenti di trovare i siti web di cui sono alla ricerca.

TCP SYN flood è un

popolare esempio di

attacco di tipo flood

semplice. In questo flood,

il sistema attaccante

invia a un host una

richiesta TCP SYN con

un indirizzo IP di origine

contraffatto. Anche se

queste richieste TCP SYN

sembrano legittime,

l'indirizzo contraffatto

fa riferimento a un client

inesistente, per cui il

messaggio ACK finale non viene mai inviato all'host

della vittima. Si determinano così connessioni aperte

a metà sul sito della vittima. Una coda di backlog

archivia queste connessioni aperte a metà, le quali

associano le risorse del server in modo che non

possano essere stabilite nuove connessioni legittime,

determinando un Denial of Service.

SYN-ACK

SYN

?

SYN

Anatomia di un attacco di tipo flood semplice


Attacchi basati sull'amplificazione Gli autori degli attacchi sono costantemente alla ricerca di modi in cui aumentare le dimensioni dei flussi. Due metodi comunemente utilizzati per realizzare attacchi basati sull'amplificazione sfruttano i protocolli DNS e NTP:

Attacchi basati sulla riflessione e sull'amplificazione DNSTre caratteristiche dei server DNS li rendono particolarmente vulnerabili agli attacchi basati sulla riflessione e sull'amplificazione:

• Alcuni server ricorsivi rispondono alle query di qualsiasi client.

• Il DNS si basa sul protocollo UDP (Universal Datagram Protocol), un protocollo senza connessione che non convalida gli indirizzi IP di origine, per cui questi indirizzi sono molto facili da falsificare.

• Una richiesta al DNS di ridotte dimensioni può generare una grande quantità di dati nella risposta.

Per eseguire un attacco, un avversario invia una serie di query DNS al server ricorsivo, modificando l'indirizzo di origine delle richieste in quello del bersaglio scelto. Le richieste sono progettate in modo da avere una risposta di dimensioni molto più grandi, indirizzando un traffico di circa otto volte superiore al bersaglio. Per ulteriori informazioni sugli attacchi DrDos (Distributed Reflective Amplification Denial of Service), consultate il case study riportato nel rapporto globale Prolexic sugli attacchi DDoS del terzo

trimestre 2013. Il rapporto è disponibile qui.

Attacchi basati sulla riflessione NTP

All'inizio del 2014, gli attacchi basati su NTP sono risultati un

importante strumento nell'arsenale DDoS. NTP (Network Time

Protocol) è il protocollo utilizzato dai computer connessi a Internet

per l'impostazione dell'orologio. Come il DNS, il protocollo NTP è un

semplice protocollo basato su UDP, soggetto facilmente ad attacchi

basati sull'amplificazione perché risponde a un pacchetto con un

indirizzo IP contraffatto e perché uno dei suoi comandi integrati invia

una risposta lunga a una richiesta breve. Il comando monlist, che può

essere inviato a un server NTP per fini di monitoraggio, restituisce gli

indirizzi degli ultimi 600 computer con cui il server NTP ha interagito.

Se un server risponde con il numero massimo di indirizzi, una richiesta

di 234 byte può comportare una risposta di 100 pacchetti per un

totale di oltre 48.000, ovvero un fattore di amplificazione pari a 206x.

A febbraio 2014 è stato utilizzato un attacco basato sulla riflessione NTP per lanciare uno dei più imponenti attacchi DDoS mai registrati, di poco inferiore a 400 Gbps.

LINK }

Lucian Constantin, "Slew of spoofs used in massive, record-breaking DDoS attack", PC World, 11 febbraio 2014.

http://www.prolexic.com/knowledge-center-dos-and-ddos-attack-reports.html

http://www.pcworld.com/article/2096720/attackers-use-ntp-reflection-in-huge-ddos-attack.html


Strumenti per il lancio di attacchi DDoS Chiunque può virtualmente lanciare un attacco DDoS in pochi secondi mediante uno dei tanti strumenti prontamente disponibili e facili da utilizzare. Questi strumenti possono essere utilizzati per lanciare attacchi sia di tipo flood semplice che basati sull'amplificazione.

BotnetUna botnet è una raccolta di PC infetti da malware e controllati a livello centrale da un botmaster. Il botmaster indirizza questi computer slave tramite un server di comando e controllo, una posizione centrale da cui i computer infetti ricevono istruzioni. I computer infetti presenti in una botnet possono facilmente essere migliaia o decine di migliaia. Il botmaster può sfruttarli tutti per inoltrare quante più richieste possibili a un singolo computer o servizio Internet, sovraccaricandolo e impedendogli di servire le richieste legittime.

LOICLOIC (Low Orbit Ion Cannon) è stato inizialmente sviluppato da Praetox Technologies come strumento open source per testare la rete sotto carico ed è stato successivamente rilasciato come software di pubblico dominio. LOIC consente di allestire un attacco DoS in modo facile e veloce. Il software offre al potenziale autore di un attacco una GUI intuitiva che l'hacker utilizza per immettere un URL, scegliere un metodo di attacco (TCP, UDP, HTTP) e inoltrare la richiesta. Sono necessari in tutto 60 secondi

Una botnet attacca la sua vittima

LINK }

Vittima

Autore dell'attacco

Computer master

Computer slave

http://www.insecure.in/images/ddos.gif


per scaricare lo strumento e utilizzarlo per aprire più connessioni al server target e inviare una sequenza continua di messaggi. Questo strumento è stata l'arma di elezione del famigerato gruppo di hacker Anonymous, che ha rivendicato la responsabilità di attacchi diretti contro Sony, l'FBI e altri enti di sicurezza statunitensi. LOIC è stato inoltre utilizzato in attacchi altamente pubblicizzati contro PayPal, MasterCard e Visa.

HOICHOIC (High Orbit Ion Cannon) è un potente upgrade di LOIC. Anziché inviare ripetutamente una singola visita a un sito da parte di un falso utente, HOIC punta alle pagine secondarie. I falsi utenti di HOIC visitano la pagine di benvenuto, della guida, degli articoli e così via sul sito della vittima. Questa tattica impedisce ad alcuni firewall di riconoscere come attacco ciò che sta realmente accadendo. Anche se il firewall non se ne accorge, avrà dei problemi nel chiudere la connessione, poiché HOIC invia più falsi utenti a più pagine all'interno di un dominio. È possibile scaricare un rapporto sulle minacce con HOIC dal sito web Akamai }

BrobotOperation Ababil, un'iniziativa DDoS che si ritiene perpetrata dal gruppo di hacktivisti Izz ad-Din al-Qassam Cyber Fighters, utilizza un toolkit di script russo noto con il nome Brobot per puntare al settore bancario degli Stati Uniti. Il gruppo identifica le estensioni dei software vulnerabili sui computer collegati a siti web a elevata larghezza di banda e a data center

ATTACCHI ECONOMIC DDOS

Quando un provider di servizi cloud ospita la vostra applicazione, l'infrastruttura cloud può espandersi per gestire le impennate di traffico durante un attacco DDoS. In genere l'azienda paga in base alla larghezza di banda utilizzata. Se un attacco DDoS consuma notevoli risorse, è possibile che i server restino attivi, ma la spesa di mantenimento di tale operatività potrebbe essere insostenibile da parte dell'azienda. Il costo di CPU o larghezza di banda negli ambienti host, come Amazon Web Services, può essere elevatissimo.

http://www.prolexic.com/knowledge-center-dos-and-ddos-threat-advisories.html



di web hosting. Compromette e controlla quindi questi computer inserendo codice incorporato pressoché invisibile nelle estensioni HTML. I computer slave di questa botnet a elevata larghezza di banda possono bombardare i siti web delle banche con attacchi DDoS di potenza pari a 190 Gbps. Un rapporto sul toolkit itsoknoproblembro con regole di rilevamento per identificare i server web infetti (bRobot) può essere scaricato qui }

I 10 principali trend DDoS per il 2013

Il 2013 ha segnato un record nell'attività degli attacchi

DDoS, come mostrato in questa infografica sui trend DDoS.

Rispetto all'anno precedente, il volume degli attacchi DDoS è aumentato del 32% secondo

una ricerca Prolexic.



I clienti Akamai hanno segnalato

768 attacchi a livello di applicazione nel 2012

e 1153 nel 2013, ovvero un aumento del

50% su base annua.

Per ulteriori informazioni, consultate il rapporto di Akamai sullo Stato di Internet: http://www.akamai.com/stateofthe internet/

LINK }

Veracode prevede

che tre aziende su quattro saranno a un

certo punto bersaglio di exploit contro le

applicazioni web e che le applicazioni web

rappresenteranno il 54% delle violazioni

totali dei dati dovute ad hacker.

DuPaul, Neil (luglio 2013). The Real Cost of a Data Breach Infographic. Informazioni tratte da http://www.veracode.com/

blog/2013/07/the-real-cost-of-a-databreach-infographic/

Il livello di rete non è più l'unico bersaglio degli attacchi DoS. Gli attacchi a livello di applicazione, oggi sempre più diffusi, appaiono come richieste legittime, ma causano un denial of service attraverso l'esaurimento delle capacità dei server delle applicazioni web. Questi attacchi possono indurre il server a utilizzare notevoli risorse di elaborazione per ogni richiesta, a operare con perfomance inferiori a quelle ottimali o a restituire risultati diversi per ogni richiesta per impedire il caching sul server.

Attacchi a elevato consumo della larghezza di bandaGli attacchi a livello di applicazione a elevato consumo della larghezza di banda solitamente bombardano le pagine che richiedono numerose risorse con richieste GET o POST e reimpostano ripetutamente la connessione per esaurire la capacità delle sessioni e della memoria del server. In alternativa, effettuano richieste complesse a elevato utilizzo di calcolo oppure richiedono file di grandi dimensioni, ad esempio PDF, al sito web. Il risultato è un consumo eccessivo di risorse che mette fuori uso i server per impedire ad essi di rispondere al traffico legittimo. Gli esempi includono attacchi che:

Attacchi DoS/DDoS a livello di applicazione

http://www.akamai.com/stateoftheinternet/


rete, poiché richiedono un numero molto minore di nodi e una bassa larghezza di banda. Inoltre, dato che spesso gli autori di tali attacchi usufruiscono di funzionalità legittime dell'applicazione, la distinzione tra l'attacco e il traffico legittimo non è sempre evidente. La difesa diventa quindi notevolmente più difficile.

Alcuni esempi di attacchi a basso consumo della larghezza di banda sono quelli che mantengono aperte le risorse e gli attacchi ai carrelli degli acquisti:

Attacchi che mantengono aperte le risorse Alcuni attacchi mantengono aperte le risorse sul server in modo da esaurire i pool di connessioni e le risorse del server. Questo approccio è molto più efficiente rispetto a quello del GET flood. Richiede infatti solo centinaia di richieste a intervalli regolari anziché migliaia in modo continuo e un singolo dispositivo può mettere fuori uso un sito di grandi dimensioni. Ad esempio:

• Slowloris distribuisce lentamente intestazioni di richieste, obbligando il server web a tenere aperte le connessioni senza completare le richieste. Il pool di connessioni del server si esaurisce quindi rapidamente.

• Slow HTTP POST distribuisce lentamente il corpo di un messaggio per esaurire le risorse del server web.

• Slow Read riduce la finestra TCP sul lato client, obbligando il server a inviare i dati al client molto lentamente. Il server è costretto a mantenere aperte le connessioni e altre risorse per garantire l'invio dei dati e di conseguenza può rapidamente diventare sovraccarico.

• Sfruttano il protocollo SSL (Secure Sockets Layer): il traffico di alcune pagine, ad esempio la pagina di login, deve essere crittografato tramite SSL per proteggere le credenziali degli utenti dei dispositivi mobili. Sono necessari nove passaggi per stabilire un handshake SSL, molti dei quali richiedono complesse operazioni crittografiche e di generazione di chiavi. Se l'autore di un attacco utilizza una botnet per stabilire numerose sessioni SSL simultaneamente, l'applicazione diventa non disponibile poiché il sistema si interrompe a seguito dell'elaborazione delle precedenti richieste.

• Sovraccaricano il database: una pagina basata su un database, ad esempio un localizzatore di punti vendita, ha bisogno di raggiungere il database ad ogni richiesta, operazione che tipicamente comporta un elevato numero di transazioni diverse o complesse del database, nonché la convalida a livello di campo e altre tecniche per la difesa da altri attacchi a livello di applicazione. L'invio continuo di queste richieste sovraccaricherà il server del database.

• Attaccano la pagina di un modulo: le pagine dei moduli hanno bisogno di accedere a un database ad ogni richiesta. Gli autori degli attacchi possono causare elaborazioni non necessarie del database, ad esempio utilizzando numeri casuali anziché codici CAP reali oppure inoltrando password di enormi dimensioni.

Attacchi a basso consumo della larghezza di bandaMolti attacchi a livello di applicazione sfruttano le conoscenze che l'hacker ha dell'applicazione e del modo in cui violarla. Questi attacchi possono essere molto più efficaci rispetto a quelli di sovraccarico della


In un attacco di alto profilo, un gruppo di hacktivisti

ha utilizzato il metodo SQL injection per rubare le

informazioni relative a oltre 1,6 milioni di account

appartenenti a organizzazioni governative statunitensi,

tra cui la NASA, l'FBI e il Pentagono.

VII. Newton, Casey (dicembre 2012). GhostShell claims breach of 1.6M accounts at FBI, NASA, and more. Informazioni tratte da http://news.cnet.com/8301-1009_3-57558338-83/ghostshell-claims-breach-of-1.6m-accounts-at-fbi-nasa-and-more/

Talvolta gli attacchi DoS operano in unione ad attacchi

che puntano ai dati, agendo come elementi di distrazione

mentre l'hacker ruba i dati. Il team Counter Threat Unit di

Dell SecureWorks ha riferito che un popolare toolkit DDoS

chiamato Dirt Jumper veniva utilizzato per sviare l'attenzione

dei dipendenti bancari da tentativi di trasferimenti

fraudolenti di importi fino a 2,1 milioni di dollari.

Brenner, Bill (agosto 2013), DDoS Attacks Used as a Cover for Other Crimes

LINK }

Uso improprio dei carrelli degli acquisti L'autore di un attacco può inserire vari articoli in carrello, abbandonarlo per un po' e quindi tornare per aggiornarlo, posponendo la scadenza della sessione e obbligando il database a caricare di nuovo il carrello. Se l'autore inserisce un elevato numero di prodotti nel carrello, le risorse consumate sono considerevoli.

Attacchi di furto di dati Mentre gli attacchi DoS/DDoS rendono inutilizzabile un sito, gli attacchi di furto di dati possono anche avere un impatto diretto sui risultati economici finali. Le organizzazioni sono esposte a un numero crescente di attacchi progettati per rubare dati. Questi attacchi sfruttano solitamente le vulnerabilità presenti nella applicazioni web e possono essere difficili da individuare poiché generano un traffico che appare legittimo ai tradizionali strumenti per la sicurezza a livello di rete.

I tentativi di furto di dati assumono spesso la forma di attacchi di tipo command injection. Con questi tipi di attacchi, un hacker introduce comandi in un'applicazione vulnerabile e può quindi eseguirli per visualizzare dati, cancellarli o assumere il controllo del computer. Le "injection flaws" si verificano quando l'applicazione manca della corretta convalida dei dati di input, condizione che consente all'autore dell'attacco di manipolare l'input per includere dati inattendibili in un comando o in una query. I tipi di attacchi command injection più comuni includono SQL injection, Remote File Inclusion e Local File Inclusion:

https://blogs.akamai.com/2013/08/DDoS-Attacks-Used-As-Cover-For-Other-Crimes.html


SQL injection L'attacco SQL injection sfrutta la codifica non corretta delle applicazioni web per consentire agli hacker di introdurre comandi SQL, ad esempio in un modulo di login, che permettono loro di eseguire query direttamente sui dati contenuti in un sito web. Funzionalità quali le pagine di login, i moduli di richiesta di supporto e di prodotti, i moduli di feedback, le pagine di ricerca e i carrelli di acquisto sono

tutte soggette ad attacchi SQL injection.

Remote File Inclusion Remote File Inclusion (RFI) è una vulnerabilità dei siti web che consente all'autore dell'attacco di utilizzare uno script per includere un file remoto sul server web. L'hacker può quindi svolgere ogni azione, dall'esecuzione di codice sul server web per il furto temporaneo di dati

fino all'assunzione del controllo di un server vulnerabile.

Local File Inclusion Local File Inclusion (LFI) è simile alla vulnerabilità Remote File Inclusion tranne che, anziché file remoti, possono essere inclusi solo file locali,

ovvero file sul server corrente.

Attacchi account checker L'account checker è un altro attacco popolare che punta ai dati dei clienti. Questi attacchi si verificano quando i cybercriminali utilizzano strumenti e script di attacco automatizzati chiamati account checker

per determinare combinazioni valide di ID utente/password. Una volta violato l'account, l'autore dell'attacco raccoglie i dati personali dell'utente e della sua carta di credito per utilizzarli in altre frodi. Gli autori nascondono i propri attacchi scorrendo un elenco di proxy aperti. Gli attacchi account checker possono inoltre causare una condizione DDoS quando l'hacker non configura correttamente i suoi strumenti: questi tenteranno di trovare i nomi utente e le password quanto più velocemente possibile, sovraccaricando i server attaccati.


Nel terzo trimestre del 2013, il Syrian Electronic Army

(SEA), un gruppo di hacktivisti che sostiene il regime del

presidente siriano Bashar Hafez al-Assad, ha rivendicato

il lancio di una serie di attacchi di phishing contro

i registrar DNS di numerose aziende. Uno di questi

attacchi ha compromesso un account di amministrazione

di un motore di rilevamento di contenuti di terze parti.

Nell'ambito dell'attacco, è stato introdotto codice

dannoso nei contenuti forniti ai clienti. Questi attacchi

hanno consentito al SEA di reindirizzare il traffico

diretto ai domini legittimi verso uno controllato dal

gruppo. Qualsiasi visitatore di un sito web coinvolto

veniva inviato a syrianelectronicarmy.com, una pagina di

propaganda del SEA.

Rapporto sullo stato di Internet del terzo trimestre 2013

LINK }

Attacchi al DNS Il DNS è un anello debole della sicurezza web. Oltre che agli attacchi DDoS e a quelli basati sull'amplificazione, il DNS è soggetto a minacce che includono hijacking del registrar e reindirizzamento/cache poisoning.

Hijacking del registrarIl registrar dei nomi di dominio gestisce la prenotazione dei nomi di dominio di Internet. Gli attacchi di tipo hijacking del registrar utilizzano tecniche di social engineering contro i dipendenti dell'assistenza clienti del registrar. Se l'autore dell'attacco può utilizzare un attacco di phishing per compromettere l'account di un'organizzazione presso il relativo registrar, ottiene il controllo del nome di dominio e può dirigerlo ai server che desidera, inclusi i server dei nomi, i server web, i server di posta elettronica e così via. Il dominio potrebbe persino essere trasferito a un nuovo proprietario.

Reindirizzamento/cache poisoningNegli attacchi di reindirizzamento del DNS, l'autore reindirizza le query per i nomi DNS ai server sotto il suo controllo pubblicizzando un falso protocollo di routing per reindirizzare il traffico ai propri server. In alternativa, gli autori inquinano la cache di un server DNS con dati DNS errati che indirizzano le query future ai server sotto il loro controllo.



1,5TBPSDI TRAFFICO DI RETE

AKAMAI PREVEDE CHE ENTRO IL 2020 UN ATTACCO DDOS GENERERÀ IN MEDIA


Gli attacchi DoS/DDoS diretti a livello di rete

e a livello di applicazione utilizzano tecniche

diverse. La vostra azienda deve difendersi da

entrambi. Qualsiasi strumento utilizziate, l'azienda

deve adottare un approccio multilivello per

proteggere le applicazioni web dagli attacchi

DoS e dal furto di dati. Gli sforzi volti a ridurre

al minimo le vulnerabilità delle applicazioni

creeranno una difesa sia dagli attacchi DoS a livello

di applicazione che dai tentativi di furto dei dati.

CAPITOLO 2

Un approccio

multilivello alla

SICUREZZA DELLE APPLICAZIONI WEB


La difesa dagli attacchi DoS a livello di rete impone un duplice

approccio. Innanzitutto, è necessaria una larghezza di banda

della rete sufficiente a gestire con facilità elevatissime quantità

di traffico. Occorre inoltre una soluzione per filtrare il traffico

degli attacchi in modo da consentire il passaggio del traffico

legittimo e bloccare quello degli attacchi.

Difesa dagli attacchi DoS a livello di rete


È possibile eliminare molte vulnerabilità a livello di applicazione

praticando una corretta igiene delle applicazioni web

e utilizzando un ciclo di vita di sviluppo software sicuro.

Ad esempio, è necessario rafforzare ogni applicazione mediante

una configurazione sicura nonché aggiornamenti e patch

tempestive. Gli sviluppatori dovrebbero pensare alla sicurezza

nelle fasi relative ai requisiti, all'architettura e alla progettazione

delle applicazioni. Dovrebbero inoltre creare delle protezioni

di sicurezza all'interno del software, come ad esempio una

sufficiente convalida dell'input per essere certi che l'applicazione

non possa essere attaccata mediante tecniche di command

injection. Tutte le configurazioni e le applicazioni dovrebbero

essere testate attentamente per individuarne eventuali

vulnerabilità. Per ulteriori informazioni su come garantire una

corretta igiene delle applicazioni web, consultate il Capitolo 5.

Protezione delle applicazioni dagli attacchi DoS e dal furto di dati

L'igiene Internet è però raramente perfetta. È opportuno

difendersi da qualsiasi vulnerabilità non protetta utilizzando

anche un WAF (Web Application Firewall). Il WAF può prevedere

l'applicazione di patch virtuali: è infatti possibile programmare

regole nel WAF per proteggersi dalle nuove vulnerabilità fino

a quando il personale IT non sarà in grado di applicare la patch

effettiva. Il WAF fornisce anche un'altra linea di difesa sia dalle

minacce che puntano ai dati (come gli attacchi SQL injection

che sfruttano le vulnerabilità a livello di applicazione) che dagli

attacchi DoS a livello di applicazione (come la manipolazione

delle sessioni di tipo Slowloris). Naturalmente, un WAF isolato

sarà probabilmente sopraffatto come qualsiasi altro dispositivo

da un attacco DoS. Di conseguenza, anche il WAF ha bisogno

di funzionalità anti-DoS e di protezioni architetturali che lo

proteggano dagli attacchi più aggressivi. Per ulteriori informazioni

su cosa ricercare in un WAF, consultate il Capitolo 4.


Nessuna soluzione di sicurezza è adatta a tutte le

situazioni.

È importante comprendere le proprie risorse e i propri

rischi e trovare la soluzione giusta per la propria

azienda. Per affrontare i vari aspetti della sicurezza delle

applicazioni web descritti nel Capitolo 2 di questa guida,

sono disponibili varie soluzioni commerciali. Queste

includono hardware in loco e servizi basati su cloud.

CAPITOLO 3

Analisi delle OPZIONI DISPONIBILI


Per proteggersi, la maggior parte delle organizzazioni si affida a dispositivi hardware installati in loco nei propri data center, ad esempio firewall di rete, soluzioni di mitigazione DDoS e WAF. L'installazione e l'implementazione di questi dispositivi in loco richiede ingenti investimenti di capitali iniziali con un ciclo di vita dell'hardware e un ammortamento di circa due-tre anni. Data l'attuale carenza di competenze, l'assunzione di esperti con le conoscenze giuste per utilizzare in modo corretto questi dispositivi hardware per mitigare gli attacchi può essere costosa e difficile.

Difendersi dagli attacchi a livello di applicazione può richiedere numerose risorse. I WAF necessitano di elevate quantità di risorse di elaborazione e di processi che possono ridurre le performance.

La maggior parte dei dispositivi rappresenta un single point of failure e non può assorbire gli attacchi DDoS senza subirne conseguenze. Inoltre, i dispositivi hardware in loco tentano per definizione di arrestare un attacco DDoS solo dopo che questo è penetrato nel data center. Si tratta di un single point of failure contro una delle minacce alla sicurezza più diffuse. Se poi l'organizzazione non dispone di un collegamento Internet di portata sufficiente, l'attacco

saturerà la larghezza di banda disponibile causando l'interruzione dell'intero data center. In alternativa, un attacco può danneggiare altre infrastrutture del data center, come router, firewall di rete e bilanciatori del carico. Anche quando le soluzioni adottate proteggono dagli attacchi, gli attacchi a elevato consumo della larghezza di banda possono ridurre le performance previste per gli utenti legittimi. Con la crescita dell'ampiezza degli attacchi DDoS, le organizzazioni dovranno continuare ad aggiungere ulteriore larghezza di banda per garantirsi una portata sufficiente e, se dispongono di più data center, i costi possono aumentare in modo esponenziale.

I servizi basati su cloud risiedono all'esterno del data center dell'azienda in modo da proteggere il traffico prima che raggiunga l'infrastruttura aziendale. Esistono due tipi principali di servizi anti-DoS/DDoS basati su cloud: quelli che indirizzano il traffico sospetto a una posizione centralizzata dove il traffico dannoso viene escluso e i servizi di protezione dei siti web che utilizzano reti CDN (reti per la distribuzione dei contenuti) per assorbire e ispezionare il traffico dannoso su una rete distribuita di server a protezione dei siti web e delle applicazioni aziendali.

Hardware in loco


Provider di soluzioni di mitigazione degli attacchi DDoSI provider di soluzioni di mitigazione degli attacchi DDoS gestiscono "scrubbing center" che utilizzano un mix di apparecchiature, regole tecniche e interazioni umane dirette per fornire protezione contro gli attacchi DoS e DDoS. Questi data center privati sono dotati di elevata larghezza di banda per elaborare i flussi in entrata e mantenere disponibili i siti.

Tali aziende offrono alcuni dei sistemi di protezione più completi contro gli attacchi DoS/DDoS, in quanto gestiscono tutti i tipi di attacchi, dai semplici flood a quelli che sfruttano i protocolli HTTP/S, FTP e altre applicazioni non web.

La modalità di funzionamento di tali servizi può essere di tipo "always-on" oppure "on demand".

• I servizi always-on monitorano continuamente il traffico per individuare eventuali attività sospette che sono indicazione di un attacco. La mitigazione always-on è come un ammortizzatore che protegge il cliente dal primo forte impatto sulla rete quando viene sferrato un attacco DDoS e di conseguenza fornisce una protezione più robusta contro i costosi tempi di inattività dei siti.

• Le opzioni on demand offrono performance migliori e maggiore convenienza. Utilizzando protocolli di routing IP standard, è facile intercettare il traffico in arrivo e ispezionarlo per individuare eventuali anomalie mediante servizi di mitigazione fuori banda. Il traffico in uscita non viene ispezionato e viene ad esso consentito di seguire il suo normale percorso. Il traffico legittimo viene identificato e inoltrato, mentre quello associato a un attacco dannoso viene scartato o "pulito".

Entrambi i tipi di servizi presentano potenziali problemi di cui tenere conto. I servizi SOC (centro operativo per la sicurezza) di tipo always-on sono più costosi e l'ispezione continua del traffico riduce ulteriormente le performance dei siti. Quando si utilizza una soluzione on demand, l'azienda deve determinare quando attivare il servizio e contattare il fornitore per attivarlo. Le soluzioni on demand non sono inoltre in grado di rilevare attacchi che si verificando nel corso del tempo, ad esempio gli attacchi SQL injection. Le organizzazioni sono pertanto esposte ad attacchi che puntano al furto dei dati o al danno di immagine.

Servizi basati su cloud


Servizi di protezione dei siti web I servizi di protezione dei siti web utilizzano le CDN per fornire sicurezza a livello di rete e di applicazione per siti e applicazioni web. Come un proxy basato su cloud, queste reti sono poste prima dell'infrastruttura IT dell'azienda e distribuiscono il traffico diretto dagli utenti finali ai siti e alle applicazioni web aziendali. La piattaforma cloud esamina il traffico di rete per rilevare eventuali pattern di attacco noti e trasferisce solo il traffico legittimo all'applicazione web.

Queste soluzioni operano in linea, per cui le organizzazioni sono sempre protette senza alcuna interazione umana. Possono inoltre mitigare gli attacchi nuovi e non osservati in precedenza. Alcuni servizi includono la tecnologia WAF e proteggono dagli attacchi alle applicazioni come quelli di tipo SQL injection.

Le CDN sono per loro natura create con un'infrastruttura distribuita, ovvero sono costituite da server dislocati in tutto il mondo. Affinché abbia successo, un attacco DoS deve puntare a sovraccaricare ognuno di questi server simultaneamente. Le CDN sono progettate specificamente per gestire elevati volumi di traffico, rendendo difficile questa attività agli autori degli attacchi. Allo stesso tempo, queste soluzioni offrono servizi di accelerazione per ridurre l'impatto sulle performance e contemporaneamente migliorare le performance end-to-end dell'applicazione web.

Un potenziale problema per le CDN è dato dal fatto che alcune di queste soluzioni provengono da fornitori di più piccole dimensioni che non dispongono dell'infrastruttura necessaria per garantire una protezione globale e/o una protezione dagli attacchi DDoS di ampia scala. Negli ultimi anni alcuni fornitori hanno subito interruzioni importanti e i clienti sono stati colpiti da attacchi DDoS di ampia scala diretti contro altri clienti. Un supporto clienti limitato o assente può anche lasciare ai clienti il compito di gestire la risposta agli attacchi subiti. Inoltre, se alcune CDN non includono la tecnologia WAF altre che la prevedono potrebbero non fornire una protezione sufficiente contro molti attacchi a livello di applicazione.


Come scegliere UNA SOLUZIONE

CAPITOLO 4

Ogni azienda è differente. Occorre quindi trovare

la soluzione adatta alle proprie esigenze. Questa

sezione vuol essere una guida per aiutarvi a porvi

le domande giuste in modo da poter prendere le

decisioni migliori per la vostra organizzazione.


IDG Research ha rilevato che sono

in media necessarie dieci ore prima

che un'azienda possa iniziare a

risolvere un attacco DDoS. In media,

un attacco DDoS non viene rilevato

prima di 4,5 ore dal suo inizio e

trascorrono altre 4,9 ore prima che la

mitigazione possa iniziare. Con costi

di interruzione che si aggirano sui $

100.000 all'ora, un attacco DDoS può

costare a un'azienda che si basa su

Internet fino a $ 1 milione prima che

si inizi a mitigare l'attacco.

Fonte: http://www.infosecurity-magazine.com/view/35238/a-ddos-attack-could-cost-1-million-before-mitigation-even-starts

LINK }

La difesa dagli attacchi DoS volumetrici che si verificano a livello di rete richiede un'architettura di rete resiliente che sia in grado di assorbire grandi esplosioni di traffico e che filtri tutto il traffico in modo che sulla rete sia consentito solo il traffico web. Alcune considerazioni chiave in merito:

Offre una protezione positiva?Molti attacchi DDoS a livello di rete possono essere arrestati consentendo solo il traffico HTTP legittimo sulla rete, ad esempio sulla porta 80 (HTTP) o sulla porta 443 (HTTPS). La soluzione deve escludere tutto l'altro traffico non associato alle applicazioni, come pacchetti TCP SYN eccessivi, flussi di pacchetti ICMP o UDP senza payload delle applicazioni.

La soluzione assorbe tutto il traffico degli attacchi?Non tutti gli attacchi puntano ad applicazioni o servizi web. Alcuni tenteranno di penetrare tramite porte FTP o non web. Per una protezione completa, cercate una soluzione in grado di valutare tutto il traffico.

La soluzione è di tipo always-on?I controlli di sicurezza proteggono il sito o l'applicazione web solo se sono attivi e operativi. È necessario determinare il livello di disponibilità promesso dalla soluzione e il modo in cui viene fornito. Occorre acquistare più versioni ridondanti di un controllo di sicurezza per garantire la disponibilità? Il provider della soluzione garantisce la disponibilità con uno SLA (accordo sul livello di servizio)?

Protezione dagli attacchi DoS e DDoS a livello di rete

http://www.infosecurity-magazine.com/view/35238/a-ddos-attack-could-cost-1-million-before-mitigation-even-starts


La soluzione fornisce larghezza di banda scalabile per gestire il volume dell'attacco?Un attacco DDoS comune potrebbe generare la quantità di traffico che un sito riceve normalmente in due anni. Per mantenere disponibile il sito, la soluzione deve gestire tutto questo traffico. Anche se l'azienda potrebbe non essere in grado di acquistare direttamente capacità sufficiente dato che resterà inutilizzata per la maggior parte del tempo, molti provider di servizi cloud consentono di accedere all'occorrenza alla larghezza di banda aggiuntiva necessaria per assorbire un attacco. Chiedete al provider quali flussi di picco può accogliere.

La soluzione contrasta gli attacchi economic DDoS ponendo un limite massimo alle spese associate ai picchi di traffico?Quando i provider di servizi cloud forniscono larghezza di banda aggiuntiva per contrastare

un attacco DDoS, spesso addebitano il traffico in più. Di conseguenza, anche se il provider di servizi cloud è in grado di proteggere il vostro sito, l'azienda potrebbe non essere in grado di sostenerne il costo. Cercate un provider che ponga un limite alle spese associate ai servizi.

La soluzione arresta gli attacchi prima che raggiungano il vostro data center?Considerate l'impatto potenziale di un attacco sul vostro intero data center. Le soluzioni cloud sono progettate per arrestare un attacco prima che raggiunga il data center. Questo significa non doversi preoccupare degli attacchi DDoS che impattano sul data center. Per contro, i dispositivi in loco vi proteggono dopo che l'attacco ha raggiunto il dispositivo: questo significa che l'attacco invaderà il data center. Se si dispone di una soluzione in loco, sarà necessario predisporre risorse sufficienti in tutta l'infrastruttura del data center (larghezza di banda della rete, router e firewall) per sostenere un attacco.

Gli attacchi DDoS sono diventati uno

dei trigger più comuni di interruzioni

dei data center, causando il 18% di

quelle riscontrate nei 67 data center

statunitensi che hanno partecipato

a uno studio condotto nel dicembre

2013 dal Ponemon Institute. Quando

nel 2010 Ponemon ha interpellato

per la prima volta i data center per

quanto riguarda le interruzioni, gli

attacchi DDoS rappresentavano la

causa solo del 2% delle interruzioni.

Fonte: http://www.networkcomputing.com/next-generation-data-center/news/servers/ddos-attacks-wreak-havoc-on-data-centers/240164503

LINK }

http://www.networkcomputing.com/next-generation-data-center/news/servers/ddos-attacks-wreak-havoc-on-data-centers/240164503


La soluzione influisce sulle performance?Le applicazioni di e-commerce e streaming multimediale richiedono performance eccellenti. Tuttavia, molti controlli di sicurezza impongono un compromesso tra sicurezza e performance. Ad esempio, un WAF esamina tutto il traffico associato alle applicazioni diretto da ogni utente all'applicazione. Quanto maggiore è il traffico e quanti più sono i tipi di attacco, tante più regole sono necessarie e tanti più dispositivi hardware sono richiesti per elaborare i pacchetti senza compromettere le performance. Per mantenere performance ottimali, cercate una soluzione architettata sia per le performance che per la sicurezza.

La soluzione è in linea?Le soluzioni in linea operano continuamente per monitorare e contrastare gli attacchi, sia che siate consapevoli degli attacchi o meno. Tuttavia, per ridurre l'impatto dei

controlli di sicurezza sulle performance, alcune organizzazioni scelgono una soluzione fuori banda che si attiva solo quando si capisce che un attacco è in corso. Queste soluzioni fuori banda non impediranno in modo proattivo che un attacco si ripercuota sui sistemi aziendali. Inoltre, non essendo sempre disponibili, queste soluzioni non riescono a proteggere dagli attacchi meno evidenti, ad esempio da codice dannoso che viene introdotto nei sistemi per rubare dati.

Qual è il costo totale di proprietà?Molti responsabili della sicurezza considerano il prezzo di una soluzione ma non il costo totale di proprietà. Quando determinate il TCO (costo totale di proprietà), considerate il costo del dispositivo, dei sistemi ridondanti per garantire la disponibilità nonché di gestione della soluzione. Valutate inoltre le spese di una violazione dei dati rispetto all'efficacia della protezione da questi attacchi offerta dalla soluzione.

OVUM, società di analisi del settore del Regno Unito, ha recentemente pubblicato un white paper da titolo "Delivering Effective DDoS Protection". L'autore Andrew Kellet, Principal Analyst, Security, ha notato che non tutte le soluzioni di sicurezza sono in grado di fornire il livello necessario di protezione dagli attacchi DDoS. Consiglia quindi alle organizzazioni di valutare i provider di soluzioni di mitigazione degli attacchi DDoS a fronte di 10 criteri aziendali:

1. Ricchezza di esperienza 2. Possibilità di fornire una capacità di

rete di mitigazione dedicata 3. Abilità comprovata e risorse globali

per mitigare gli attacchi più vasti e complessi in Internet

4. Innovazione delle tecnologie di mitigazione degli attacchi DDoS

5. Competenze umane nelle prime linee della protezione dagli attacchi DDoS

6. Velocità di mitigazione e garanzie fornite dagli SLA

7. Mitigazione a livello SSL 8. Flessibilità di erogazione dei servizi 9. Conoscenza delle minacce 10. Visibilità della rete in tempo reale


Protezione dagli attacchi a livello di applicazione

Gli attacchi a livello di applicazione richiedono un approccio più differenziato rispetto alla difesa dagli attacchi a livello di rete. Molti attacchi a livello di applicazione, sia che si tratti di attacchi DoS o di tentativi di furto di dati, si basano sul traffico legittimo. Ad esempio, gli attacchi DDoS a livello di applicazione e le transazioni legittime di un'applicazione iniziano entrambi con una semplice richiesta all'applicazione.

La maggior parte delle organizzazioni affronta questi attacchi in uno dei due seguenti modi:

1. Eliminazione delle vulnerabilità presenti nelle applicazioni seguendo un ciclo di vita di sviluppo software sicuro e una buona igiene Internet, come descritto nel Capitolo 5.

2. Applicazioni front-end con un WAF.

Il nostro consiglio? Utilizzare entrambe le soluzioni.

Naturalmente, un WAF può essere preso di mira e sopraffatto così come qualsiasi altro componente della rete. Deve pertanto disporre di tutte le funzionalità anti-DoS e di tutte le protezioni architetturali esaminate nella precedente sezione.

È necessario conoscere le caratteristiche e le funzionalità del proprio WAF, sia che si tratti di un appliance in-house o di un servizio gestito dal proprio ISP, e il modo in cui il firewall agirà contro i diversi tipi di vettori di attacco. È inoltre necessario sapere cosa succederà alle performance di rete quando si utilizza una stateful inspection, ad esempio cookie SYN, rispetto a un stateless block sul firewall in loco.

Tenete presente che un firewall offrirà in genere una protezione limitata contro gli UDP flood e gli ICMP flood e nessuna protezione contro un SYN flood di 2 o 3 Gbps o attacchi

a livello di applicazione. I firewall forniscono scarsa o nessuna protezione anche contro gli attacchi a livello di applicazione a bassa velocità che implicano il passaggio di richieste HTTP e HTTPS attraverso il firewall. Inoltre, esiste un limite alla protezione fornita dal firewall a livello ISP basato su cloud. Non tutti i tipi di firewall ISP possono gestire ogni tipo di attacco DDoS e alcuni ACL possono fallire, specialmente se sono implementati su un numero ridotto di dispositivi in prossimità del server.

Se si dispone di un firewall in loco o si utilizzano ACL a livello ISP, la gestione dei firewall nell'ambito di una strategia di difesa DDoS interna è un processo difficile che richiede l'esecuzione di molte modifiche di regole complesse durante un attacco DDoS. Trasferendo tutti questi processi complicati a un servizio di mitigazione degli attacchi DDoS basato su cloud, è possibile eliminare lunghe procedure di riconfigurazione dei firewall e di interfacciamento con l'ISP durante un attacco DDoS.


1. Qual è il livello di flessibilità e completezza delle regole WAF?I WAF eseguono sui pacchetti un'approfondita ispezione delle richieste/risposte HTTP/S e del relativo payload per identificare e proteggere da attacchi quali SQL injection, RFI e così via. Le regole WAF esaminano i formati delle richieste e degli indirizzi e determinano se corrispondono a pattern noti che suggeriscono un attacco. Se identifica questi pattern, il WAF li contrassegna e/o li blocca. Cercate un WAF che offra i seguenti tipi di regole:

}Regole che identificano problemi notiMolti attacchi sono in circolazione da lungo tempo e sono ben definiti, ad esempio gli attacchi SQL injection o le richieste che provengono da strumenti automatizzati che non fanno uso di browser. La maggior parte delle soluzioni è dotata di regole per gli attacchi ben conosciuti.

}Regole per attacchi emergentiGli attacchi sono costantemente in evoluzione. Nessuna azienda con un sito web può osservare tutti gli attacchi e sviluppare regole per proteggersi da tutti gli attacchi emergenti. Ma alcuni provider di servizi cloud osservano notevoli quantità di traffico e possono quindi rilevare i nuovi tipi di attacchi nel momento in cui appaiono, creare nuove regole per diagnosticarli e metterle a disposizione di tutti i propri clienti su scala globale.

}Regole personalizzate/applicazione di patch virtualiLe organizzazioni dovrebbero sempre installare le nuove versioni e le patch del proprio software. Le patch devono però essere testate prima di essere installate e questa attività può richiedere tempo. Una soluzione che consente di creare regole personalizzate che fungono da "patch virtuali" può impedire agli autori degli attacchi di sfruttare la vulnerabilità fino a quando non si è in grado di applicare la patch.

}Regole WAF per la consapevolezza situazionaleIn alcuni casi non si desidera bloccare necessariamente una particolare attività, ma è possibile che questa diventi sospetta e che richieda ulteriori indagini se combinata con altre azioni. Potrebbe quindi essere utile disporre di regole che informino di questi eventi. Supponiamo che l'azienda sappia che una determinata applicazione di e-commerce presenta una vulnerabilità in basket.php. Mentre una normale ricerca su Google non desterà sospetti, una ricerca sul web che punta a "nurl:basket.php" potrebbe indicare che l'autore di un attacco sta cercando di sfruttare la vulnerabilità presente in basket.php. Dovrebbe essere possibile configurare il firewall in modo da consentire il traffico di un utente che ha eseguito un'innocua ricerca su Google, bloccando però un utente che ha eseguito una ricerca su "nurl:basket.php".

Le considerazioni per la selezione di un WAF sono le seguenti:


2. Quali tipi di controlli a livello di rete offre il WAF? Il WAF fornisce controlli a livello di rete per consentire o limitare le richieste provenienti da determinati indirizzi IP in modo da proteggere il server di origine da attacchi a livello di applicazione? Cercate un WAF che fornisca i seguenti tipi di controlli:

}BlacklistUn modello di sicurezza negativo segue il principio "accetta tutti tranne ciò che è esplicitamente rifiutato". Il WAF consente di definire un elenco di indirizzi IP da bloccare?

}WhitelistUn modello di sicurezza positivo segue il principio "rifiuta tutto tranne ciò che è esplicitamente attendibile". Il WAF supporta la possibilità di definire un elenco di indirizzi IP o di intervalli di indirizzi IP consentiti?

}Blocco geograficoIl blocco geografico filtra il traffico originato da aree geografiche specifiche per mitigare gli attacchi DDoS localizzati. Una volta identificati gli indirizzi IP specifici, il traffico proveniente da tali indirizzi IP può essere bloccato o limitato prima che raggiunga l'applicazione. Il WAF supporta il blocco geografico?

3. Il WAF fornisce controlli comportamentali?La maggior parte dei WAF blocca il traffico sulla base di particolari firme o regole. Ma le regole WAF basate sul comportamento esaminano e rispondono al comportamento di un richiedente, di un indirizzo IP o di un utente sia al presente che nel corso del tempo. Ad esempio, si potrebbe scrivere una regola basata sul comportamento che esamina quante richieste effettua un utente in un determinato periodo di tempo e blocca gli utenti che effettuano un numero di richieste superiore a quello specificato

nel periodo dato. Si potrebbero anche bloccare gli utenti che effettuano un numero superiore di richieste superiore a quello specificato determinando un messaggio "errore 404 pagina non trovata".

4. Offre il mascheramento dell'origine?Un backdoor in un server web si verifica quando qualcuno ne conosce l'indirizzo IP e vi accede direttamente. Una soluzione che offre funzionalità di "mascheramento dell'origine" scherma il sito web o il server delle applicazioni da Internet, impedendo agli utenti di connettersi direttamente ad esso. Invece il provider di servizi consentirà solo all'origine di connettersi direttamente ai server sulla propria rete. Gli elenchi di controllo degli accessi del WAF del cliente determinano a quali server è consentito l'invio di traffico all'origine.


È possibile affrontare gli attacchi DDoS contro i server DNS e gli attacchi basati sulla riflessione e sull'amplificazione DNS utilizzando gli stessi controlli che mitigano tutti gli altri attacchi DDoS basati sulla rete. Ma la necessità di affrontare minacce di cache poisoning e hijacking del registrar richiede due ulteriori capacità:

La soluzione supporta le specifiche DNSSEC?Gli hacker che utilizzano attacchi di reindirizzamento/cache poisoning possono impossessarsi di qualsiasi passaggio del processo di ricerca DNS e assumere il controllo di una sessione, ad esempio, per indirizzare gli utenti a propri siti web ingannevoli per la raccolta dei dati relativi ad account e password. La soluzione è un'implementazione end-to-end delle specifiche DNSSEC (DNS Security Extensions). Le specifiche DNSSEC

dovrebbero essere utilizzate per applicare firme digitali ai dati al fine di garantirne la validità e implementate a ogni passaggio del processo di ricerca per garantire che l'utente finale si connetta con il sito web o il servizio effettivo che corrisponde a un particolare nome di dominio. Per sfruttare le specifiche DNSSEC, occorre un sistema interno di gestione delle chiavi o un provider di servizi che fornisca il servizio di gestione delle chiavi e sia in grado di servire il traffico DNSSEC.

Il provider di servizi utilizza un registrar attendibile?

Molti registrar non dispongono di processi di business sicuri per la protezione dagli attacchi di phishing che causano il trasferimento del sito dal registrar. Cercate un provider di servizi di sicurezza per le applicazioni web basati su cloud che offra i propri servizi di registro con controlli rigorosi per evitare attacchi di social engineering.

Per ulteriori informazioni sui WAF:

1. Il cloud e gli attacchi DDoS sul web: https://blogs.akamai.com/2014/04/

cloudification-of-web-ddos-attacks.

html/

2. Come si presenta un attacco web al team Professional Services di Akamai: https://blogs.akamai.com/2014/03/what-

a-web-attack-looks-like-to-akamais-

professional-services-team-lessons-from-

the-defense-of-a-rec.html/

3. Elenco di controllo per gli attacchi DDoS: https://blogs.akamai.com/2014/03/a-

ddos-checklist.html/

Protezione dagli attacchi al DNS

https://blogs.akamai.com/2014/%2003/what-a-web-attack-looks-like-to-akamais-professional-services-team-lessons-from-the-defense-of%20-a-rec.html/











https://blogs.akamai.com/2014/03/a-ddos-%20checklist.html/





CAPITOLO 5

Nessuna soluzione può risolvere ogni sfida posta alla

sicurezza. È necessario adottare un approccio multilivello.

Le soluzioni ottimali per la sicurezza in Internet sono una

combinazione di soluzioni di sicurezza acquistate e di

misure interne volte a ridurre al minimo le vulnerabilità dei

siti e delle applicazioni web.

IGIENE INTERNET: quali sono le vulnerabilità più comuni delle applicazioni web e come vanno affrontate


Il primo passo per affrontare le vulnerabilità delle applicazioni web consiste nel comprendere da dove provengono e quali sono quelle che più probabilmente influiranno sui sistemi. Si possono trovare vulnerabilità sia nelle applicazioni personalizzate (sviluppate in-house) che nel software di terze parti.

Vulnerabilità nelle applicazioni personalizzateLe organizzazioni che scrivono le proprie applicazioni sono soggette a vulnerabilità a seguito della progettazione o dell'implementazione non sicura. Queste vulnerabilità vengono definite sconosciute o specifiche dell'applicazione poiché sono sconosciute agli hacker prima della loro interazione con l'applicazione.

Vulnerabilità di software di terze partiAnche se gli hacker possono andare a caccia di vulnerabilità nel software personalizzato, è molto più facile attaccare quelle presenti nel software di terze parti. La maggior parte delle applicazioni

per il web utilizza software commerciali contenenti vulnerabilità, come plug-in, software di forum web o software di blog. I ricercatori che operano nel campo della sicurezza scoprono i punti deboli di questi prodotti popolari, ne informano il fornitore ed emettono quindi un avviso pubblico riguardante il problema.

Tutti, inclusi gli hacker, possono accedere a queste pubblicazioni. Conoscendo questi problemi noti, gli hacker battono in lungo e in largo Internet per individuare i computer che contengono tali vulnerabilità, in particolare di tipo SQL injection, Remote File Inclusion e Local File Inclusion. Poiché gli amministratori e i proprietari dei siti impiegano solitamente un po' di tempo per applicare patch ai propri siti, gli autori degli attacchi possono sempre trovare computer vulnerabili.

Di recente, gli hacker hanno scoperto che è meglio assumere il controllo dei server web anziché dei computer degli utenti, poiché i primi dispongono di una maggiore larghezza di banda e possono essere utilizzati per generare in seguito volumi di attacchi molto più vasti.

OWASP (Open Web Application Security Project) è una community aperta impegnata che aiuta le organizzazioni a sviluppare, acquistare e mantenere applicazioni attendibili. Nella sua Top 10 List vengono identificati i rischi più critici che le organizzazioni devono oggi affrontare.

1. Injection

2. Interruzione dell'autenticazione e della gestione della sessione

3. Attacchi XSS (Cross-Site Scripting)

4. Riferimenti a oggetti diretti non sicuri

5. Errata configurazione della sicurezza

6. Esposizione di dati sensibili

7. Assenza di controllo degli accessi a livello di funzione

8. Vulnerabilità CSRF (Cross-Site Request Forgery)

9. Utilizzo di componenti vulnerabili noti

10. Reindirizzamenti e inoltri non convalidati

Quali sono le vulnerabilità più diffuse?


Per ridurre al minimo le vulnerabilità all'interno delle applicazioni web, è importante migliorare l'igiene Internet. Questo significa seguire le seguenti best practice per la progettazione, l'implementazione, la configurazione e la manutenzione delle applicazioni:

Mantenere aggiornato il software e installare le patch più recentiNessun codice è perfetto. Prima o poi i difetti vengono alla luce. I più gravi sono quelli che mettono a rischio la sicurezza. La prima linea di difesa contro gli attacchi dannosi consiste nell'utilizzare la versione più aggiornata del software del server web e del server delle applicazioni e nell'installare patch di sicurezza il più presto possibile.

I plug-in e i componenti aggiuntivi del software, ad esempio i plug-in WordPress, possono essere particolarmente vulnerabili perché sono spesso sviluppati da programmatori inesperti o provengono da fonti che non sempre seguono le linee guida di codifica. Utilizzate solo i plug-in necessari e assicuratevi che siano aggiornati.

Definire configurazioni sicure Un'errata configurazione della sicurezza può verificarsi a qualsiasi livello dello stack delle applicazioni, tra cui piattaforma, server web, server della applicazioni, database e codice personalizzato. Gli sviluppatori e gli amministratori di sistema devono collaborare per garantire che l'intero stack sia configurato correttamente.

Elementi da considerare per una configurazione sicura:• Appropriato utilizzo della crittografia per i dati

in motion e i dati at rest• Rimozione degli account inutili• Disattivazione o rimozione dei servizi non

necessari• Osservanza del principio di privilegio

minimo È facile configurare in modo non corretto un server web e consentire a utenti malintenzionati di raggiungere posizioni che si intendeva invece proteggere: pagine di amministrazione, elenchi di directory, elementi che gli utenti normali non dovrebbero vedere e che invece consentono agli hacker

di allestire un attacco più grave. Un sistema ben configurato dovrebbe consentire agli utenti di accedere solo a ciò a cui devono necessariamente accedere.

Sviluppate una configurazione standard e un processo di protezione avanzata ripetibile in modo che sia facile e veloce implementare i sistemi e assicurarsi che siano correttamente bloccati. Gli ambienti di sviluppo, QA e produzione dovrebbero tutti essere configurati in modo identico mediante un processo automatizzato per ridurre al minimo il lavoro necessario per installare un nuovo ambiente sicuro. Eseguite scansioni ed effettuate controlli a intervalli regolari per individuare le configurazioni errate.

Scrivere codice sicuroÈ necessario tenere presenti gli aspetti di sicurezza quando si sviluppa un software partendo da zero e quando si scrivono componenti aggiuntivi per un software esistente. Individuare e porre rimedio ai problemi di sicurezza in una fase iniziale del ciclo di sviluppo è meno costoso che correggere il codice una volta che l'applicazione è in produzione.

Come gestire le vulnerabilità più comuni delle applicazioni web


Requisiti

Implemen-tazione

Progettazione

Test Codifica

È possibile evitare la maggior parte dei guasti e dei punti deboli implementando gli aspetti di sicurezza con attenzione e in modo omogeneo durante le fasi di definizione dei requisiti, architetturali e di progettazione delle applicazioni. Ad esempio, modellate le minacce con anticipo per identificare le pagine contenenti la maggior parte della logica e quindi con i tempi di caricamento più lunghi, in modo da garantire ulteriori difese contro gli attacchi DoS. Assicuratevi di formare le persone che distribuiscono le applicazioni web affinché integrino la sicurezza nel ciclo di vita di sviluppo del software e ettete in atto processi che guidino il loro lavoro.

Tra le protezioni più efficaci da integrare nel software, è necessario includere l'implementazione corretta delle seguenti tecniche:

• Convalida imput. La maggior parte delle vulnerabilità è causata dalla mancanza di convalida dell'input degli utenti e di sanificazione corretta dell'input. Mai fidarsi degli input degli utenti. Occorre invece includere la convalida dell'input nei campi dei moduli per mitigare la possibilità di sovraccarico del buffer, di introduzione di codice e di altri attacchi che possono danneggiare la logica delle applicazioni.

• Crittografia. È necessario crittografare i dati sia in motion che at rest, mediante i più recenti standard di crittografia del settore.

Ciclo di vita dello sviluppo di un software sicuro

Fonte: http://resources.infosecinstitute.com/intro-secure-software-development-life-cycle/

Per garantire che le applicazioni

siano sicure, è molto più efficace

integrare la sicurezza sin dalle

fasi iniziali. Occorre considerare

la sicurezza in ogni fase del ciclo

di vita di sviluppo del software,

come mostrato qui.


Analizzare il codice e i plug-inIndipendentemente dall'attenzione dedicata alla progettazione e allo sviluppo di un'applicazione, esisteranno sempre punti deboli nel codice. Spesso non sono immediatamente evidenti e molti si propagano man mano che gli sviluppatori incorporano frammenti di codice esistente in più applicazioni. L'analisi delle vulnerabilità offre la possibilità di individuare backdoor, codice dannoso e altre minacce eventualmente esistenti nel software acquistato e nelle applicazioni sviluppate internamente.

Sono disponibili due tipi di analisi delle vulnerabilità: test statici e test dinamici.

• Test statici: i test statici analizzano il codice sorgente dell'applicazione e indicano i punti in cui l'applicazione è vulnerabile all'input dannoso come nel caso di attacchi SQL injection. Questi test esaminano ogni riga di codice e individuano l'esatta posizione di ogni punto debole. Strumenti automatizzati

possono persino fornire consigli per la mitigazione, riducendo i tempi della ricerca. I risultati sono però molto teorici e tendono a contenere sia falsi negativi che falsi positivi. In altre parole, si ottiene un lungo elenco di vulnerabilità che probabilmente gli hacker non colpiranno, mentre strumenti potrebbero non rilevare alcune vulnerabilità.

• Test dinamici: i test dinamici identificano le vulnerabilità presenti nell'ambiente di runtime riproducendo il modo di lavorare di un hacker. Queste analisi attraversano i siti web, compilano moduli, inviano richieste e analizzano la struttura dell'applicazione. Iniziano quindi a bombardare l'applicazione con input dannoso cercando di individuare le vulnerabilità. Il vantaggio è che questo tipo di test rileva vulnerabilità reali e identifica quelle che potrebbe essere state non individuate con gli strumenti statici. Purtroppo però sono limitati. Le applicazioni sono molto complesse ed è difficile esaminarle per intero, per cui si ottiene una copertura minore rispetto ai test statici.

La soluzione migliore per trovare la maggior parte delle vulnerabilità, se non tutte, consiste nell'utilizzare una combinazione di entrambi i tipi di analisi. Alcuni fornitori offrono entrambe le analisi nella stessa soluzione.

Installare un WAFL'installazione di un WAF consente più tempo per correggere le vulnerabilità. Si può usare un WAF per applicare patch virtuali all'applicazione sviluppando una regola che blocchi la nuova vulnerabilità fino a quando non è possibile creare una correzione permanente.

Quando implementate un WAF, assicuratevi di testare, monitorare e aggiornare la configurazione predefinita con regole ottimizzate per lo specifico ambiente dell'applicazione. Ricordate che nessuno strumento di sicurezza prevede un'impostazione una tantum. Le best practice impongono di rivedere e aggiornare il set di regole almeno su base trimestrale o, ancora meglio, su base mensile.


Analizzare la precisione del WAFAssicuratevi di analizzare la precisione del WAF. È necessario valutare il WAF in termini di capacità di bloccare gli attacchi e consentire il transito del traffico buono determinando:

• Quanti attacchi reali sono stati bloccati (veri positivi)

• Quante richieste valide sono state fatte passare (veri negativi)

• Quanto traffico valido è stato impropriamente bloccato (falsi positivi)

• Quanti attacchi sono stati fatti passare (falsi negativi)

• Coefficiente di correlazione di Matthews (per informazioni sul coefficiente e su come applicarlo al WAF, consultate la pagina http://en.wikipedia.org/wiki/Matthews_correlation_coefficient)

Cercate o create una soluzione di test del WAF per valutare la precisione della vostra implementazione. Lo strumento dovrebbe inviare sia traffico valido che attacchi reali e consentire di aggiungere con facilità test case sia di traffico valido che di attacchi. Dovrebbe raccogliere dati statistici con precisione e fornire informazioni dettagliate su ciascun test, includendo richiesta, risposta, comportamento previsto e natura della richiesta. Dovrebbe inoltre fornire funzionalità di generazione di report.

http://en.wikipedia.org/wiki/Matthews_correlation_coefficient






Man mano che si continuano a trasferire dati e servizi in Internet, non è più possibile fare affidamento sulla solida protezione perimetrale per mantenere al sicuro i propri sistemi e i propri dati. Si rendono invece necessarie soluzioni progettate specificamente per affrontare le minacce alla sicurezza poste da Internet, in particolare gli attacchi DoS/DDoS a livello di rete e di applicazione e i tentativi di furto di dati.

Questo eBook ha tracciato un quadro dettagliato dei tipi di minacce che affliggono le risorse Internet, degli elementi necessari di una soluzione e delle opzioni disponibili. Qualunque sia la soluzione scelta, è necessario adottare un approccio multilivello che fornisca larghezza di banda sufficiente a livello di rete e che consenta il transito del solo traffico HTTP sulla rete. A livello di applicazione, occorre seguire processi di sviluppo sicuro e una valida igiene Internet, nonché implementare una soluzione WAF completa per gestire gli attacchi che potrebbero infiltrarsi tra le crepe. Mettendo in atto una serie completa di controlli d sicurezza, le organizzazioni possono ridurre al minimo i rischi associati al mantenimento della propria presenza in rete.

Per le informazioni più aggiornate sul panorama delle minacce DDoS, scaricate l'ultimo rapporto trimestrale sugli attacchi qui Per ulteriori informazioni sul panorama della sicurezza generale e di Internet. scaricate il rapporto di Akamai sullo Stato di Internet

CONCLUSIONE

http://www.prolexic.com/knowledge-center-dos-and-ddos-attack-reports.html%20



Avviate subito il vostro piano per la sicurezza delle applicazioni web:

Seguite questi 5 passaggi per migliorare il vostro approccio alla sicurezza delle applicazioni web:

1. Valutate i rischi per la sicurezza che con maggiore probabilità possono avere effetti negativi sui vostri siti e sulle vostre applicazioni web

2. Eseguite un inventario dei controlli di sicurezza esistenti e determinate quelli necessari da aggiungere per mitigare i rischi

3. Determinate le vulnerabilità delle vostre applicazioni web e seguite le best practice di igiene Internet per gestirle

4. Ricercate le vostre opzioni

5. Implementate la vostra soluzione multilivello

Il panorama della cyber sicurezza è in costante evoluzione.

Akamai continuerà a restare al passo con i trend di mercato e

a raccogliere le opinioni dei più importanti esperti del settore.

Per commenti quotidiani sul settore della sicurezza, VISITATE IL NOSTRO BLOG } http://blogs.akamai.com.

Per parlare con un rappresentante CHIAMATE IL NUMERO: 1.877.425.2624 o

CONTATTATE IL NOSTRO TEAM DI VENDITA } oggi stesso all'indirizzo: http://www.akamai.com/html/forms/sales_form.html?utm_cam-paign=error-pages&utm_source=404&utm_content=email-us

http://blogs.akamai.com


http://www.akamai.com/html/forms/sales_form.html


http://www.akamai.com/html/forms/sales_form.html?utm_campaign=error-pages&utm_source=404&utm_content=email-us

http://www.akamai.com/html/forms/sales_form.html?utm_campaign=error-pages&utm_source=404&utm_content=email-us


RISORSE UTILI:12 esperti della sicurezza da conoscere: vi occorre aiuto per comprendere meglio gli ultimi trend nel campo della cyber sicurezza? Gli esperti riportati di seguito sono alcuni dei nomi più importanti del settore, ognuno con una forte presenza sui social media.

Seguiteli per fare il pieno di dati sulla sicurezza informatica con una dose aggiuntiva di brillanti discussioni.

ANDY ELLIS ....................................................................... Chief Security Officer di Akamai .............................................................................. Twitter: @CSOAndy

ANDREW JAQUITH ....................................................... CTO di SilverSky ............................................................................................................. Twitter: @arj

BILL BRENNER ................................................................. Guru della sicurezza di Akamai ................................................................................. Twitter: @BillBrenner70

BRIAN KREBS ................................................................... Giornalista investigativo .............................................................................................. Twitter: @BrianKrebs

CHRIS HOFF ........................................................................ VP Strategy and Planning, Juniper Networks ....................................................... Twitter: @Beaker

JACK DANIEL ..................................................................... Technical Project Manager, Tenable ......................................................................... Twitter: @jack_daniel

JOSHUA CORMAN ....................................................... CTO presso Sonatype ................................................................................................... Twitter: @JoshCorman

MARTIN MCKEAY ......................................................... Guru della sicurezza di Akamai ................................................................................. Twitter: @Mckeay

MICHAEL SMITH ............................................................ CSIRT Director di Akamai ............................................................................................ Twitter: @rybolov

MIKE ROTHMAN ........................................................... President, Securosis ....................................................................................................... Twitter: @securityincite

RICH MOGULL .................................................................. CEO, Securosis ................................................................................................................ Twitter: @RMogull

STEPHANIE BALAOURAS .......................................... VP e Research Director, Forrester Research ........................................................... Twitter: @sbalaouras

APPENDICE 1


LETTURE CONSIGLIATE: Rapporto globale sugli attacchi DDoS Tenetevi aggiornati sui trend nel campo della cyber sicurezza

Case study dei clienti Leggete come altre aziende proteggono i propri siti web dagli attacchi DDoS

Notifiche di minacce del team PLXsert Scoprite ulteriori informazioni sulle minacce DDoS attuali e le misure da adottare per proteggervi

Man, Machine & DDoS Mitigation (Uomo, macchina e mitigazione DDoS) Scoprite perché sono necessarie competenze umane nel campo della cyber sicurezza nell'attuale panorama degli attacchi DDoS

Ovum: Delivering Effective DDoS Protection (Ovum: come offrire una mitigazione DDoS efficace) Leggete questo rapporto degli analisti sui motivi per cui la protezione dagli attacchi DDoS deve essere parte del vostro piano di risposta agli incidenti di sicurezza

APPENDICE 2

http://www.prolexic.com/knowledge-center-dos-and-ddos-attack-reports.html

http://www.akamai.com/html/ms/security.html

http://www.akamai.com/html/ms/security.html


http://www.prolexic.com/knowledge-center-white-paper-man-machine-and-ddos-mitigation.html

http://www.prolexic.com/knowledge-center-white-paper-man-machine-and-ddos-mitigation.html

http://www.prolexic.com/knowledge-center-analyst-report-ovum-delivering-effective-ddos-protection.html

http://www.prolexic.com/knowledge-center-analyst-report-ovum-delivering-effective-ddos-protection.html

MINACCE E MITIGAZIONI UNA GUIDA ALLA SICUREZZA WEB ... · 2013 COST OF CYBER CRIME STUDY: United...

Documents

Transcript of MINACCE E MITIGAZIONI UNA GUIDA ALLA SICUREZZA WEB ... · 2013 COST OF CYBER CRIME STUDY: United...