Security Operation Center (SOC) Design significa che la progettazione della sicurezza non può più essere concepita in modo addizionale e/o distribuito. Anche in Italia per progettare un buon SOC è necessario orchestrare hardware, software, reti e servizi gestendo, idealmente, tutto da un unico punto di controllo. Ma gli esperti sottolineano che questo è solo un’idea, non un modello reale.
Sempre e in ogni caso, il Security Operation Center Design dovrebbe diventare un asset fondamentale per qualsiasi tipo di azienda e per qualsiasi tipo di business. Come si fa lo spiega David Nathans, noto esperto di sicurezza e CyberWarfare Officer che ha scritto una guida intitolata Designing and Building Security Operations Center.
Oggi le infrastrutture a supporto del business sono costituite da una pluralità di sistemi, di piattaforme e di applicazioni. Di ognuno esistono una quantità inverosimile di soluzioni a supporto della sicurezza (anti-virus, firewalls, IDS/IPS, ERP, access control, IdM, single sign-on e via dicendo), e ognuno produce una continua quantità di log che costituiscono una serie smisurata di messaggi giornalieri che andrebbero verificati per conferrmare che ogni soluzione non abbia qualche anomalia di funzionamento o indichi compromissioni, attacchi o infezioni.
Le linee guida di un buon Security Operation Center Design
Nathans riporta la questione del SOC ai suoi fondamentali, spiegando che è solo un’illusione pensare di potersi sedere alla propria scrivania e aspettare che una schermata vi racconti immediatamente che cosa sia accaduto di brutto a una rete o a un sistema host mentre luci e sirene vi avvisano immediatamente non appena qualcuno accede a qualcosa a cui non dovrebbe. Un Security Operation Center di questo tipo non esiste e probabilmente non esisterà mai. Malgrado l’innovazione tecnologica e la sofisticazione delle soluzioni contro cybercriminali e malfunzionamenti endemici dei sistemi, è difficile che sul vostro computer come per magia appaia un pop-up che vi segnala esattamente dove avete subito un attacco e di quale entità dicendovi anche come proteggere i sistemi e tutti gli endpoint a rischio.
La maggior parte delle volte succederà che per intercettare la causa e/o il colpevole un analista dovrà essere estremamente paziente ma anche molto determinato nel cercare quell’ago nel pagliaio che lo porterà a scoprire i problemi di sicurezza che devono essere affrontate.
Quando si tratta di Security Operation Center Design, dunque, si può partire da approcci diversi: mettere una persona preposta a controllare un IDS (Intrusion Detection System) tutto il giorno oppure immaginare di dedicare una squadra di risorse (l’autore ipotizza 2500) che si occuperanno della gestione e manutenzione di centinaia di diversi tipi di dispositivi distribuiti in ogni parte del pianeta. In entrambi i casi, che il SOC sia grande o piccolo, per progettare l’infrastruttura si devono comunque prendere in considerazione gli stessi elementi e gli stessi fattori di rischio.
Come progettare l’infrastruttura organizzativa del SOC
Il Security Operation Center Design si deve occupare innanzitutto di risolvere la protezione dell’infrastruttura organizzativa (OSI – Organization Security Infrastrucure) implementata a livello aziendale in modo da mettere in sicurezza tutte le aree necessarie al business. Si tratta di progettare tutti i dispositivi e le tecnologie che andranno distribuiti in luoghi chiave rispetto all’azienda e che proteggeranno, rileveranno, o fermeranno un comportamento dannoso o un attacco.
Potrà essere un firewall utilizzato sul perimetro oppure in rete oppure soluzione fornite da società terze o fornitori di servizi in cloud fino a include software antivirus installate a protezione degli endpoint come, ad esempio, i computer di un utente.
Come già anticipato, un vero approccio di difesa include tantissimi sistemi diversi a supporto della sicurezza e tutti devono essere gestiti e monitorati da professionisti di sicurezza preparati e capaci di garantire che ogni soluzione non solo sia configurata correttamente ma anche controllata e monitorata con l’attenzione necessaria a interpretare e comprendere le segnalazioni che arrivano dalle attività di presidio.
Far capire alla direzione aziendale quanto sia arduo il compito del SOC non è banale. Il CDA, infatti, crede che si tratti di mettere una persona alla regia di un cruscotto centralizzato che segnala un problema e basta chiamare qualcuno a risolverlo, ma non è così. Se fosse così semplice, infatti, le cronache non riporterebbero così tanti episodi di violazioni dei dati.
Quello che la guida di Nathans spiega, non è quali sono e come funzionano gli strumenti a supporto della sicurezza ma le aree su cui il Security Operation Center Design deve puntare per definire e progettare un’infrastruttura di sicurezza a livello organizzativo che includa policy e procedure organizzative per:
- la difesa del perimetro
- la difesa del network
- la difesa degli host
- la difesa delle applicazioni
- la difesa dei dati
SOC: come proteggere il perimetro aziendale
Nella guida Designing and Building Security Operations Center, l’esperto racconta come ci siano differenti tipi di tecnologie che possono essere utilizzate per difendere il perimetro aziendale.
La cosa più importante prima di scegliere questo tipo di soluzioni, però, è capire che il perimetro rappresenta il limite dove il controllo e la gestione aziendale si fermano e dove iniziano le connessioni con altri service provider, business partner e altre realtà più o meno affidabili. Il modello di riferimento della sicurezza è quello di evitare il più possibile che estranei entrino nella vostra rete, riuscendo almeno a rilevare tutto ciò che non è stato possibile fermare. È questo, in sintesi, ciò che fa un firewall.
Ecco perché quando si tratta di Security Operation Center Design il firewall è di fondamentale importanza. I log prodotti da un firewall devono essere raccolti e analizzati perché sono questo tipo di informazioni che vi aiutano a capire cosa sta succedendo al vostro network, offrendo dettagli sulla caduta delle performance associate ad attacchi DoS (Denial of Services), violazioni dei sistemi, sottrazione delle identità, accessi non autorizzati, compromissione dei dispositivi e via dicendo. Controllare i log del firewall aiuta a determinare l’indirizzo IP di un sistema esterno che sta accedendo alla vostra rete mentre si utilizza un traduttore di indirizzi di rete (NAT – Network Address Translation). Solo così il Security Operations Center è in grado di interpretare l’instradamento in entrata e in uscita degli indirizzi internet.
Il passo successivo è focalizzarsi su un sistema VPN o di accesso remoto: sono questi i sistemi usati dai dipendenti e dai collaboratori che devono connettersi a un’organizzazione e accedere alle risorse quando si trovano dall’esterno della rete. È fondamentale per la salute dei sistemi assicurarsi che ogni utente abbia un accesso appropriato il che significa che quando un utente non ha più motivo di accedere, l’accesso gli viene revocato. Il monitoraggio e l’inventario aggiornato degli accessi è un’attività apparentemente noiosa, ma per i fini della sicurezza è quanto mai strategica. Ci sono anche i proxy server da considerare ma anche questa argomentazione merita un capitolo a parte che esula da questa trattazione.
SOC: come proteggere le reti
Un altro capitolo importante del Security Operation Center Design è la strategia di difesa a livello di networking interno. Ogni persona, dispositivo, sistema, applicazione comunica utilizzando un’infrastruttura di rete che va assolutamente protetta Il monitoraggio deve includere sistemi di rilevamento delle intrusioni e sistemi di prevenzione, sistemi di controllo degli accessi alla rete (NAC), insieme a sistemi di prevenzione della perdita dei dati e dei sistemi di rilevamento di anomalie comportamentali.
Gli IDS dovrebbero essere cablati ovunque ci sia un segmento di rete in grado di comunicare con un altro segmento di rete che abiliti un traffico dati. L’IDS agirà da collettore della sicurezza, permettendo di vedere tutto il traffico di rete, verificando se ci sia qualcosa che non va, che si tratti di attività malevole ad opera di qualche hacker che sta cercando di sfruttare una vulnerabilità oppure un semplice malfunzionamento a livello di sistema. L’IDS è di vitale importanza per la SOC non solo a supporto delle attività di analisi e di valutazione ma anche per la gestione e la manutenzione dei sistemi. I NAC sono anche grandi di aiutare gli amministratori si sistema nelle attività di prevenzione rispetto ai dispositivi che devono connettersi per vari motivi a una rete interna.
I Security Operation Center dovrebbero tenere d’occhio non solo le anomalie di rete e i dispositivi ad essa collegati o non collegati. Un attaccante non ha bisogno di essere al di fuori della rete, operando in qualche luogo lontano. Il cybercriminale potrebbe operare all’interno dell’organizzazione e cercare di ottenere l’accesso ai dati e alle risorse così come accedere a una sala conferenze incustodito.
Registri e avvisi provenienti da questi tipi di sistemi sono importanti informazioni che devono essere raccolti e analizzati dal SOC, questo potrebbe anche includere i sistemi che tentano di connettersi a qualsiasi rete wireless o cercare di impersonare la rete wireless vera l’organizzazione è in esecuzione.
SOC: come proteggere gli host
Per un SOC è di primaria importanza gestire e monitorare le macchine attraverso l’uso di sistemi come, ad esempio, antivirus, controlli di dispositivi per USB, sistemi di prevenzione della perdita dei dati basati su host (Data Loss Prevention – DLP). Quando il software antivirus rileva la presenza di un malware si innescano una serie di azioni (una delle quali è, auspicabilmente, la pulizia del virus).
Il problema, purtroppo frequente, è quando ci sono virus che vengono rilevati ma non possono essere puliti per motivi diversi. La notifica che arriva al Security Operation Center offre comunque un’indicazione di metodo su come sia necessario un intervento manuale. Spesso i virus sono progettati per rubare dati o aprire un ingresso ai sistemi così da consentire un più facile accesso agli aggressori anche nel caso di reti protette.
Ogni volta che i dati stanno lasciando la rete sarebbe bene avere una soluzione capace di valutare se il workflow ha una destinazione conosciuta e affidabile. I sistemi di Data Loss Prevention operano sia a livello di rete che a livello di host, e devono essere configurati secondo determinate regole per rilevare se sono a rischio dati importanti e se questi sono veicolati su una rete in modo corretto. Queste regole applicate ai sistemi di gestione devono essere mantenute e periodicamente riviste in base alle notifiche che arrivano ai SOC.
SOC: come proteggere le applicazioni
È lapalissiano ma quanto mai vero: i software che eseguono funzioni critiche o memorizzano dati importanti per l’organizzazione devono essere protette molto bene. Queste applicazioni, rispetto al network, possono risiedere praticamente ovunque: dai singoli host ai server primari fino ai mainframe.
Dal punto di vista della sicurezza, dunque, si tratta di un’area molto vasta da proteggere e i responsabili devono tenere in considerazione tanti fattori diversi, a valle e a monte: programmare la protezione di qualcosa, infatti, significa sapere come si vuole proteggere le diverse applicazioni ma anche aiutare il Security Operation Center a interfacciarsi con tutti questi sistemi di protezione.
È fondamentale gestire le patch applicative: tra i compiti del SOC, infatti, rientra la scansione regolare dei software per rilevare se sono incorse vulnerabilità legate al fatto che non è stato fatto l’aggiornamento opportuno e avvisare il proprietario del software di procedere con l’upgrade necessario. Solo così è possibile evitare che virus, shellcode e altri attacchi malevoli possano aggredire i sistemi aziendali.
Il monitoraggio delle applicazioni consente al SOC di rilevare diverse cose: quando i file sono modificati impropriamente oppure quando un utente continua a cercare la propria password, al ritmo di 1.000 volte al secondo. Queste e altre dinamiche passano sotto il controllo dei Security Operation Center che deve avere strumenti adeguati.
SOC: come proteggere i dati
Malgrado un’azienda abbia stratificato più livelli di protezione e di difesa la questione fondamentale della sicurezza rimane comunque una sola: una buona gestione dei dati e delle risorse di memorizzazione.
Che tipo di protezioni bisogna mettere in atto per proteggere i dati? Prima di tutto la crittografia dei file e dei volumi di file su qualsiasi tipo di dispositivo a livello di endpoint, così come a livello di server, fino ad arrivare alla crittografia degli accessi per gruppi. Poi protezioni fisiche che garantiscono una sicurezza del perimetro che custodisce i dati.
Sempre e in ogni caso, indipendentemente da come si decida di proteggere i dati, ci deve essere qualcuno che si occupi di guardare le segnalazioni e di intervenire andando a modificare le regole dei sistemi in base alle esigenze.
Security Operation Center Design: policy e procedure
Al di là delle tecnologie messe in campo, la sicurezza è un circolo virtuoso di policy e di procedure che vanno continuamente riviste e che impattano sui SOC garantendo i margini di azione e …di non azione.
Quando si dispone di un proxy web che protegge gli utenti dai siti dannosi, ad esempio, il SOC ha bisogno di rivedere con una certa frequenza gli eventi in modo da garantire che non ci siano stati sistemi infettati con software dannoso che è stato scaricato consapevolmente o inconsapevolmente.
Le policy aziendali a questo proposito possono essere molto precise, delimitando cosa può essere scaricato e cosa no, arrivando a decidere che cosa un dipendente sia autorizzato a vedere sul proprio computer e cosa no quando naviga on line. Allo stesso modo, ci sono una serie di prescrizioni e di autorizzazioni che possono decidere di interdire alcune aree ad alcuni dipendenti e collaboratori che, se vengono violate, possono essere oggetto di segnalazione da parte dei SOC alle HR.
Security Operation Center Design significa anche risolvere tutti questi aspetti che possono impattare sull’operatività di un’azienda. Policy e procedure devono includere aspetti che vanno ben oltre il controllo dei dispositivi e delle configurazioni e rientrare nei compiti di controllo dei SOC.
Per progettare un SOC meglio affidarsi a un security architect
Per progettare un Security Operation center da zero, una volta definito il perimetro di azione e comprese le aree di intervento, è necessario affidare la progettazione a un architetto della sicurezza, è necessario affidarsi a un archittetto della sicurezza.
Il Security Architect è un professionista che capisce le esigenze e gli obiettivi del business ma ha anche una buona capacità di comprensione di quali siano i potenziali punti deboli dell’organizzazione. Sono i security architect che devono raccomandare le tecnologie e/o le configurazioni più adatte per la continuità operativa dei sistemi legacy, aiutano a scegliere e ad acquistare i prodotti per la sicurezza e a installare i prodotti che possano monitorare e proteggere tutta l’infrastruttura.
È sempre l’architetto della sicurezza che deve occuparsi di progettare le varie contromisure commisurate sui diversi tipi di attacchi come ad esempio l’accesso non autorizzato degli utenti, la perdita di dati, l’hacking, i malware e via dicendo.
Il security architect è dunque una figura di vitale importanza per l’organizzazione, ma non sarà necessariamente una risorsa interna del SOC nel caso vi affidaste a un MSSP (Managed Security Service Provider). Questo non significa che i security architect non possano far parte del SOC ma, in genere queste figure sono parte di grandi realtà specializzate nella sicurezza che lavorano con diversi SOC per identificare le aree di debolezza o le aree che necessitano di miglioramento.
I requisiti di un Security Architect? Conoscere tutti gli standard di settore e le best practice sapendo organizzare il lavoro e impostare controlli tecnici realistici. Non solo deve essere sempre aggiornato con tutte le tendenze tecnologiche a livello di reti, applicazioni, sistemi e dispositivi ma anche rimanere allineato con l’evoluzione della sicurezza dal punto di vista organizzativo rispetto a esigenze, dimensioni, soluzioni di riferimento per definire un progetto di SOC scalabile (la scalabilità è parte integrante della strategia del Security Operation Center Design).
È necessario capire le dimensioni di tutta l’infrastruttura da proteggere in modo da riuscire a prendere le decisioni a supporto della sicurezza più indicate rispetto alle soluzioni di protezione da mettere in pratica. Se si prevede di implementare un sistema di gestione degli accessi, ad esempio, è necessario sapere bene quanti utenti ci sono in modo da commisurare tutto l’equipaggiamento in modo adeguato: software, hardware, memoria, disco rigido, potenza elaborativa. Solo così si può procedere all’acquisto del numero di licenze sufficienti di tutti gli utenti che avranno accesso al sistema.
SOC design: l’importanza del SIEM e del Log Management
Ci sono tonnellate di documenti che spiegano a cosa servono gli strumenti a supporto del SIEM (Security Information and Event Management) così come c’è tutta una letteratura tecnica sul log management. Non si può parlare di Security Operation center se non si citano questi due asset, di là del loro valore assolutamente indiscusso.
Quello che è necessario capire oggi è che le cose sono molto cambiate e, rispetto al passato, non è più sufficiente acquistare un Intrusion detection System per intercettare le vulnerabilità e gli attacchi per immaginare la propria azienda al sicuro. Oggi l’informatizzazione del business ha reso talmente complesso e ramificato il sistema di accesso e di scambio delle informazioni che le minacce possono arrivare da qualsiasi punto della rete, da qualsiasi dispositivo, da qualsiasi software, da qualsiasi luogo e in qualsiasi momento. Potete continuare a installare soluzioni dedicate, a moltiplicare le soluzioni per ridondarle, a comprare le ultime soluzioni annunciate come la rivoluzione della sicurezza. Ma tutti gli esperti consigliano di fare prima di tutto un ragionamento organizzativo, stabilendo prima di tutto una priorità alle segnalazioni che i sistemi di sicurezza inoltrano ai responsabili. È questo che fa un buon SIEM che apre un processo di ticketing aiutando a razionalizzare e a programmare interventi efficienti e mirati. Ecco perché nel Security Operation Center il SIEM è una componente basilare di cui la sicurezza non può più fare senza.
L’altra faccia del SIEM è il log management: archiviare le informazioni raccolte aiuta ad analizzare le cose che non funzionano nell’immediato così come nel medio e nel lungo termine. Anche in questo caso un SOC deve includere strumenti che risolvano la gestione degli innumerevoli log in maniera quanto più possibile automatizzata, per non finire col non considerare più alcun allarme a causa della quantità di dati da analizzare.
Gestione della sicurezza: l’importanza delle procedure di ticketing
Le notifiche devono essere impostate in modo automatico attraverso criteri di priorizzazione progettati a seguito di un’accurata analisi delle soluzioni più mission critical e, via via a scalare. E anche in questo caso è necessario istituite un sistema di ticketing associato alle gerarchie degli interventi, in modo da considerare solo le informazioni che servono davvero, nel momento in cui servono davvero.
Le procedure di ticketing, infatti, sono parte integrante del Security Operation Center Design. Ogni analista nel corso del tempo svilupperà un proprio stile di monitoraggio. Utilizzare un sistema di trouble ticketing consentirà di avvalersi di un vero e proprio archivio centrale in cui sono raccolti tutte le note e i dati utilizzati per eseguire le analisi degli eventi. Questo contribuisce non solo a una migliore comprensione dei flussi di lavoro ma anche a definire le best practice che potranno essere condivise con gli altri membri del team, aiutando a convalidare i risultati. Un sistema di ticket spesso può portare con se informazioni sulle risoluzioni ai problemi più comuni così come può avere indicatori che aiutano a identificare un evento positivo da un falso positivo.
Soprattutto quando l’azienda ha tanti dispositivi e infrastrutture di rete complesse, avere un sistema di trouble ticketing aiuta da un lato a gestire le anomalie e le inefficienze e, dall’altro, a collezionare esperienza e know-how in modo strutturato. Si tratta di poter contare su un database costantemente aggiornato e caratterizzato da informazioni personalizzate. Integrato a un meccanismo di segnalazioni e di scambi fatte di testi, email e/o SMS, va impostato per essere condiviso con le persone specializzate alla risoluzione del determinato problema, in modo che l’alert arrivi automaticamente alle risorse più competenti.
Nel Security Operation Center Design va pensato dunque anche un buon sistema di ticketing che permetterà ai membri del team di creare nuove voci, consentendo ai membri del SOC di mettere a sistema e gestire eventi specifici e tutti gli eventuali problemi di nuovo conio. Questi ticket possono essere basici oppure molto complessi e dettagliati, riportando frasi come “in attesa di amministratore di sistema richiamare” o “escalation di gestione”.
Il SOC ha bisogno per eseguire sempre il proprio lavoro in fretta, ma non così in fretta da non ottemperare a tutti i criteri di gestione ottimali: analisi, comprensione e definizione dell’intervento. Costruire un sistema di ticketing capace di per abbinare eventi e flussi di lavoro è necessario sia per un’analisi efficace, sia per una comunicazione e una conclusione del problema efficaci.
Quando un analista ha utilizzato tutti gli strumenti di sicurezza a disposizione ed è riuscito a stabilire l’effrazione o l’incidente ed ha superato la fase di convalida, è necessario istituire immediatamente una pratica di ticketing. Inoltre è fondamentale che tutte le informazioni disponibili siano contenute nel biglietto generato o creato a seguito dell’evento e che queste informazioni siano il più possibile dettagliate.
Bisogna collezionare i report, le schermate, gli alert sulla rete, tutte le possibili segnalazioni di anomalie o variazioni anomale, includendo il tutto nel ticket. Uno degli avvertimenti ai responsabili del SOC è che non dovrebbero essere posti limiti alla capacità di storage per questo tipo di sistemi. Il tutto considerando non solo che l’analista deve avere il tempo di leggere e valutare ogni singolo ticket, il che può richiedere anche diverse ore, giorni o addirittura mesi ma che le persone coinvolte nell’interpretazione dei dati possono essere diverse, che lavorano su più turni di lavoro e che possono avere livelli di seniority diverse. Tutto questo per dire che bisogna anche formalizzare il linguaggio e i sistemi di codifica in modo da rimuovere le informazioni inutili o contingenti che possono creare rumore di fondo, agevolando così la lettura del ticket attraverso una selezione delle informazioni progettata a misura di SOC.
