La sfida della cybersecurity non si può vincere con i soliti approcci e tanto più è semplice il modello concettuale con il quale si gestiscono le organizzazioni tanto più la gestione sarà sicura, affidabile e funzionale.
L’adozione di un approccio Service Based Security può essere – soprattutto in questi momenti di tensione geopolitica anche sul fronte cyber – uno stimolo a vedere il governo delle nostre organizzazioni sempre più digitali con un occhio nuovo, a rendersi conto della necessità di modalità operative meno settoriali e più olistiche dove le relazioni e l’interdipendenze tra gli asset generano una realtà più complessa della somma delle parti.
Non c’è transizione digitale senza sicurezza: come evitare costosi errori
Il modello OSI
Il modello italiano prevede di costruire un perimetro nel quale vengono censiti tutti gli asset importanti delle organizzazioni per poi procedere alla messa in sicurezza e alla manutenzione della postura di sicurezza.
Il 28 febbraio, alla luce dello scoppio della guerra in ucraina, il CSIRT nazionale ha emanato un bollettino nel quale invita tutte le organizzazioni ad aumentare la postura di sicurezza cibernetica identificando una serie di misure che dovrebbero essere di gestione normale ma è sempre meglio ribadirlo.
Questo modello “a perimetro” consente di proteggere le organizzazioni senza perturbarne le attività più di tanto anche perché è ormai impossibile isolare le organizzazioni dalla rete o dare una sicurezza assoluta.
L’approccio consolidato all’interno del mondo della sicurezza è quello basato sul “modello OSI” ovvero basato sulla messa in sicurezza dei vari strati che vanno dalla rete, l’infrastruttura, i sistemi e infine le applicazioni. Un modello che è tuttora prevalente nelle organizzazioni e che ancora oggi detta lo stesso modello organizzativo aziendale con responsabilità ripartite per ogni livello del modello. Questo modello porta con sé delle enormi complicazioni all’interno delle moderne organizzazioni poiché ormai in ognuna di esse tutto è molto interconnesso e anche una piccola “svista” può compromettere l’intera azienda o ente. È ormai necessaria una sola vista nella quale ci sono tutte le responsabilità e tutto il commitment per erogare il servizio, evitando il rischio dello scaricabarile tra diverse unità dell’organizzazione.
Un modello concettuale per gestire la complessità
Si presenta la necessità di avere un modello concettuale che consenta di gestire la complessità e di valutare tutti gli asset in modo che si possa dare una priorità di sicurezza e si possano avere approcci di sicurezza adattivi a seconda della tipologia di applicazione o infrastruttura. Va da sé che non tutti gli asset all’interno delle organizzazioni hanno la stessa criticità. In una banca il servizio delle carte di pagamento ha una criticità notevolmente più alta della mobile app per prenotare la scrivania per gli smart worker.
Di solito questa attività di analisi delle criticità e dei potenziali danni è compito della valutazione di impatto che accompagna la valutazione del rischio, in questa fase vengono valutati gli impatti che l’organizzazione può avere se un asset viene violato nella sua sicurezza/affidabilità. Di solito questa valutazione è staccata da altre categorizzazioni che l’organizzazione fa per la gestione dei sistemi e per la loro evoluzioni.
Esistono normalmente delle categorizzazioni basate sul rischio, sul Catalogo dei Servizi, sulle priorità di business, sull’anzianità delle applicazioni, sul debito tecnico, e così via. Trovare un modello unico che consenta di operare semplifica enormemente le attività di governance delle organizzazioni e questo riduce la possibilità di errore e l’overhead di attività. Se le attività di gestione e governo degli asset è maggiore delle energie dedicate al buon funzionamento del sistema è necessario porsi l’obiettivo di semplificare l’approccio. Un unico modello consente di avere un solo vocabolario comune a tutta l’organizzazione e una unica percezione del rischio e delle criticità, nonché della consapevolezza del valore per il business.
L’approccio ITIL e le tappe dell’approccio service based
Da questo punto di vista può venirci incontro l’utilizzo dell’approccio ITIL che già normalmente è molto diffuso nelle nostre organizzazioni adattandolo (il “motto” di ITIL è proprio “adotta e adatta”) alla complessità delle moderne organizzazioni.
Le nostre organizzazioni sono ormai delle strutture dedicate alla erogazione dei servizi e l’obiettivo principale è quello di rispettare gli SLA che vengono presi con i clienti/utenti. L’approccio Service Based Security si sposa perfettamente con queste esigenze.
Partendo dunque da un inventario dei servizi strutturato secondo una logica business è possibile identificare quali siano i servizi che vengono erogati dall’organizzazione verso l’utenza e poi identificare quali sono i servizi di supporto trasversali ai servizi di business, applicare una logica a matrice. Ogni servizio è identificato dagli asset necessari alla erogazione, dagli SLA definiti, dagli OLA tra il servizio e altri servizi di supporto.
Sarebbe troppo lungo spiegare in dettaglio come procedere in questo inventario, questo è possibile se la creazione del Catalogo dei Servizi erogati viene fatta ai massimi livelli aziendali e tenendo conto del valore che generano e della loro criticità.
Per facilitare questo compito è utile strutturare il catalogo in “macro-servizi” e “servizi” al fine di avere una catalogazione che non sia troppo di dettaglio ma nemmeno troppo generica e dunque inefficace.
L’analisi del rischio per servizio
Effettuata questa catalogazione si può procedere a fare l’analisi del rischio per servizio e così la valutazione di impatto, identificando quali sono i servizi critici e quali servizi invece hanno una criticità minore. È possibile creare una scala a più livelli per avere delle differenziazioni in base alle esigenze interne.
Fatta questa prima catalogazione è necessario fare un inventario degli asset per ogni servizio in termini di rete, hardware, sistemi, applicazioni e personale coinvolto creando così un perimetro del servizio che sarà l’0ambito al quale applicare una postura di sicurezza sulla base della scala di cui sopra.
Non tutti i servizi sono critici allo stesso modo e in alcuni servizi è possibile tollerare una degradazione delle prestazioni mentre su altri no. Con una catalogazione per servizio si potrebbe decidere di mettere in atto una strategia per la quale di fronte ad un attacco alcuni servizi vengono degradati negli SLA o perfino spenti per spostare risorse a protezione di altri (risorse umane o tecnologiche).
Ad esempio, un Ente pubblico potrebbe decidere di degradare i tempi di pagamento dei fornitori o della contabilità di qualche giorno per poter comunque erogare i servizi importanti ai cittadini o alle imprese. Potrebbe decidere di mettere in atto strategie di disaster recovery diverse sulla base dei servizi. Questo già normalmente è una pratica diffusa ma utilizzando un approccio basato sui servizi si potrebbe semplificare l’overhead totale della gestione aziendale.
Inoltre, va considerato che ormai i servizi tecnologici sono sempre più integrati tra strato applicativo, rete e infrastruttura e la visione per servizio consente di mantenere questa unità concettuale.
Valutare quanto ogni asset sia critico
Mappare ogni servizio su tutti gli asset consente anche di valutare quanto ogni asset sia critico nel funzionamento del servizio, considerando tra gli asset anche il personale. Ovviamente ci sono ambiti di infrastruttura che vengono condivisi da più servizi e dunque è necessario avere un meccanismo per capire in che percentuale ogni servizio dipende da quell’asset. Una strategia di mitigazione del rischio potrebbe portare alla considerazione che più servizi critici non possono condividere lo stesso ambito di infrastruttura sia perché se uno viene attaccato non cadono più servizi critici, sia perché con un attacco in corso si può riconfigurare in modo da degradare il servizio nei servizi meno critici e mantenere pienamente operativi gli altri.
L’inventario degli asset per ogni servizio va costruito per servizi di comunicazione, infrastruttura hardware, dati, macchine virtuali o piattaforme varie di sistema, processi applicativi o servizi applicativi, persone e competenze critiche, processi che compongono quel servizio.
Una volta mappato il servizio è possibile perimetrarlo, ad esempio facendo in modo che ogni servizio sia in una virtual lan differente, che venga monitorato il traffico di dati o di rete tra servizi che non hanno necessità di parlarsi, che non sia possibile accedere ai dati da un servizio, un apparato o un’applicazione che non fanno parte del medesimo servizio. È anche possibile pensare di spegnere un servizio per proteggerlo sapendo bene quali sono tutte le sue componenti o adottare processi diversi pensati in momenti di crisi che producono gli stessi Livelli di Servizio attesi.
Questa vista basata sul servizio torna utile per tutti gli aspetti di gestione operativa seguendo le logiche di ITIL ma anche per quanto riguarda lo sviluppo del software che viene catalogato come manutenzione correttiva, evolutiva o adeguativa di un servizio o, nel caso di nuovi sviluppi, creazione di un nuovo servizio.
Un modello a matrice
Con questa vista per servizio viene anche abbastanza semplice ripensare l’intera organizzazione per servizio privilegiando un modello a matrice nel quale le risorse sono attribuite ad operare sui servizi in una certa percentuale del loro tempo, percentuale adattabile in caso di necessità.
Ma il modello Service Based può anche essere utile per ricostruire il modello dei costi e dunque tenere sotto controllo il costo reale di ogni servizio e anche calcolare il singolo costo della transazione su quel determinato servizio. Seguendo e adattando il modello Active Based Costing è possibile applicare un approccio Service Based Costing.
Conclusioni
Le nostre organizzazioni erogano servizi sempre più complessi, ogni servizio è composto da una catena di eventi/processi dove se solo uno si rompe il servizio non può essere erogato. È tempo di orientare l’intera organizzazione verso l’erogazione dei servizi adottando un approccio resiliente e funzionale a questo scopo.
L’approccio Service Based Security si sposa bene con una moderna gestione dei sistemi informativi, ogni realtà avrà la necessità di implementare in modo flessibile questo approccio. Ad esempio, la PA potrebbe dotarsi di un approccio comune a tutte le PA in modo che sia possibile mappare i servizi a livello più generale, fissare dei livelli di servizio e delle priorità a livello generale.
