SOC e NOC: Non una Scelta, ma una Collaborazione Essenziale per la Tua Sicurezza e la Business Continuity

In un clima spesso allarmistico, l’attenzione odierna si concentra giustamente sulle tematiche cyber. Molte aziende hanno già scelto di avvalersi di un servizio SOC (Security Operations Center), ma è davvero tutto ciò che serve per la sicurezza aziendale? Per rispondere a questa domanda, è fondamentale comprendere il ruolo strategico e la concreta importanza del NOC (Network Operations Center).

Negli ultimi anni, grazie alla mia esperienza, ho assistito numerosi clienti nel complesso percorso di integrazione di un servizio SOC all’interno delle loro organizzazioni, armonizzandolo con le soluzioni e le tecnologie esistenti. Ho avuto l’opportunità di conoscere molti dei principali attori nel settore della Cyber Security e di osservarli durante il processo di onboarding dei clienti: dall’analisi iniziale alla fase di progettazione, fino all’implementazione finale. Sebbene ogni player abbia il proprio modus operandi e un bagaglio tecnologico differente, ho notato che le metodologie di implementazione del servizio convergono attorno ad alcuni punti fermi. Tra questi, la scelta cruciale delle fonti di dati e informazioni da acquisire. Endpoint, server e firewall perimetrali: questa è la triade di sorgenti vitali di eventi e comportamenti da cui ogni SOC parte nel processo di presa in carico di un nuovo cliente.

Non mi è mai capitato – e di casi ne ho visti parecchi – che venissero presi in considerazione, o anche solo citati, elementi come switch, router o access point. Mai. Ho quindi compreso un concetto molto semplice: a un SOC questi oggetti non interessano. O, più semplicemente, non rientrano nel perimetro di ciò che viene considerato realmente importante per governare la sicurezza informatica all’interno di un’organizzazione.

A un primo sguardo, tutto ciò potrebbe sembrare strano, ma approfondendo le modalità operative e organizzative di un SOC, ho capito come tale approccio sia, alla fine, pienamente condivisibile: il network, o meglio, il suo corretto funzionamento, è ritenuto semplicemente garantito. In altre parole, si dà per scontato che funzioni – e che lo faccia bene. Gli operatori di un SOC – di 1°, 2° o 3° livello – non hanno interesse nell’analizzare andamenti come il numero di linee guaste, la saturazione di un uplink o la latenza di una chiamata. “Non è il loro mestiere,” direbbe qualcuno. “Non ci serve,” dicono invece loro, serenamente, quando viene posta la domanda: “perché?”.

Da questa consapevolezza non può che nascere l’inevitabile interrogativo: “Ma allora chi se ne occupa?”

Ogni organizzazione, prima o poi, deve affrontare problemi legati alla propria rete. Dalla mia esperienza, posso rilevare che il più delle volte tutto ruota attorno a una semplice mancanza di consapevolezza: non avere la minima idea di cosa stia accadendo all’interno della propria rete.

• Internet è lento.
• La posta non funziona.
• Google non si apre.

Probabilmente qualcuno sorriderà leggendo queste affermazioni. Provate però a chiedere a chi lavora nel settore, specialmente a chi gestisce le richieste di 1° livello in un reparto IT aziendale: non è vero che queste sono le domande che quotidianamente si sentono fare, e che quasi mai ottengono una risposta convincente?

Non c’è frustrazione più grande, di fronte a un disservizio, del rendersi conto di essere completamente ciechi: in questi casi, spesso non rimane altra soluzione se non procedere a tentoni, ma quasi mai questa strada risulta la migliore, e di certo non la più veloce.

L’Indispensabile Ruolo del NOC: Collaborazione, Non Conflitto, con il SOC

Diventa quindi inevitabile capire come le competenze di un SOC debbano essere affiancate a quelle di un NOC, un team di tecnici altrettanto specializzati ma dedicati a un’unica e vitale questione: la salute del network. Non a caso, entrambi (NOC e SOC) condividono la stessa radice – “Operations Center” – ma hanno un focus differente: “Network” per il primo, “Security” per il secondo.

Il tema della cyber security ha acquisito, specialmente negli ultimi anni, una crescente importanza fino a diventare oggi un argomento primario. E mi permetto di commentare: “finalmente!”. Con la stessa franchezza, ritengo altrettanto vitale ricordare che un approccio focalizzato solo sulla security non è sufficiente a garantire il corretto funzionamento di un intero ecosistema informatico.

