Un utente di rete (un Senior Manager d’azienda, in procinto di redigere un importante report) bussa alla porta del team addetto alla sicurezza. Ha un problema urgente: vuole accedere a un server protetto da firewall. Parla con la Security Engineer, che controlla la propria policy sulla sicurezza e ne conclude che l’utente in questione non debba accedere apertamente ai dati su quel server, poiché vi sono memorizzati i dati delle carte di pagamento, tra altre informazioni personali. Quindi gli nega la richiesta di accesso.
Ma l’utente è determinato: sanno con chi hanno a che fare?! Su quel server c’è un ultimo e importante dato necessario per completare il report! L’utente decide di percorrere il corridoio e raggiungere il team di rete. Conosce un Network Engineer junior che vuole far felici i suoi utenti importanti, perché vuole fare carriera nell’organizzazione! L’ingegnere è entusiasta di poter essere d’aiuto. Inventa uno schema che aggira il firewall, una rapida modifica per portare la VLAN in cui si trova il server su un router risolverà il problema! Basta ai blocchi dettati dal firewall!
Come può la Security Engineer impedire che ciò avvenga o, nel caso, a rilevarlo in modo da porvi rimedio? Dovrebbe essere in grado di monitorare ogni percorso nella rete e vedere se ne cambia qualcuno. In particolare, dovrebbe vedere quali percorsi erano controllati dai firewall e ora provengono dai router. È un problema piuttosto specifico che richiederebbe una soluzione complessa e su misura.
Lasciatelo fare a IP Fabric
La nostra Security Engineer può utilizzare il verification checking e la deep intelligence della piattaforma IP Fabric!
Per prima cosa, può creare un compliance check basato su una simulazione dell’end-to-end path. Poi crea una mappa del percorso end-to-end dal client al server da proteggere e definisce un path check.
Nel grafico il firewall è in rosso, perché le sue regole bloccano il traffico dell’applicazione, quindi il client non può parlare con il server. Perciò, quando creiamo il path check, ci aspettiamo che fallisca e, come vediamo nella tabella sottostante, è esattamente ciò che avviene.
Il giorno dopo qualcosa è cambiato. Il path verification check dimostra che il client può comunicare con il server tramite almeno un percorso:
La nostra Security Engineer esegue un controllo del percorso end-to-end e nota qualcosa di strano. Ora ci sono due percorsi verso il server e uno è visualizzato in blu, ovvero è un percorso valido. Anche se ciò non significa necessariamente che il client può accedere ai dati sul server, mostra che, se fosse scelto quel path, la connessione ignorerebbe il firewall e le norme progettate per proteggere il server.
Un rapido confronto tra questo snapshot di IP Fabric e i precedenti, mostra esattamente cosa è cambiato. Il router L66JR6 ora non invia più il traffico per la sottorete 10.66.127.0/24 tramite il firewall, ma può invece inviarlo direttamente.
A questo punto si tratta semplicemente di rintracciare le modifiche apportate alla configurazione ed eliminarle. Ciò ripristinerà la conformità alla security policy, tutto grazie ai controlli di verifica di IP Fabric!
[Il Senior Manager e il suo Network Engineer dovranno affrontare le conseguenze dell’aver violato i criteri di sicurezza, ma questo ha certamente insegnato loro che non si scherza con il security team!]
Se avete trovato utile questo articolo, continuate a seguire il nostro profilo LinkedIn o il Blog, dove pubblicheremo altri contenuti. Se desiderate vedere con i vostri occhi come IP Fabric può aiutarvi a gestire la vostra rete più efficacemente, contattateci visitando il nostro sito www.ipfabric.io.
