• Guide, Sicurezza
• 6 Giugno 2017

Quello nel quale stiamo per addentrarci oggi e nei prossimi capitoli, è un’attività che può essere compiuta per scopi leciti o illeciti. Il Penetration Testing o PenTest può essere definito come il processo che permette di analizzare in profondità la sicurezza di uno o più sistemi. L’attività deve essere una parte importante dei processi aziendali in modo da assicurare la piena consapevolezza dei punti deboli dell’infrastruttura IT e non.

Per ogni PenTest può essere applicata una diversa metodologia; si intende un insieme di regole da poter seguire per condurre un PenTest in maniera corretta.

Tale pratica può essere condotta indipendentemente o come attività schedulata nel proprio ufficio di IT Security. Uno scheduling comporta l’implementazione di adeguate misure di sicurezza, redigere un documento di analisi dei rischi, revisione del Codice, creazione di modelli di minacce ed altro…

Esistono due approcci metodologici al PenTest:

• Black Box
  
• White Box
  

Parliamo di “Scatola Oscura” o Black Box quando colui o coloro che compiono l’attività di Penetration non hanno cognizione delle tecnologie implementate nell’organizzazione target. Devono essere adottate tutte le tecniche di hacking conosciute ed è importante saper classificare le vulnerabilità in base al loro livello di rischio. (es. Un sistema vulnerabile ad un Local Code Execution può essere considerato meno grave rispetto ad un Remote code execution)

Tale metodologia può essere più costosa in termini di tempo e risorse rispetto ad un approccio di tipo White Box ed è soggetto alle reali abilità dell’attaccante.

La metodologia White Box, al contrario, è una tipologia di PenTest dove l’attaccante è a conoscenza di tutto l’ambiente che andrà a testare. È il miglior modo per valutare e concentrarsi su tutte quelle tecnologie che possono risultare critiche. In questo caso si va a valutare i rischi esterni che l’azienda/organizzazione incorre, non valutando le vulnerabilità interne (es. Social Enginering / Dipendente Scontento).

Gli step sono simili alle fasi di Black Box, ma in qualche modo l’approccio White Box può essere integrato nei cicli di vita di implementazioni Hardware/Software per eliminare le possibili problematiche a monte di un possibile attacco.

Sentiamo spesso parlare di Vulnerability Assessment e Penetration testing. Ma qual è la differenza sostanziale?

La differenza basilare è che nel Vuln. Assessment si vanno ad evidenziare tutte le possibili vulnerabilità, andandole a valutare il possibile impatto, nel PenTest si procede ad identificare tutte le vulnerabilità ed sfruttare possibili exploit pubblici o custom (0-day) con l’aggiunta di privilege escalation e mantenimento dell’accesso ai sistemi target.

In questo viaggio impervio non siamo soli…

Esistono varie linee guida che possono essere d’aiuto per chi voglia incominciare ad implementare controlli periodici:

• Open Source Security Testing Methodology Manual (http://www.isecom.org/research/)
  
• Information Systems Security Assessment Framework (https://ht.transparencytoolkit.org/FileServer/FileServer/whitepapers/issaf/issaf0.2.1A.pdf)
  
• Open Web Application Security Project Testing Guide (https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents)
  
• Web Application Security Consortium Threat Classification (http://www.webappsec.org/)
  
• Penetration Testing Execution Standard (http://www.pentest-standard.org/index.php/Main_Page)

Altre metodologie e tecniche di PenTest possono essere “Blind”, “Double Blind”, “Gray Box”, “Double gray box”, “Tandem”, “Reversal”.

Compreso la base dell’argomento, vediamo come deve essere pianificata l’attività nel modo migliore.

Esistono tantissimi tools che possono essere adoperati per tale proposito ma è importante usarli con criterio e sapienza in modo da poter massimizzare il risultato con uno sforzo minore.

Le fasi del PenTest, che possono essere semplici o complessi in base all’ambiente target, sono:

• Definizione del Target
  
• Raccolta delle Informazioni
  
• Identificare e Scoprire il Target
  
• Enumerazione Target
  
• Mapping delle Vulnerabilità
  
• Ingegneria Sociale
  
• Sfruttamento delle falle
  
• Escalation dei privilegi
  
• Mantenimento dell’accesso
  
• Documentazione and Reporting

In base all’approccio white/black box, sarà sempre possibile modificare l’ordine delle fasi che potrà essere adattato in base alla tipologia di target da valutare.

Nei prossimi articoli affronteremo tutti i capitoli con vari esempi e casi reali. Partiamo dalla definizione del Target e Test Plan

Definizione del Target / Test Plan

Il primo capitolo che deve essere affrontato obbligatoriamente, parte da una unica semplice domanda: Cosa vogliamo testare? Perché?

Non aver ben chiaro la risposta alla domanda, porterà con sé uno spreco eccessivo di risorse.

In primis, è necessario creare un documento che elenchi le linee guida e le informazioni che dovranno essere estratte o trovate nei sistemi target. (es. informazioni dell’infrastruttura). Si procederà poi ad un Test Plan prevedendo l’allocazione delle risorse necessarie, analisi dei costi, NDA, regole di ingaggio ecc…

N.B: Il Plan potrà comprendere anche eventuali limitazioni o restrizioni nel condurre il PenTest.

Dovranno essere definiti anche i vantaggi fondamentali che il cliente ricevere in favore del raggiungimento degli obiettivi aziendali tramite PenTest. È una sezione che sarà utile a valutare il risultato ottenuto in termini qualitativi.

Si parte, da alcuni punti:

• Raccolta di informazioni base come nome dell’azienda, indirizzo, sito web, contatti, numeri di telefono etc…
• Si definisce il vero obiettivo del PenTest;
• Si stabilisce la tipologia di PenTest (black/ white / Ingegneria sociale inclusa/esclusa…)
• Quanti target devono essere testati;
• Quali sistemi operativi utilizza la vostra infrastruttura (info dipendente dall’approccio scelto)
• Device di rete da testare? (IDS/IPS/ load balancer…)
• Disaster recovery plan definito?
• Standard che l’azienda deve rispettare?
• Contatti del capo progetto;
• Tempo di esecuzione dei test;
• Budjet;
• Ulteriori info/richieste.

È importante comprendere anche come dovrà essere redatto il report finale:

• Report per l’esecutivo;
• Report tecnico;
• Report per sviluppatori.

In che modo dovrà essere consegnato:

• Email;
• Email cifrata;
• Stampato;
• Consegna a mano…

Una volta raccolti tutti i requisiti di base del Test Plan, in ultima analisi occorre assegnare le adeguate risorse e calendarizzare tutte le attività; tramite alcuni strumenti è possibile gestire i progetti in corso e poterne mantenere facilmente traccia.

Nel prossimo articolo, si introdurrà il concetto ed esempi pratici di Information Gathering.