Il tema della Cyber Security, ormai popolare e inflazionato, si riduce esclusivamente a definire contromisure generiche e generali su un contesto applicativo molto più complesso e bisognevole di analisi dettagliata in ogni suo aspetto; affidare la sicurezza del dominio tutto, con sw generico di terze parti, senza definire con precisione quali sono i requisiti di sicurezza da soddisfare, quali sono i dati conservati e trattati ed il loro livello di sensibilità e/o riservatezza, quali le applicazioni che vi insistono e quali le modalità di trasporto e i device finali che devono essere resi idonei all’accesso, fornisce un senso non corretto della sicurezza.
Non si tratta di difendere utenti privati da attacchi esterni, si tratta di proteggere tutto l’ecosistema e l’approccio deve partire necessariamente dall’alto per perimetrare con contezza il dominio ai fini della sicurezza totale.In questo campo, Logica Informatica ha una grande esperienza e mette a disposizione dei suoi clienti strumenti capaci di rafforzare la difesa dei sistemi informatici dagli attacchi più sofisticati.
Partendo dall’assunto che la Sicurezza Informatica, rappresenta la salvaguardia dei sistemi informatici da potenziali rischi e/o violazioni, gli obiettivi principali delle violazioni sono:
- il dato
- il servizio
- il sistema.
Le cause delle violazioni risiedono nelle:
- vulnerabilità interne ai sistemi;
- vulnerabilità indotte dall’ambiente circostante.
- la distribuzione delle applicazioni su device e/o driver generici e non protetti
- politiche e regole di accesso non ben delineate
Le violazioni possono avere diversa natura e diversi target tra quelli citati.
Un esempio di violazione, genericamente proveniente da un utente esterno, è rappresentato dall’attacco DOS, Denial of Service, l’obiettivo di tale violazione è rappresentato dai sistemi sotto attacco e non dalle informazioni in essi mantenute.
Lo scopo è quello di arrecare un danno al soggetto proprietario del sistema, impedendo l’utilizzo dei servizi offerti dal sistema stesso.
Tale violazione è genericamente resa possibile grazie ad alcune vulnerabilità residue a carico degli apparati di rete utilizzati come boundary del sistema, nei confronti del mondo esterno.
Una violazione diversa, ma comunque proveniente dall’esterno, è quella dell’hacker che riuscito a guadagnare i privilegi da amministratore per accedere al sistema, crea una serie di back door (ingressi al sistema nascosti, noti solo all’hacker), tramite le quali l’attaccante, in un secondo momento, e non sempre in modo immediatamente palese, potrà:
- trafugare le informazioni mantenute all’interno del sistema;
- manipolare le informazioni mantenute dal sistema al fine di:
♦ deteriorare i servizi offerti dal sistema;
♦ arrecare danni a terze parti in maniera indotta; - Arrecare danni irreparabili al sistema;
- Sfruttare il sistema ed i servizi per i propri scopi.
I principali aspetti di protezione sono:
- confidenzialità;
- integrità;
- disponibilità.
La protezione dagli attacchi informatici viene ottenuta agendo sui due livelli:
- Fisico
- Logico
Il livello logico di protezione dagli attacchi prevede l’autenticazione e l’autorizzazione di un’entità che rappresenta l’utente nel sistema.
Tale attività deve essere necessariamente delegata ad un robusto sistema di Controllo Accesso ovvero gli strumenti di sicurezza che consentono alle organizzazioni di gestire l’accesso sicuro alle applicazioni all’interno delle singole sottoreti/sottosistemi e tra diverse reti/sistemi.
L’ autenticazione aperta basata su standard e relative autorizzazioni basate su criteri dettate da un’unica infrastruttura, gestisce le credenziali essenziali sull’identità centralizzata e i privilegi sulle applicazioni grazie al servizio single sign-on (SSO).
Tutte le operazioni effettuate dall’utente debbono essere tracciate in file di log, questo processo di monitoraggio delle attività è detto audit o accountability.
Tale attività deve essere affidata a sistemi di Audit & Log che si occupano di:
- Raccogliere il log di applicazioni e sistemi;
- Rendere disponibile una Alert Console per la gestione degli allarmi;
- Rendere disponibile una Management Console per la gestione del sistema;
In genere i singoli sistemi o applicazioni hanno una modalità proprietaria di tracciare tutte le attività che vengono effettuate su di essi o tramite essi, si pensi semplicemente ad un sistema operativo o ad un boundary come un firewall od un router.
I sistemi di Audit & Log si occupano di interfacciarsi con ciascun dispositivo/applicazione/sistema al fine di recuperare il log generato e provvedono a memorizzare le informazioni in un repository centralizzato gestendo gli eventuali allarmi o warning derivanti dai messaggi di log catturati.
L’utilizzo combinato dei sistemi riportati in breve costituisce un buon metodo per proteggere i propri sistemi/informazioni a livello logico. Naturalmente i sistemi di cui in precedenza dovranno essere corredati di ulteriori meccanismi di sicurezza per ovviare a tutte le possibili vulnerabilità del sistema target.
Il principio che spinge all’utilizzo combinato di un sistema per il controllo degli accessi e di un sistema per la raccolta e la gestione del log generato dai sistemi, viene dalla filosofia secondo cui si ritiene quasi impossibile, meglio poco praticabile, impedire qualsiasi tentativo di violazione.
È sicuramente molto utile tracciare tutto ciò che accade, al fine di:
- Riuscire ad identificare in tempo reale eventuali intrusioni o assenza di servizio
- Analizzare a posteriori l’accaduto per identificare:
♦ Cause remote;
♦ Possibili contromisure.
Il livello fisico prevede la presenza di contromisure infrastrutturali ed operative che completano le contromisure elettroniche di cui al livello logico. Spesso la sicurezza informatica è intesa come un insieme di contromisure elettroniche, ma queste, in realtà possono non essere sufficienti. Un esempio di quanto detto è dato dai disturbatori elettronici utilizzati nei centri per l’elaborazione automatica dei dati classificati. Tale dispositivo, catalogabile come contromisura infrastrutturale, consente di ovviare all’utente malevolo che intende trafugare informazioni classificate dai centri EAD classificati. Un utente, abilitato alla trattazione di informazioni classificate, potrebbe, disattendendo alle normative che regolano la materia, introdurre nei centri EAD classificati dei dispositivi portatili di ultima generazione, come telefoni cellulari, e divulgare informazioni. I disturbatori inibiscono il corretto funzionamento delle apparecchiature citate in precedenza.
Adottare le contromisure elettroniche più sofisticate potrebbe generare un falso senso di sicurezza che può portare a trascurare l’utilizzo di contromisure semplici ed efficaci di natura infrastrutturale e/o operativa.
Un ulteriore falso senso di sicurezza è dato dal pensare che un sistema messo in sicurezza risulti inattaccabile. In realtà un sistema “securizzato” è un sistema le cui vulnerabilità sono state mitigate, per la maggior parte, da contromisure di diversa natura.
Potrebbero però rimanere delle vulnerabilità residue per le quali la tecnologia non offre strumenti efficaci o per le quali, dall’analisi di fattibilità economica/organizzativa effettuata nell’ambito del risk management, si ha l’indicazione di trascurare tali buchi del sistema.
Oltre alle vulnerabilità residue esistono anche delle vulnerabilità indotte dall’ambiente circostante che rendono il sistema a rischio.
In conclusione, per un sistema messo in sicurezza si deve porre l’attenzione sulle:
- Vulnerabilità residue;
- Vulnerabilità indotte.
Le vulnerabilità residue di un sistema messo in sicurezza sono in genere note e dunque mitigabili tramite delle SEF (Secure Enforced Functions) automatiche. Qualora non fossero mitigabili per via automatica sono comunque tracciabili ed eventualmente mitigabili tramite strumenti procedurali.
Molto spesso, però, un sistema nella sua configurazione sicura, manifesta delle ulteriori vulnerabilità residue. Tali vulnerabilità non sono determinabili durante la fase di progettazione delle misure di sicurezza, esse possono venire alla luce, per esempio, al momento del raggiungimento della situazione di funzionamento di regime.
Una volta raggiunta la situazione di funzionamento di regime è possibile che la mole reale dei dati trattati dai sistemi, sia tale per cui una contromisura risulti poco efficace o anche solo difficilmente utilizzabile. Le condizioni potrebbero essere tali da costringere alla revisione della stessa.
Un sistema molto utilizzato ha più vulnerabilità di un sistema poco sfruttato e comunque le contromisure di sicurezza devono poter disporre di interfacce tarate sulla mole dei dati.
Una console per il monitoraggio del traffico di rete, per esempio, potrebbe rivelarsi inefficace perché:
- lenta qualora per ciascuna “comunicazione” vengono visualizzate o gestite troppe informazioni al riguardo;
- scarsamente utilizzabile da un operatore che tra le tante informazioni non riesca ad individuare prontamente l’incidente e la sua origine; nell’ambito di un centro di controllo satellitare, molte volte il tempo di reazione agli incidenti rappresenta la vera carta vincente e risolutiva.
Anche le modalità di applicazione delle procedure di sicurezza possono risultare inadeguate o viziate da un comportamento smart dell’utente. In tali casi dovrà essere analizzata la situazione al fine di rendere efficace la misura procedurale e adeguarla all’esigenza più operativa del quotidiano degli operatori del centro.
Molte possono essere, inoltre, le vulnerabilità indotte dalle interfacce di comunicazione del sistema con il mondo esterno ai propri confini.
Qualsivoglia sistema, ad eccezione di quelli nati per un utilizzo stand-alone, necessitano della comunicazione verso altri sistemi. Questo è il motivo per cui, per il prosieguo, possiamo identificare il singolo sistema da proteggere come una componente di un sistema complessivo molto più ampio ed eventualmente distribuito geograficamente.
Notoriamente le reti di interconnessione al mondo esterno sono il mezzo tramite cui possono giungere la maggior parte degli attacchi ai sistemi informatici e rappresentano il ricettacolo di vulnerabilità. Volendo usare un parallelismo romanzesco, si potrebbe paragonare il sistema messo in sicurezza ad un castello reso sicuro dalle sue mura di cinta e dalle sue guardie interne. In realtà appena fuori dal castello le vie possono essere infestate dai briganti che rappresentano dunque il vero pericolo per le informazioni trasmesse e sono inoltre, il mezzo tramite cui vengono veicolati gli attacchi.
Sicuramente esistono delle strade di comunicazione sicure, tramite le quali le comunicazioni possono essere considerate protette adeguatamente. La scelta della rete tramite cui interconnettere il proprio sistema al mondo esterno deve dunque essere sottoposta al vaglio di un esperto team della sicurezza, al fine di definire i requisiti da soddisfare per la politica della sicurezza. Il team, inoltre, provvede alla scelta delle misure che si dovranno adottare per l’enforcing della sicurezza embedded della interconnessione acquistata dal provider.
L’enforcing della sicurezza sulle reti di comunicazione tra sistemi, può avvenire sia per via procedurale che per via automatica e per entrambe le tipologie è necessaria una preventiva e dettagliata fase di analisi delle esigenze.
Quanto detto coincide anche con il punto di vista secondo cui si conduce l’analisi della sicurezza di un sistema, analisi della:
- sicurezza interna;
- sicurezza esterna.
La sicurezza interna è data da tutti i meccanismi che riescono a ovviare alle vulnerabilità di costruzione ed alle vulnerabilità indotte ma interne ai confini del sistema. La sicurezza esterna è data da quanto consente di ovviare alle vulnerabilità indotte nel sistema tramite le interfacce con il sistema stesso.
Riportiamo i principali obiettivi dell’utilizzo delle diverse tecniche di difesa.
| Tecnica di difesa | Dato | Sistema | Servizio |
| Difesa da hacking | √ | √ | |
| Crittografia | √ | √ | |
| Sistemi di autenticazione | √ | √ | |
| Firma Dato | √ | ||
| Firewall / Secur Gateway | √ | √ | |
| Intrusion Detection System (IDS) | √ | ||
| Honeypot | √ | √ | |
| Steganografia (scambio di informazioni sotto copertura) | √ |
Approccio Consigliato
Il processo individuato e complessivo si compone dei seguenti passi:
- Definizione politica di sicurezza e definizione SSRS (Requisiti di Sicurezza e Mappatura Dati Trattati)
- Analisi e securizzazione delle architetture funzionali
- Individuazione e definizione delle specifiche di sicurezza
- Redazione:
♦ Security Design Note (SDN)
♦ RESS (Documento di Risoluzione dei Requisiti di Sicurezza)
♦ Security Target (Obiettivo di sicurezza definito, da raggiungere e mantenere)
Le Security Design Note contengono, oltre che le indicazioni per la securizzazione del centro in oggetto anche le architetture top level relative alle componenti che dovranno essere sviluppate per rafforzare il dominio in valutazione, denominate add-on di sicurezza, quali:
- Sistema per il Controllo degli Accessi (ACS)
- Sistema di Audit e Log (AeL)
- Intrusion Detection System
- Secure Enforced Function (SEF necessarie al sistema)
- Boundary Protection Device (BPD|SGW)
- Firma dei Dati
- Algoritmi di cifra se utili allo scopo
- Sistema per la gestione delle chiavi di cifra civile se utili allo scopo
