Penetration test: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
m smistamento lavoro sporco e fix vari |
Revisione fino a Vulnerabilità |
||
Riga 1:
In [[informatica]], il '''''penetration test''''' (o informalmente '''pen test''') è il processo operativo di analisi o valutazione della [[sicurezza informatica|sicurezza]] di un [[sistema informatico]] o di una [[rete di computer|rete]].
Condotta su più fasi dal punto di vista di un potenziale attaccante simulando l'[[attacco informatico]] di un utente malintenzionato, consiste nello sfruttamento delle vulnerabilità rilevate aiutando a determinare se le difese del sistema sono sufficienti o se invece sono presenti altre vulnerabilità, elencando in questo caso quali difese il test ha sconfitto. Il test ha dunque come obiettivo quello di evidenziare le debolezze della [[piattaforma (informatica)|piattaforma]] fornendo il maggior numero di informazioni sulle [[vulnerabilità informatica|vulnerabilità]] che ne hanno permesso l'accesso non autorizzato<ref>{{Cita libro|titolo=The CISSP® and CAPCM Prep Guide: Platinum Edition|editore=John Wiley & Sons|isbn=978-0-470-00792-1|citazione=A penetration test can determine how a system reacts to an attack, whether or not a system's defenses can be breached, and what information can be acquired from the system|lingua=en}}</ref><ref>{{Cita libro|isbn=978-1-84928-371-7|autore=Kevin M. Henry|titolo=Penetration Testing: Protecting Networks and Systems|citazione=Penetration testing is the simulation of an attack on a system, network, piece of equipment or other facility, with the objective of proving how vulnerable that system or "target" would be to a real attack.|editore=IT Governance Ltd|lingua=en}}</ref>, fornendo una stima chiara sulle capacità di difesa e del livello di penetrazione raggiunto nei confronti:
* delle vulnerabilità interne al sistema;
* delle vulnerabilità esterne al sistema;
* della sicurezza fisica.
Tutti i problemi di sicurezza rilevati vengono quindi presentati al cliente assieme
== Storia ==
Riga 15:
La minaccia della computer penetration fu sottolineata in un importante rapporto organizzato dal [[Dipartimento della Difesa degli Stati Uniti d'America|Dipartimento della Difesa statunitense]] (DoD) alla fine del 1967. In sostanza, i funzionari del Dipartimento della Difesa si rivolsero a Willis Ware per condurre una task force di esperti proveniente da NSA, [[Central Intelligence Agency|CIA]], DoD, mondo accademico e industria per valutare formalmente la sicurezza dei sistemi informatici time-sharing. Facendo affidamento su molti documenti presentati nel corso dello Spring 1967 Joint Computer Conference, la task force confermò largamente che la computer penetration era una minaccia alla sicurezza del sistema informatico. Il rapporto di Ware è stato inizialmente classificato, ma molti dei maggiori esperti informatici del paese identificarono lo studio come documento definitivo sulla sicurezza informatica.<ref name="Hunt 8"/> Jeffrey R. Yost del [[Charles Babbage Institute]] ha più recentemente descritto il rapporto di Ware come "... di gran lunga lo studio più importante e approfondito su questioni tecniche e operative in materia di sicurezza dei sistemi informatici del suo tempo".<ref>Yost (2007), p. 602</ref> In effetti, il rapporto Ware ha ribadito la grave minaccia rappresentata dalla computer penetration per i nuovi sistemi time-sharing online.
Per capire meglio le debolezze del sistema, il governo federale e dei suoi finanziatori ben presto cominciarono
Donald MacKenzie, uno studioso della storia della sicurezza informatica, sottolinea che "RAND aveva fatto alcuni studi di penetrazione (esperimenti
Le azioni dei primi tiger team e gli sforzi della RAND Corporation hanno dimostrato l'utilità dei penetration test come strumento per la valutazione della sicurezza del sistema. A quel tempo, un analista RAND notò che i test avevano "... dimostrato la praticità della system-penetration come strumento per valutare l'efficacia e l'adeguatezza delle difese per la sicurezza dei dati." Inoltre, un certo numero di analisti RAND affermarono che gli esercizi di penetration test offrivano diversi vantaggi che erano sufficienti per giustificarne l’uso.<ref name="Hunt 9">Hunt (2012), p. 9</ref>
Forse il principale esperto di computer penetration durante questi primi anni è stato James P. Anderson, che ha lavorato per NSA, RAND
# Trovare una vulnerabilità sfruttabile
# Progettare un attacco intorno
# Testare l'attacco
# Impadronirsi di una linea in uso
Riga 32:
Nel corso del tempo, la sequenza di Anderson ha contribuito a guidare molti altri esperti di sicurezza, che si sono basati su questa tecnica per valutare la sicurezza dei sistemi time-sharing.<ref name="Hunt 9"/>
Negli anni successivi, la computer penetration come strumento per la valutazione della sicurezza è
Mentre questi studi suggerivano che la sicurezza informatica negli Stati Uniti era un problema importante, lo studioso Edward Hunt ha di recente fatto una riflessione più ampia sullo studio della computer-penetration come strumento di sicurezza. Hunt, in un recente documento sulla storia del penetration test, suggerisce che le istituzioni per la difesa degli Stati Uniti “... hanno creato molti degli strumenti utilizzati nella moderna guerra cibernetica”.<ref>Hunt (2012), p. 5</ref>
Riga 43:
Nei test ''[[White Box]]'' sono invece fornite conoscenze dettagliate dell'infrastruttura da esaminare, spesso comprensive di schemi di rete, codice sorgente delle applicazioni e liste di indirizzi IP presenti nella rete. Esistono anche varianti a queste metodologie definibili ''[[Grey Box]]''.<ref name="SANS Institute">{{Cita web|url=http://www.sans.org/reading-room/whitepapers/bestprac/writing-penetration-testing-report-33343|titolo=Writing a Penetration Testing Report|accesso=10 dicembre 2016|data=6 aprile 2010|editore=[[SANS]]|formato=pdf|lingua=en}}</ref> I risultati dei penetration test possono valutare gli impatti di un attacco e suggerire contromisure per ridurre i rischi.<ref name="SANS Institute"/>
I processi di analisi che vengono condotti in un penetration test hanno diversi tempi di azione in cui sono alternate fasi manuali e fasi automatiche. Vengono acquisite inizialmente le informazioni principali sull'[[Architettura (computer)|architettura]] della piattaforma e sui servizi offerti. Dall'analisi di questi dati deriva la scelta di come condurre il passo successivo, consistente in
L'attività si conclude nello sviluppo della reportistica composta dal report di analisi sommaria dedicato al [[management]] o ''executive summary'', contenente l'analisi dell'impatto di rischio di quanto riscontrato e tempistiche per l'azione di rientro o mitigazione delle problematiche riscontrate, e dal report tecnico, contenente l'analisi dettagliata dei problemi e la soluzione tecnica. Il penetration test va effettuato su sistemi esposti su [[Internet]] e comunque sulle piattaforme sensibili collegate a grosse reti, prima di entrare in esercizio, per avere una prova pratica della sicurezza di ciò che si espone.
È importante capire che la probabilità che un pen-tester riesca a trovare tutti i problemi di sicurezza è molto bassa. Ad esempio: ieri è stato fatto un penetration test che ha messo in evidenza l'assenza di vulnerabilità nel sistema; oggi Microsoft rilascia una patch atta a correggere alcuni errori di sistema contenente una nuova vulnerabilità di alcuni server di posta che in precedenza erano considerati sicuri; questo significa che il pen-test di ieri non è più valido visto che naturalmente non può mettere in luce la nuova vulnerabilità. Lo stesso esempio può essere applicato
== Strumenti ==
Riga 84:
== Strumenti di test automatizzati ==
Il processo di penetration test può essere semplificato in due parti:
#
# Descrizione dell'operazione non valida
Riga 92:
Il [[fuzzing]] è una tecnica molto diffusa per scoprire le vulnerabilità di un sistema. Ha lo scopo di ottenere un errore non gestito attraverso un input casuale. Il tester utilizza input casuali per accedere a porzioni di codice poco utilizzate visto che quelle più frequenti sono solitamente esenti da errori. Gli errori sono utili perché o espongono ulteriori informazioni, come ad esempio crash del [[Server web|server HTTP]], o sono direttamente utilizzabili, ad esempio il [[buffer overflow]].
Immaginate un sito che dispone di 100 caselle di testo. Alcune saranno vulnerabili a [[SQL injection]] attraverso l'uso di determinate stringhe. L'invio continuo di stringhe casuali arriverà prima o poi a trovare un buco nella sicurezza. L'errore risulta evidente presentandosi come una pagina HTML non corretta a causa di un errore SQL. In questo caso, solo le caselle di testo sono utilizzate come [[input]]. Tuttavia, i sistemi software hanno solitamente molti tipi di input, come i [[cookie]], il flusso di un file in upload o canali RPC. Gli errori possono presentarsi in tutti questi tipi di input. L'obiettivo è quello di ottenere prima un errore non gestito
=== Payload ===
| |||