NOC vs SOC: integrazione anziché contrapposizione

In un clima spesso allarmistico, l’attenzione oggi è posta (giustamente) sulle tematiche di carattere cyber e sono molte ormai le aziende che hanno deciso di avvalersi di un servizio SOC: ma è davvero tutto quello che serve?
Per rispondere a questa domanda è necessario ricordare il ruolo del NOC e comprenderne la concreta importanza strategica.

Grazie alla posizione che spesso ricopro, ho potuto assistere in questi ultimi anni diversi tra i nostri clienti nell’intricato percorso di inserire un servizio SOC all’interno della propria organizzazione, armonizzandolo con le soluzioni e le tecnologie già presenti.
Ho potuto quindi conoscere molti tra gli attori più conosciuti in questo settore - ovvero la Cyber Security - e ho avuto la fortuna di poterli osservare durante il percorso di onboarding dei propri clienti: dalla fase di analisi, a quella di progetto per poi arrivare all’implementazione finale.
Sebbene ogni player abbia di fatto un proprio modus operandi caratteristico, così come un bagaglio di soluzioni tecnologiche differente, ho avuto modo di constatare che a conti fatti le metodologie di implementazione del servizio non sono poi così diverse e tutte tendono a convergere attorno ad alcuni punti fermi.
Tra questi, inevitabilmente, ricade la scelta cruciale delle fonti di dati e informazioni da acquisire. Endpoint, server e firewall perimetrali: è questa la triade delle sorgenti vitali di eventi e comportamenti da cui qualunque SOC parte nel processo di presa in carico di un nuovo cliente.

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

Ad un primo sguardo tutto ciò potrebbe sembrare sbagliato o quanto meno bizzarro ma affinando la consapevolezza delle modalità operative ed organizzative di un SOC ho infine compreso come tale approccio sia - alla conta dei risultati - pienamente condivisibile: il network - o meglio, il corretto funzionamento del - viene ritenuto semplicemente garantito. In parole povere: si dà per scontato che funzioni - e che lo faccia bene. Gli operatori di un SOC - e non importa che siano essi di 1°, 2° o 3° livello - non hanno interesse nell’analizzare andamenti quali ad esempio il numero di linee guaste, la saturazione di un uplink o la latenza di una call. «Non è il loro mestiere», direbbe qualcuno, semplificando. «Non ci serve», dicono invece loro, serenamente, quando gli viene posta la domanda: «perché?».

Da questa consapevolezza non può quindi che nascere l’inevitabile interrogativo: «ma allora chi se ne occupa?».

Ogni organizzazione, prima o poi, deve affrontare problemi legati al proprio network e in base alla mia esperienza non posso che rilevare come il più delle volte tutto ruoti attorno ad una semplice presa 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.

Alcuni probabilmente sorrideranno nel leggere queste affermazioni. Provate però a chiedervi - o, in alternativa, a chiedere a qualcuno che lavora nel settore, specie chi gestisce le richieste di 1° livello all’interno di un reparto IT aziendale - se non è vero che queste sono le domande che quotidianamente si sentono pronunciare… e che quasi mai ottengono una risposta (e anche quando quest’ultima arriva… non è poi così convicente).

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

Diviene quindi inevitabile capire come le competenze di un SOC debbano essere inevitabilmente affiancate a quelle di un NOC ovvero un team di tecnici altrettanto specializzati ma dedicati ad occuparsi di una e di una sola questione vitale: la salute del network.
Non è un caso che entrambi (NOC e SOC) condividano per definizione la stessa radice - ovvero «Operations Center» - ma abbiano un focus assai differente: «Network» per il primo, «Security» per il secondo.

Il tema della cyber security ha acquisito, specie negli ultimi anni, una trazione via via crescente fino a diventare oggi un argomento di primaria importanza ed è impossibile non confrontarsi con esso. E mi permetto di commentare: «finalmente!».
Con la stessa franchezza ritengo però altrettanto vitale ricordare che un approccio focalizzato sul solo concetto di security non è sufficiente a garantire il corretto funzionamento di un intero ecosistema informatico.
Nel cercare di esprire chiaramente alcuni concetti mi piace spesso fare ricorso a similitudini mutuate dal mondo dei trasporti: prendendo spunto da quanto appena detto, un conto è avere nelle autostrade dei caselli per controllare il traffico o pattuglie per prevenire e punire violazioni al 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 o meno controproducente questo continuo incalzare, logorante e a tratti quasi fastidioso, verso un’unica alternativa, ovvero il dotarsi di un servizio SOC come panacea in grado di contrastare ogni tipo di avversità o disservizio.
Piuttosto, ritengo più vantaggioso riappropiarsi di una migliore comprensione di ciò che regola il corretto funzionamento di un sistema informatico e restituire al network - o meglio alla salute e al controllo del - l’importanza e la centralità che merita. Sarebbe infatti 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 può dare quindi un NOC che un SOC non è in grado di offrire?

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