Per chiarire questi concetti, mi piace spesso ricorrere a similitudini dal mondo dei trasporti: un conto è avere caselli per controllare il traffico o pattuglie per prevenire violazioni del Codice della strada, un altro conto è tenere in ordine il manto stradale, costruire nuove carreggiate o dirottare il traffico in caso di incidente. Il quesito che personalmente mi pongo, osservando come è gestita oggi la comunicazione in termini di cyber security, è se sia controproducente questo continuo incalzare verso un’unica alternativa, ovvero il dotarsi di un servizio SOC come panacea in grado di contrastare ogni avversità.

Piuttosto, ritengo più vantaggioso riappropriarsi di una migliore comprensione di ciò che regola il corretto funzionamento di un sistema informatico e restituire al network – o meglio alla sua salute e al suo controllo – l’importanza e la centralità che merita. Sarebbe inutile dotarsi di veicoli a guida autonoma se poi le strade fossero sempre impraticabili a causa di lavori in corso o congestione del traffico.

Cosa Offre un NOC che un SOC Non Può? Esempi Pratici

Una simile domanda richiederebbe una risposta assai complessa e articolata in termini di soluzioni e tecnologie. Non è però così complicato mettere a fuoco alcuni aspetti che rendono il NOC indispensabile, attraverso esempi concreti e funzionali, ricavati dall’operatività quotidiana di un qualunque reparto IT aziendale. Passiamone in rassegna qualcuno:

A. “Internet è lento”: Un Grande Classico

Le cause reali compatibili con un effetto finale del genere sono incalcolabili. In questi casi, vedo molti ricorrere all’espediente di osservare l’ampiezza di banda occupata, alcuni si affidano a test improvvisati mediante l’intramontabile PING, altri ancora si abbandonano a valutazioni effimere basate sui valori di latenza osservati. Ma in tutti questi casi si tratta di una mera constatazione del risultato finale di un disservizio le cui cause rimangono incomprensibili.

In casi simili, il NOC ha un asso nella manica: la conoscenza dell’andamento storico delle metriche coinvolte. Il NOC può confermare – o smentire – se quell’occupazione di banda o quella latenza sono anomale, e lo può fare rigorosamente, perché ha memoria degli andamenti abituali dei dati oggetto di verifica, osservandoli H24. Laddove il controllo tempestivo di qualunque tecnico è destinato a rimanere circoscritto al “in quel momento”, la capacità di analisi di un NOC si propaga a confini temporali ben più estesi e all’interno di quelle frontiere trova spazio un altro asset fondamentale: la capacità di correlazione.

• La latenza è alta? Non importa, è così da qualche settimana.
• La banda occupata è alta? Lascia perdere, è normale a quest’ora del giorno.

Avere la capacità di fare queste valutazioni in tempi rapidi agevola enormemente il processo di troubleshooting e aiuta a indirizzare gli sforzi nella giusta direzione. Il concetto è facilmente assimilabile alla lezione che Neo si vede impartire da Morpheus in Matrix: “Prima o poi capirai, come ho fatto anch’io, che una cosa è conoscere il sentiero giusto, un’altra è imboccarlo.”

B. “La posta non funziona”: Allarme Rosso

Anche in questa circostanza, le possibili cause possono essere moltissime e difficili da vagliare. I problemi legati alla posta elettronica, per esperienza, possono risultare anche più complessi rispetto a quelli legati alla connettività, se non altro perché coinvolgono un aspetto applicativo che nel primo caso è assente. E non dimentichiamo una componente umana non trascurabile: a quanti è capitato di constatare che una difficoltà segnalata da un utente fosse in verità causata da una digitazione errata dell’indirizzo? L’acronimo “PEBKAC” – “Problem Exists Between Keyboard And Chair” – dice tutto.

Spesso, però, i problemi nascono da malfunzionamenti all’interno dell’infrastruttura informatica aziendale o trovano giustificazione nell’intricato e macchinoso insieme di misure e controlli che regolano il flusso dei messaggi di posta elettronica. Mai sentito parlare di DKIM, SPF, DMARC o DNSRBL? La lista di ciò che dovrebbe essere verificato è assai più lunga.

