Storie spaventose da raccontare in rete

Con Halloween alle porte, ecco una storia dell'orrore realmente accaduta sulle policy dei firewall. (Per rendere l'effetto, la immagini pure narrata con una voce roca e inquietante… oppure da Morgan Freeman, se preferisce.)

Come Sales Engineer, trascorro molte giornate a fare demo dei nostri prodotti, parlando con Security Engineer, responsabili della compliance, DevOps Manager e CISO di firewall e sicurezza di rete. A volte le storie di chi lavora in prima linea sono incredibili e a volte decisamente spaventose. Ecco un racconto recente di un cliente che toglierà il sonno a qualunque firewall engineer.

Scenario:
L'azienda aveva adottato da poco una filosofia “zero trust” e aveva investito molto tempo per avvicinarsi a quell'obiettivo. Nell'ultimo anno si era concentrata sulla pulizia delle policy dei firewall, scrivendo regole specifiche per l'esigenza di business – niente di più – solo gli IP e le reti che necessitavano dell'accesso. Stavano facendo progressi quando uno dei loro engineer ha fatto una scoperta agghiacciante: una temuta regola “Any – Any – Any – Accept” sepolta al centro della policy.

Si sono affannati a capire perché quella regola esistesse. Alla fine hanno scoperto che era stata creata da un network engineer junior, che voleva semplicemente far funzionare qualcosa. Quella singola regola vanificava tutti i progressi compiuti verso l'obiettivo zero trust ed esponeva la rete a un rischio enorme.

Era evidente che la regola andasse rimossa. Ma era presente nella policy – non rilevata – da almeno 6 mesi e consentiva sicuramente traffico business critical. Anzi, i log indicavano che si trattava di una regola estremamente utilizzata. Naturalmente, con ogni probabilità non consentiva solo traffico business critical, ma anche traffico malevolo. Occorreva rimediare rapidamente al problema.

Innanzitutto hanno organizzato riunioni con i team di rete e hanno cercato di indovinare quale potesse essere parte del traffico, individuando applicazioni critiche e flussi che chi conosceva la rete riteneva potessero utilizzare quella regola. Ma alla fine hanno deciso di stringere i denti, rimuovere la regola e vedere chi avrebbe protestato.

Hanno quindi informato dell'errore i manager di tutte le business unit. Con imbarazzo, hanno comunicato che sarebbe stata attivata una “hotline” con operatori a disposizione e che, in definitiva, sarebbe stato necessario far testare alle persone tutte le funzioni business critical per assicurarsi che i loro prodotti, le loro applicazioni e qualunque risorsa necessaria per svolgere il proprio lavoro e per consentire a clienti/partner/fornitori di fare affari con loro restassero indisponibili solo il tempo necessario a ripristinare tutto. Sì, qualcosa è andato giù, e sì, erano pronti a creare nuove regole per risolvere i problemi, ma è stato un incubo.

—

Forse lei non vive uno scenario da incubo come quello descritto sopra, ma FireMon può comunque semplificarle il lavoro aiutandola a ripulire le policy dei firewall. Ecco alcuni modi in cui FireMon avrebbe potuto evitare lo scenario descritto. E, se dovesse mai scoprire nella sua policy una regola eccessivamente permissiva, consulti il punto 6 qui sotto per una soluzione indolore al problema.

1) Avvisi e reportistica di compliance:
Avremmo notificato immediatamente il team in caso di attivazione di una regola eccessivamente permissiva come questa. In pratica può “regolare il livello” di permissività desiderato, ad esempio “Regole che consentono l'accesso a più di 60.000 destinazioni” oppure “Regole con sorgenti più ampie di una rete /16”.

2) Avvisi di modifica:
Questa regola sarebbe comparsa nella nostra vista normalizzata – indipendentemente dal vendor del firewall – e si sarebbe visto chiaramente che era stata aggiunta. Non sarebbe quindi stato possibile “infilarla di nascosto”. Alcuni engineer e manager ricevono automaticamente via email i report sulle modifiche alle policy ogni volta che viene effettuata una modifica, oppure anche solo un'istantanea a 30 giorni di tutto ciò che è cambiato.

3) Con il nostro strumento di automazione, FireMon Policy Planner, la regola rischiosa sarebbe stata bloccata sul nascere, prima ancora di essere applicata. Grazie alla nostra “analisi pre-modifica”, la regola sarebbe stata individuata e segnalata prima di essere portata in produzione e prima di lasciar passare anche un solo pacchetto di traffico. Ecco perché i responsabili della compliance apprezzano il fatto che non ci limitiamo a raccomandare la creazione di regole in base all'esigenza, ma, come in un ambiente sandbox, eseguiamo i nostri algoritmi di compliance prima di poter applicare automaticamente le regole. Alcuni clienti adottano Policy Planner SOLO per questa funzionalità e vi accedono tramite le nostre API.

4) Sempre con gli avvisi di modifica, il team saprebbe con certezza chi ha effettuato quali modifiche e quando. In questo caso, trattandosi di un engineer junior, un manager o un responsabile avrebbe potuto filtrare/ordinare rapidamente le modifiche effettuate da quell'utente nell'ultima settimana, o quantomeno nell'ultimo mese, per vedere che tipo di modifiche avesse apportato. È un'analisi che avrebbe potuto svolgere anche il team compliance, o persino l'utente stesso.

5) Dal punto di vista della documentazione, FireMon può essere l'unica fonte attendibile per informazioni come “chi ha richiesto questa regola, chi è il proprietario dell'applicazione, quando è stata rivista l'ultima volta, ecc.”. Filtrando e ordinando le regole in base alla documentazione associata, anche in questo caso il problema sarebbe stato individuato più rapidamente.

6) Ho tenuto il meglio per ultimo. Se ha una regola eccessivamente permissiva – ad esempio perché i suoi predecessori seguivano una politica di creazione delle regole diversa, più “aperta/flessibile” della sua – disponiamo di un modo semplice per ripulire queste regole. Con la Traffic Flow Analysis il nostro strumento esamina ogni singolo indirizzo IP che attraversa la regola, scomponendo un any/any/any in flussi specifici. Può esportare questi flussi e creare regole specifiche basate su di essi.