A. «Internet è lento»: un grande classico.

Le reali cause compatibili con un effetto finale del genere sono un numero mediamente incalcolabile: sono francamente e semplicemente troppe. In casi del genere vedo molti ricorrere all’espediente di osservare l’ampiezza di banda occupata sulle proprie linee, alcuni si affidano a test improvvisati mediante l’intramontabile PING, altri ancora si abbandonano a valutazioni effimere basate sui valori di latenza osservati in quel momento. Ma in tutti questi casi si tratta di una mera constatazione su quello che è il risultato finale di un disservizio le cui cause rimangono ancora incomprensibili.
In casi simili il NOC ha di prassi un asso nella manica da giocare: la conoscenza dell’andamento storico delle metriche coinvolte. Il NOC può confermare - oppure smentire - se quell’occupazione di banda, o quella latenza, sono in effetti anomale: e lo può fare rigorosamente, perché ha memoria di quelli che sono gli andamenti abituali dei dati oggetto di verifica, perché li osserva da tempo, e in modalità H24. Laddove il controllo tempestivo di un qualunque tecnico è destinato a rimanere circoscrito esclusivamente a «in quel momento» di cui sopra, 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 ovvero 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 molto rapidi agevola enormemente il processo di troubleshooting e aiuta ad 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 posso essere davvero moltissime, assai 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 anche un aspetto applicativo che nel primo caso è per lo più assente. E non dimentichiamocene, implicano necessariamente una non così trascurabile componente umana: a quanti è capitato infatti di constatare che una difficoltà segnalata da un utente fosse in verità causata da una digitazione errata dell’indirizzo del destinatario? Non so voi ma ogni tanto, facendo manutenzione alle code di invio dei vari MTA che gestisco, trovo messaggi non consegnati verso domini quali @gimeil.com, @iau.com e così via. Avete presente l’acronimo «PEBKAC»? «Problem Exists Between Keyboard And Chair» - «Il problema sta tra tastiera e sedia». Ecco, appunto.
Spesso però i problemi nascono da malfunzionamenti all’interno dell’infrastruttura informatica aziendale oppure trovano giustificazione nell’intricato nonché macchinoso insieme di misure e controlli che regolano oggigiorno il fluire dei messaggi di posta elettronica da un sistema all’altro. Mai sentito parlare di DKIM, SPF, DMARC o DNSRBL? E 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 dimensione e criticità preoccupante.
L’esempio più frequente - casistica in cui prima o poi tutte le organizzazioni si imbattono - è «finire in una RBL»: il proprio IP, o il proprio dominio, viene cioé classificato come ostile e ritenuto fonte potenziale di SPAM. Ci sarebbero molte cose da dire a riguardo, prima fra tutte la legittimità dei comportamenti tra molti degli attori coinvolti - ma non è questa la sede giusta per affrontarle. È però utile comprendere come un NOC possa costantemente setacciare le numerose RBL (Real-time Blackhole List) ed essere avvisato quando - a torto o ragione - l’organizzazione vi comparisse. Quando l’effetto finale che può essere osservato è una email che non viene consegnata, a livello strategico è fondamentale comprendere rapidamente se è necessario intervenire, e con quale strategia. Se infatti l’inserimento in una RBL dovesse invece essere giustamente motivato - ad esempio a causa di un invio anomalo di messaggi, casistica molto spesso ricondicibile ad una casella di posta che è stata «bucata» - non solo si renderebbe necessario intervenire richiedendone la rimozione ma sarebbe ancor più fondamentale risalire alle cause del problema e sanare la situazione alla radice: diversamente infatti il rischio sarebbe quello di finire inseriti in altre RBL.
Un problema di questo tipo può essere molto fastidioso da gestire: il processo di rimozione da una RBL - peggio ancora se sono più di una - può richiedere diverse ore, in alcuni casi anche giorni.
Come diceva qualcuno: «prevenire è meglio che curare».

C. «Google non si apre»: è impossibile lavorare.