Il NOC ha la possibilità di monitorare automaticamente molte delle metriche coinvolte nei sistemi di posta elettronica e, in alcuni casi, può dimostrarsi addirittura proattivo, segnalando e gestendo un problema prima che assuma dimensioni critiche.

L’esempio più frequente – casistica in cui tutte le organizzazioni si imbattono – è “finire in una RBL” (Real-time Blackhole List): il proprio IP o il proprio dominio viene classificato come ostile e ritenuto potenziale fonte di SPAM. Un NOC può costantemente setacciare le numerose RBL ed essere avvisato quando l’organizzazione vi compare. Quando l’effetto finale è una email non consegnata, a livello strategico è fondamentale comprendere rapidamente se è necessario intervenire, e con quale strategia. Se l’inserimento in una RBL dovesse essere giustamente motivato – ad esempio a causa di un invio anomalo di messaggi, spesso riconducibile a una casella di posta “bucata” – non solo si renderebbe necessario richiederne la rimozione, ma sarebbe ancora più fondamentale risalire alle cause del problema e sanare la situazione alla radice, per evitare di finire in altre RBL. Un problema di questo tipo può essere molto fastidioso da gestire, richiedendo ore o giorni per la rimozione. Come diceva qualcuno: “prevenire è meglio che curare.”

C. “Google non si apre”: Impossibile Lavorare

Questo genere di segnalazione può essere assimilato a una categoria più ampia che raccoglie problemi di carattere applicativo, nello specifico, applicazioni web – tutto ciò che è possibile utilizzare tramite un browser.

Se pensassimo a tutte le componenti che potrebbero intervenire in una qualunque organizzazione mediamente strutturata, il computo delle possibili cause restituirebbe un risultato scoraggiante. Ancora una volta: le variabili in gioco sarebbero troppe.

ACL, URL Filtering, IPS, IDS, Malware Protection, Traffic Shaping: queste sono solo alcune delle tecnologie e funzionalità che sarebbero oggetto di verifica. Ma non solo: non è certo un segreto che molte delle applicazioni su cui si basa gran parte dell’operatività quotidiana degli utenti si trovino ora nel cloud, in modalità SaaS (Software as a Service). Microsoft 365, Google Workspace, Amazon AWS, Salesforce, Shopify, Stripe: solo per citarne alcuni. Non è così stravagante rapportare quel “Google non si apre” a una di queste casistiche, ad esempio un banale problema di accesso alla propria casella Gmail.

Anche in questo contesto, il ruolo del NOC è vitale: grazie ai propri strumenti di analisi, in grado di correlare automaticamente e in tempo reale più fonti di informazioni, il NOC è in grado di isolare eventuali anomalie, intervenendo prima che il deterioramento riscontrato possa peggiorare. La capacità di analisi di un NOC va ben oltre quanto si possa sospettare: è in grado di monitorare ed esaminare il comportamento del traffico dalla postazione di lavoro che l’ha generato fino alla farm di destinazione, attraversando il network aziendale e le infrastrutture dei provider. Può mettere in campo soluzioni di remediation automatiche – sfruttando ad esempio la tecnologia SD-WAN e la presenza di più linee di connessione. Può prendere decisioni sulla base di criteri di rischio e business continuity, dando priorità al traffico che l’organizzazione ritiene più strategico: quando la coperta è corta, da qualche parte bisogna pur tirarla.

Fermiamoci a ripensare agli esempi fin qui visti e proviamo a mettere a fuoco il ruolo che un SOC avrebbe avuto: il suo peso sarebbe stato marginale. Il SOC non gestisce l’infrastruttura di rete, non è in grado di analizzare le metriche che governano un network aziendale: se uno switch si guasta, il SOC non lo sa – non è di suo interesse. Il SOC non si occupa del corretto funzionamento della posta elettronica: può aiutare a ricostruire le circostanze legate a un episodio di phishing, ma se il problema è legato a un MTA mal configurato o a un record DNS impreciso cede volentieri il campo. Il SOC non amministra le configurazioni di un firewall, tantomeno le politiche di URL Filtering applicate: ne rileva le eventuali violazioni ma non ne gestisce la manutenzione quotidiana.

