Una storia pratica del firewall – Parte 2: il valore della gestione

Jody Brazil CEO di FireMon Check Point e i firewall stateful inspection hanno vinto la prima battaglia contro i firewall proxy (Parte 1: gli inizi). È facile sostenere che tutto si riducesse alla tecnologia di ispezione, ma questo trascura un'innovazione chiave della soluzione Check Point: la gestione delle policy. L'affermazione dei firewall stateful inspection sulla concorrenza dei proxy a metà degli anni '90 è dovuta, in misura significativa, alla facilità di gestione. Gran parte di questo articolo è dedicata a Check Point. Ciò dipende principalmente dal ruolo dominante che Check Point ha avuto nel mercato dei firewall tra la fine degli anni '90 e i primi anni 2000. Tuttavia, dipende probabilmente anche dalla mia esperienza con Check Point in quegli anni. Accolgo volentieri il Suo punto di vista e attendo i Suoi commenti. La metà degli anni '90 è stata un'epoca di rapida evoluzione delle reti. Ad esempio, ethernet era un'opzione, ma non sempre il protocollo di rete locale in uso (ricorda il token ring?). La connessione a Internet non era data per scontata, era oggetto di discussione. La connessione dial-up era ancora diffusa e AOL era l'attore dominante. Sostenere che i firewall fossero una tecnologia mainstream significherebbe fraintendere Internet come mainstream. Una delle implicazioni di questa rete in rapido cambiamento era una notevole dose di ignoranza e inesperienza. In questo contesto, la gestibilità di un firewall non deve essere trascurata come fattore chiave di mercato per il vincitore finale. Oggi, nello sviluppo software, si parla di user experience e usabilità. Sebbene all'epoca non fossero questi i termini in voga, la ragione per cui oggi ne parliamo contava già allora. I clienti "preferivano" il prodotto. Quindi, per quanto sicurezza e prestazioni fossero importanti, l'usabilità della GUI del firewall Check Point non va sottovalutata. Per citare un venditore di Gauntlet dell'epoca: "Non importava chi fosse il potenziale cliente, in ogni account in cui entravo dovevo combattere contro la GUI di Check Point – e di solito perdevo". Check Point ha introdotto il proprio firewall con gestione centralizzata e un'interfaccia utente molto innovativa. Tra le funzionalità chiave figuravano:

• Un editor grafico delle regole
• Repository centrale di oggetti condiviso tra le policy dei firewall
• Logging centralizzato
• Gestione multi-dominio e OPSEC

Il Policy Editor di Check Point

Il concetto di regola firewall come quintupla composta da origine, destinazione, protocollo, porta (protocollo e porta erano combinati in un unico oggetto denominato servizio) e azione esisteva molto prima del policy editor di Check Point. Le prime access control list supportavano questo concetto già negli anni '80. Tuttavia, Check Point ha cambiato il paradigma con l'editor grafico delle regole. Non era più necessario conoscere la sintassi CLI per creare una regola. Bastavano un mouse e pochi clic. Inoltre, la modifica delle regole era arricchita da funzioni utili come copia e incolla, commenti definiti dall'utente e più oggetti per colonna. Quest'ultimo aspetto, più oggetti per colonna, è stato rivoluzionario. Le access control list precedenti supportavano una sola origine, una sola destinazione e un solo servizio nelle rispettive colonne. Il supporto di più oggetti rendeva ogni regola più potente e la modifica di una policy diventava spesso un'operazione di modifica di una regola esistente anziché di creazione di nuove regole. Gran parte di questo policy editor si basava su un altro progresso: il repository centrale di oggetti.

Il repository centrale di oggetti di Check Point

Storicamente, le access control list venivano create con un riferimento a uno specifico indirizzo IP per l'origine o la destinazione. Questo funzionava, ma se l'IP di un sistema cambiava, occorreva aggiornare ogni regola. Analogamente al codice sorgente riutilizzabile, Check Point comprese che creare un repository centrale di oggetti e utilizzare tali oggetti nelle regole sarebbe stata una strategia migliore. A quel punto, se un host cambiava IP, bastava aggiornare l'oggetto e la policy rifletteva automaticamente e correttamente tale aggiornamento, poiché utilizzava un riferimento all'oggetto memorizzato. Inoltre, era possibile creare gruppi di questi oggetti (e gruppi di gruppi) per consentire il riutilizzo di gruppi di oggetti comuni all'interno della policy. Si trattava di progressi significativi per una gestione più efficace delle policy.

Logging centralizzato

