La situazione di partenza

All’interno del gruppo VEM, relativamente alla gestione del processo di sicurezza, sono presenti pi`u team, ognuno dei quali si occupa di un aspetto specifico. In particolare, la parte di implementazione delle configurazioni sui firewall e la loro manutenzione `e gestita dal NOC (Network Operation Cen- ter); quella di monitoraggio, rilevamento delle minacce e Incident Response `e gestita dall’IRT (Incident Response Team) di Certego.

Al fine della gestione del processo sono necessarie continue interazioni tra i due team: nel momento in cui l’IRT individua un attacco in corso basato sulla rete, come ad esempio un malware penetrato all’interno della rete che contatta un server sotto il controllo dell’attaccante, `e importante bloccarlo tempestivamente. Tuttavia, l’IRT non gestisce direttamente i firewall, per cui deve contattare il NOC, affinch´e quest’ultimo si incarichi di inserire una regola di blocco sul firewall interessato. In questa operazione sono coinvolti due utenti umani, che devono interagire compatibilmente con le priorit`a e gli impegni pianificati.

Si potrebbe incaricare l’IRT dell’inserimento delle nuove regole senza passare dal NOC ma questa strada non `e percorribile, sia per ragioni amministrative (si cerca di limitare il numero di persone responsabili della gestione di un determinato apparato), sia per un problema di competenze (i membri del- l’IRT non conoscono i dettagli delle configurazioni firewall dei clienti e le loro specificit`a). Inoltre, a complicare ulteriormente lo scenario, vi `e il fatto che il panorama delle soluzioni installate presso i clienti `e sempre pi`u eterogeneo e integrato, imponendo una crescente specializzazione.

Di conseguenza, tra il rilevamento di un attacco in corso e la sua effettiva neutralizzazione pu`o trascorrere parecchio tempo, specialmente in frangenti di carico di lavoro elevato per il NOC e/o al di fuori del normale orario di lavoro. La tempestivit`a `e invece di primaria importanza quando si tratta di Incident Response, in quanto all’aumentare del tempo durante il quale un attaccante ha accesso ad un sistema aumentano anche i danni potenziali che pu`o compiere; un attacco bloccato sul nascere avr`a maggiori probabilit`a di

essere inconcludente o di ridotto impatto.

2.3.2

Il software da sviluppare

Dati i requisiti e la situazione di partenza descritti, si intende sviluppa- re un’API (nome in codice kAPI-royal) che consenta all’IRT di applicare regole di blocco sui firewall dei clienti utilizzando un’interfaccia semplificata e uniforme, indipendente dai vendor, che a sua volta sfrutti le potenzialit`a delle API REST implementate dai vendor sui loro prodotti. In questo modo si eliminer`a non solo la necessit`a di conoscere le specificit`a degli svariati pro- dotti di ogni vendor, ma anche quella di conoscere nel dettaglio la topologia delle reti dei clienti.

Le regole di blocco saranno basate alternativamente su indirizzo IP (ad esem- pio 192.168.1.120), di sottorete (ad esempio 192.168.2.0/24) o FQDN (Fully Qualified Domain Name, ad esempio test.org) del dominio che si intende bloccare.

In figura 2.2 `e presente il diagramma UML dei casi d’uso che esemplifica le principali operazioni a cui si vuole abilitare gli analisti dell’IRT. Conte- stualmente viene visualizzato il ruolo del NOC, che si occuper`a della prima installazione e della manutenzione ordinaria, senza necessit`a di intervenire manualmente ogni volta che l’IRT desidera agire sulle regole di blocco.

2.3.3

I dispositivi da supportare

Nell’ambito di questa tesi, ci si focalizzer`a sul supporto dei dispositivi utilizzati attualmente dai vari clienti, tralasciando gli altri. La struttura mo- dulare del progetto dovr`a comunque consentire l’estensibilit`a, aggiungendo in futuro il supporto a nuovi prodotti e vendor.

In generale, saranno gestiti dispositivi classificabili in due categorie: i next- generation firewall (descritti nella sezione 1.1.1) ed i sistemi per il controllo degli accessi. Verranno ora analizzati i prodotti specifici che saranno presi in esame.

2.3 Analisi del problema 37

Figura 2.2: Diagramma dei casi d’uso Cisco ASA

Cisco Adaptive Security Appliance (ASA) [34] `e la prima soluzione next- generation firewall proposta dall’azienda californiana. Si tratta di un prodot- to solido, anche se la curva di apprendimento per utilizzarlo completamente `e piuttosto ripida, in quanto manca un’interfaccia grafica web, rendendo neces- sario destreggiarsi con la linea di comando. `E presente un plugin aggiuntivo per implementare le API REST, che consentono la gestione delle funzioni principali, come alternativa alla linea di comando.

Cisco Firepower

Cisco Firepower [35] `e il nuovo sistema operativo eseguibile su hardware ASA. Introduce una nuova interfaccia grafica e la possibilit`a di centralizzare la gestione di un’infrastruttura basata su di esso tramite Firepower Mana- gement Center (FMC). I firewall controllati sono chiamati Firepower Threat Defense (FTD). Si tratta di un prodotto ancora non completamente maturo,

in quanto alcune funzionalit`a, come le API REST, sono implementate solo in parte e le prestazioni non sono ancora ottimali.

Fortinet FortiManager

FortiGate [36] `e la soluzione next-generation firewall di Fortinet. Pu`o essere utilizzato come dispositivo a s´e stante o, nel caso di infrastrutture firewall distribuite, in maniera centralizzata tramite FortiManager [37]. Nel caso di studio preso in esame ci si limiter`a a quest’ultimo caso d’uso. Sono presenti API REST piuttosto complete nelle funzionalit`a offerte, anche se non del tutto rispettose degli standard de facto nella progettazione di servizi web RESTful.

Check Point R80

Anche Check Point offre un next-generation firewall di sua produzione, al momento giunto alla versione R80. [38] Basato su Red Hat Enterprise Linux, `e anch’esso pensato per infrastrutture firewall distribuite. Le API REST sono piuttosto complete e ben documentate.

Cisco ISE

A differenza dei prodotti descritti finora, Cisco Identity Services Engine (ISE) [39] non `e un next-generation firewall, bens`ı uno strumento scalabile e adattabile di controllo degli accessi per reti di dimensioni medio-grandi e grandi basato sul contesto (i privilegi sono assegnabili agli host dinami- camente in base al ruolo, alla locazione e alla configurazione software). A differenza di quanto progettato per i firewall, qui non si bloccher`a il traffico in transito, ma si operer`a per mettere in quarantena i client infetti della rete, in modo da contenere la diffusione dei malware ed evitare che questi inviino dati ai loro creatori.

2.3 Analisi del problema 39

2.3.4

Stato dell’arte

Dato il problema presentato, `e opportuno esplorare il mercato alla ricerca di eventuali soluzioni a questo problema: se gi`a ne esistesse una adeguata, non sarebbe necessario progettare una soluzione ad hoc.

In primo luogo, si nota come il problema sia piuttosto specifico e legato al contesto applicativo dell’azienda: questa difficolt`a di comunicazione si verifi- ca solo nei casi in cui esistano pi`u team che si occupano di aspetti diversi dello stesso cliente. Per questo motivo, eseguendo ricerche estese sia a soluzioni proprietarie, sia a soluzioni open source, non `e stato possibile individuare un prodotto completo in grado di adempiere alle funzionalit`a richieste.

Si `e quindi reso necessario estendere il raggio della ricerca, mirando ad in- dividuare non pi`u soluzioni complete, ma, pi`u in generale, prodotti parziali che interagiscono con le API REST dei vendor, senza essere necessariamente pensati per il contesto applicativo preso in esame, ai quali potersi ispirare. Fortunatamente, sono stati individuati alcuni progetti open source relativa- mente a Cisco Firepower, Fortinet FortiManager, Check Point R80 e Cisco ISE. [40, 41, 42, 43, 44, 45] Si potr`a attingere a tali fonti per valutare alcuni esempi di utilizzo delle API.

2.3.5

Test plan

Considerato l’ambito applicativo, `e necessario che il software sia ben te- stato, in modo da prevenire malfunzionamenti inattesi durante l’utilizzo in produzione che potrebbero causare danni ai clienti: poich´e si interagir`a di- rettamente con le policy dei firewall, nel caso peggiore si potrebbe mandare offline tutta la rete. Si rende, quindi, necessaria la definizione di un processo di controllo della qualit`a volto a mitigare questo rischio.

Sar`a opportuno definire unit tests che andranno a verificare la correttezza del comportamento delle singole componenti del sistema e integration tests che esamineranno le interazioni dei componenti tra loro. Tali test saranno eseguiti in maniera automatica prima del rilascio di ogni nuova versione del

software, in modo da intercettare eventuali bug.

Per quanto riguarda gli ambienti di test (schematizzati in figura 2.3), si uti- lizzer`a nelle prime fasi un ambiente dedicato e virtuale, separato dai sistemi in produzione e simile ad essi, in modo da non causare danni in caso di problemi. Quando il comportamento del software in questo ambiente sar`a considerato corretto, si passer`a ai test in produzione presso alcuni clienti se- lezionati. Questo passaggio `e necessario poich´e nell’ambiente virtuale non `e possibile riprodurre efficacemente la complessit`a dei sistemi di tutti i clienti, che in alcuni casi arrivano a contemplare migliaia di regole sui firewall. Infi- ne, se anche questo test avr`a successo, si rilascer`a il prodotto presso tutti i clienti.

Capitolo 3

Progettazione e

implementazione

A fronte del problema descritto nel capitolo precedente, saranno ora esaminate le fasi di progettazione e implementazione del sistema software descritto (kAPI-royal), motivando le scelte intraprese.

3.1

Progettazione

In questa sezione saranno analizzate le scelte progettuali effettuate, te- nendo conto delle specificit`a dei prodotti dei vari vendor.

3.1.1

Paradigmi di sviluppo

Il software da realizzare deve fornire un’interfaccia che medi l’accesso ai dispositivi controllati. Considerata l’affidabilit`a richiesta nelle comunicazioni e la necessit`a di ottenere i risultati di un’elaborazione prima di proseguire con le attivit`a successive, si `e scelto di utilizzare uno stile di comunicazio- ne sincrono. Sar`a fondamentale l’integrazione con il software preesistente, mantenendo uno stile modulare: `e consigliabile adottare lo stesso paradig- ma del software principale, ovvero quello object-oriented. Questo implica lo svolgimento di un’attivit`a di mediazione con lo stile architetturale REST

utilizzato dalle API dei firewall. Ad ogni modo, internamente pu`o essere uti- lizzato qualsiasi paradigma si ritenga opportuno, purch´e l’interfaccia esposta sia di tipo object-oriented.

In particolare, dove possibile, si `e valutato di utilizzare il paradigma fun- zionale, poich´e le funzioni definite in questo modo sono prive di side-effect, rendendo pi`u semplice verificare la presenza di bug e migliorando l’efficienza.