Laddove un SOC sfrutta l’enorme patrimonio di informazioni che un sistema informatico può garantire, cercando di isolare eventi potenzialmente dannosi e tentando di impedire che diventino problematici, un NOC si occupa di mantenere in buona salute l’intero network – e non solo – assicurando la business continuity e un’esperienza di utilizzo appagante.

Un aneddoto che mi piace raccontare riguarda un intervento eseguito anni fa per un’azienda di logistica che lamentava un evidente problema di prestazioni all’interno del proprio network. Sono stato coinvolto dopo che per mesi altri avevano tentato di isolare il problema. Giunto sul posto, il problema è emerso in modo quasi banale: per mesi ci si era intestarditi a inseguire una falsa pista. La soluzione era davanti agli occhi ma era rimasta celata a causa di una serie di assunzioni errate. Le prestazioni di rete, ritenute non adeguate, erano state associate a un presunto malfunzionamento dei dispositivi di networking coinvolti. La verità si è dimostrata deludente ma la soluzione è stata facile e immediata: le apparecchiature coinvolte erano perfettamente funzionanti, semplicemente non erano state configurate al meglio.

Il caso è quanto mai emblematico: molti ritengono che dotarsi di dispositivi di rete di buona fattura e generosamente dimensionati sia l’unica attenzione da avere, sufficiente a garantire un funzionamento impeccabile. Il network è una materia complessa, costituita da una miriade di protocolli in costante comunicazione eppure la maggior parte delle persone ritiene che gli switch siano come le “ciabatte della corrente”: attacchi il cavo e via. Per fortuna, non è così.

In quel caso, il protocollo Spanning Tree aveva eletto a Root Bridge un semplice access point, di modesto dimensionamento, collocato in un punto defilato di un magazzino remoto. Una rete progettata per garantire 10 Gbit/s si trovava strozzata a 100 Mbit/s. Le prestazioni reali erano circa 100 volte più basse rispetto a quelle inizialmente preventivate: un disastro. Molto probabilmente diversi tra voi sanno a cosa mi riferisco quando parlo di Spanning Tree, ma il nocciolo del problema è stata l’assenza delle informazioni più utili insieme, ovviamente, alla competenza per poterle analizzare. Morale della favola: un impianto è rimasto in sofferenza per mesi, erogando livelli di prestazione inadeguati quando paradossalmente la soluzione al problema non ha richiesto che poche linee di configurazione – e nessun intervento hardware. Il protocollo Spanning Tree – così come molte altre tecnologie in ambito network – è pane quotidiano per un NOC, oggetto di costante verifica e manutenzione.

NOC e SOC: Una Sinergia Indispensabile per la Resilienza Aziendale

Ma allora è meglio avere un NOC al posto di un SOC? La risposta è: “assolutamente no”. Quanto fin qui discusso vuole costituire un terreno solido su cui costruire una semplice riflessione: NOC e SOC non sono in contrasto, sono complementari. Entrambi sono indispensabili e la loro dinamica non è quella di una sterile contrapposizione, ma di una stretta e vantaggiosa collaborazione. Il NOC non solo amministra il network, rendendolo efficiente e affidabile, ma concorre nel predisporre le migliori condizioni utili al SOC per esercitare le proprie funzioni di controllo e contenimento. Se volessimo semplificare: ha poco senso preoccuparsi del tetto quando le fondamenta vacillano.

Il dibattito pubblico tende a indirizzare la propria attenzione quasi esclusivamente verso i temi legati alla cyber security: ciò non solo è utile, ma ancor più necessario. Non è però sufficiente – e quanto fin qui discusso spero aiuti a comprenderlo bene. Tutte le organizzazioni, specie le più complesse e strutturate, hanno la necessità vitale di garantire la propria business continuity e con essa la corrispondente resilienza. In questo difficile percorso, il NOC non ricopre solo un ruolo di supporto, ma anche e soprattutto di guida: è inverosimile pensare di avviarsi nella giusta direzione senza sapere da dove si è venuti.

Deja-Vu, con le proprie competenze ed esperienza, vuole affiancare le organizzazioni e modellare insieme ad esse un servizio NOC affidabile e al passo con le sfide che i tempi in cui viviamo impongono, permettendo ai propri reparti IT di concentrarsi sugli obiettivi aziendali e sul loro conseguimento.

La nostra vocazione si riassume in questo: “Your Network, Our Business”.