Un problema estremamente comune con i firewall è il blocco del traffico sbagliato. In particolare quando si colloca un firewall tra due reti in precedenza non segmentate, come avveniva alla fine degli anni '90 in quasi ogni nuova implementazione di firewall. Il logging centralizzato di tutti i log del firewall, facilmente consultabile, rendeva la diagnosi degli errori di policy molto evidente e relativamente semplice. Un utente poteva segnalare un problema, fornire una combinazione IP di origine / IP di destinazione e un amministratore poteva trovare il log "drop" nel visualizzatore dei log e la regola associata che aveva causato il blocco (oppure, in alternativa, trovare un log "accept" e comunicare all'utente che si sbagliava). Gli errori erano, e sono tuttora, comuni nell'amministrazione delle policy dei firewall, per cui la facilità di troubleshooting rappresentava un valore aggiunto fondamentale per qualsiasi piattaforma firewall.

Gestione multi-dominio e OPSEC

All'inizio degli anni 2000, Check Point ha puntato ancora di più sulla potenza della gestione introducendo la gestione multi-dominio con Provider-1 e le API di integrazione con OPSEC. Entrambe rappresentavano una scommessa significativa sulla capacità della gestione di differenziare Check Point dagli altri concorrenti nel settore dei firewall – e ha funzionato. Provider-1, come suggerisce il nome, era rivolto alla comunità dei provider, alle telecomunicazioni e ai managed service provider. Sebbene i provider siano stati i primi ad adottare la tecnologia, anche le aziende hanno rapidamente trovato ragioni per utilizzare il prodotto. Funzionalità chiave quali il controllo dei permessi, le prestazioni di gestione e dell'interfaccia utente ottenute suddividendo policy e database di oggetti di grandi dimensioni, e le regole globali applicabili e imponibili a livello globale erano tutte caratteristiche molto richieste dalle grandi aziende. In larga parte, si trattava di limitazioni della piattaforma di gestione standard. Se da un lato si potrebbe sostenere che Check Point avrebbe dovuto correggere la piattaforma di gestione anziché richiedere ai clienti un sovrapprezzo significativo per Provider-1, dall'altro i clienti ne hanno riconosciuto i vantaggi e sono stati disposti a pagare per queste funzionalità di gestione avanzate. OPSEC era un programma per partner e un insieme di API rilasciati da Check Point per favorire l'integrazione con prodotti di terze parti. Tra i primi successi figurano i prodotti di reporting che utilizzavano la Log Export API (LEA), i prodotti di URL filtering che utilizzavano l'URL Filtering Protocol (UFP) e i prodotti di gestione, come FireMon, che utilizzavano la Check Point Management Interface (CPMI). Il programma e le integrazioni hanno avuto un enorme successo. Oggi i partner OPSEC che offrono qualche capacità di integrazione con la piattaforma sono ben oltre 100. Questo ecosistema di prodotti di sicurezza offre ai clienti valore aggiunto e fiducia nel proprio investimento. Oggi diamo per scontate le integrazioni via API, ma nel 2001, al lancio di OPSEC, non erano affatto così diffuse.

Cisco e la CLI erano un attore dominante

Il mercato non era completamente dominato da Check Point e dalla GUI. Mentre Check Point si affermava come leader nel mercato dei firewall con una GUI potente e facile da usare, Cisco è rimasta fedele alle proprie origini con un'interfaccia a riga di comando (CLI) nel Pix. Il Pix è stato un concorrente dei primi tempi nel mercato dei firewall, risalente al 1994 e acquisito da Cisco nel 1995. La familiarità degli amministratori di rete con Cisco e con la CLI rendeva il Pix la scelta preferita quando il team di rete era responsabile della sicurezza. Check Point avrebbe eroso questo vantaggio con le proprie funzionalità di sicurezza e la GUI, favorita da un lento cambiamento nella struttura organizzativa aziendale, con la sicurezza destinata a diventare un gruppo separato dal team di rete. Con questo cambiamento, la relazione esistente tra Cisco e il team di rete ha avuto un ruolo sempre minore nella scelta del fornitore di firewall. Le funzionalità di gestione avanzate hanno contribuito a consolidare la posizione di Check Point sul mercato e hanno rafforzato il valore della gestione per i prodotti di sicurezza. Ma, così come le prestazioni hanno aiutato Check Point a battere i proxy negli anni '90, negli anni successivi le prestazioni sarebbero tornate a essere un criterio decisionale fondamentale e questa volta Check Point si sarebbe trovata sotto minaccia. Parte 3: le prestazioni al centro della scena