Questo genere di segnalazione può essere facilmente assimilabile ad una categoria ben più ampia che raccoglie - semplifichiamo - problemi di carattere per lo più applicativo: nello specifico, applicazioni web. Volendo potremmo ridurre la questione alla seguente constatazione a carattere estremamente pratico: tutto quello che è possibile utilizzare mediante un browser.
Se pensassimo un momento a tutte le componenti che potrebbero intervenire, immaginando come scenario quello di una qualunque organizzazione mediamente strutturata, e quindi della sua infrastruttura informatica, il computo delle possibili cause restituirebbe un risultato a dir poco scoraggiante. Ancora una volta: le variabili in gioco sarebbero davvero 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 è basata gran parte dell’operatività quotidiana di un utente medio trovino ora ubicazione nel cloud, in modalità SaaS. Microsoft 365, Google Workspace, Amazon AWS, Salesforce, Shopify, Stripe: solo per citare alcuni tra i più famosi e riconoscibili.
Non è poi così stravagante rapportare ora quel «Google non si apre» ad una di queste casistiche, ad esempio un banale problema di accesso alla propria casella Gmail.
Anche in questo contesto il ruolo del NOC è a dir poco vitale: grazie ai propri strumenti di analisi, in grado di correlare automaticamente ed 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 di primo acchito sospettare: è in grado di monitorare ed esaminare il comportamento del traffico a partire dalla postazione di lavoro che l’ha generato fino ad arrivare alla farm di destinazione, attraversando il network aziendale e le infrastrutture dei provider utilizzati. 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 pure tirarla.

Fermiamoci ora a ripensare agli esempi fin qui visti e proviamo a mettere a fuoco il ruolo che un SOC avrebbe avuto in tali ambiti: se ci pensiamo bene, il suo peso sarebbe stato alquanto marginale.
Il SOC non gestisce l’infrastuttura 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 ad un episodio di phishing ma se il problema è legato ad un MTA mal configurato o un record DNS impreciso cede volentieri il campo, lasciando l’onere della diagnosi ad altri.
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 intervenire per impedire che possano diventare realmente 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 ogni tanto 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 diverso tempo - quantificabile in mesi - altri avevano tentato di isolare il problema.
Giunto sul posto, eseguite le prime verifiche, il problema è emerso in modo alquanto naturale - se vogliamo quasi banale: per mesi ci si era intestarditi ad 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 ad un presunto malfunzionamento dei dispositivi di networking coinvolti.
Se da un lato la verità si è dimostrata piuttosto delundete, dall’altro la soluzione è stata facile ed immediata: le apparecchiature coinvolte erano perfettamente funzionanti, semplicemente non erano state configurate al meglio.
Il caso è quanto mai emblematico: molti infatti ritengono che dotarsi di dispositivi di rete di buona fattura oltre che generosamente dimensionati sia l’unica attenzione da avere, sufficiente a garantire al proprio network 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 che era stata progettata per garantire 10 gbit/s si trovava strozzata a 100 mbit/s. Le prestazioni reali erano quindi circa 100 volte più basse rispetto a quelle inizialmente preventivate: senza tanti giri di parole, un disastro.
Molto probabilmente diversi tra di voi sanno a cosa mi riferisco quando parlo di Spanning Tree, ma non è questo il punto: 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 del tutto inadeguati quando paradossalmente la soluzione al problema non ha richiesto che poche linee di configurazione - e nessun intervento a livello hardware.
Il protocollo Spanning Tree - così come molte altre tecnologie in ambito network - è pane quotidiano per un NOC, oggetto di costante verifica e manutenzione.

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 insieme una semplice riflessione: NOC e SOC non sono in contrasto l’uno con l’altro, 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 ed affidabile, ma concorre nel predisporre le migliori condizioni utili al SOC per esercitare le proprie funzioni di controllo e contenimento. Se volessimo semplificare un po’: ha poco senso preoccuparsi del tetto quando le fondamenta vacillano.

Il dibattito pubblico tende ad 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 bene a comprenderlo. Tutte le organizzazioni, specie le più complesse e strutturate, hanno la necessità vitale di garantire la propria business continuity e insieme ad essa la corrispondente resilienza. In questo difficile percorso il NOC non ricopre solo un ruolo di supporto ma anche e soprattutto di guida: è infatti inverosimile pensare di avviarsi nella giusta direzione senza sapere da dove si è venuti.

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

La nostra vocazione si riassume in questo: «Your Network, Our Business».