2. Sicurezza

Questo argomento è stato trattato in networkSM.

---

Concetto di sicurezza

Sicurezza: definizione

Secondo il NIST, la sicurezza si definisce come la protezione offerta ad un sistema informativo automatizzato per raggiungere gli obiettivi atti a preservare l’integrità, la disponibilità e la riservatezza delle risorse del sistema informativo.

CIA Triad

CIA Triad è un modello fondamentale che viene usato nella sicurezza delle informazioni, che consiste in tre concetti chiave:

1. Confidenzialità: prevede che le informazioni contenute in un sistema informativo non siano rese disponibili ad accessi non autorizzati. Si divide in:
   1. data confidentiality: ci si assicura che informazioni private (confidenziali) non siano accessibile ad individui non autorizzati;
   2. privacy: ci si assicura che un soggetto possa controllare quali informazioni sono raccolte sul proprio conto e può decidere a chi possono essere divulgati questi dati.
2. Integrità: previene che le informazioni possano essere danneggiate o corrotte, rendendolo inutilizzabili o inaffidabili. Si divide in:
   1. integrità dei dati: garantisce che le informazioni e i programmi siano modificati sono in una certa maniera, previa autorizzazione;
   2. integrità del sistema: garantisce che un sistema svolga le sue sue funzioni in modo previsto, senza che vi sia una manipolazione - volontaria o accidentale - del sistema.
3. diponibilità (Availability): garantisce che l’accesso ad un sistema sia normalmente possibile.

Concetti aggiuntivi

Oltre ai principi fondamentali appena espressi, un sistema sicuro gode anche di altre caratteristiche quali:

• non ripudiabilità: garanzia che al mittente sia fornita una prova di consegna e al destinatario sia fornita una prova dell’identità del mittente, in modo che nessuno possa negare di aver processato l’informazione;
• accountability: la proprietà di un sistema per la quale si garantisce che tutte le azioni siano riconducibili a un’unica entità, responsabile delle sue azioni;
• autenticità: la proprietà che garantisce l’essere autentico e la capacità di essere verificato e affidabile, potendo verificare che ogni utente sia davvero chi dice di essere e che ogni input al sistema venga da una fonte affidabile.

Vulnerabilità

Nel contesto della sicurezza, la principale preoccupazione è che le risorse del sistema siano vulnerabili. Ad esempio, possono essere:

• corrotte e facciano una cosa errata o diano una risposta errata;
• leaky^[Qualcuno non autorizzato può accedere a quelle risorse.];
• non disponibili o molto lente.

Concetto di attacco

Attacco: definizione

Un attacco è una minaccia che, se eseguita con successo, porta ad una violazione di sicurezza o una minaccia.

Un attacco è perpetrato da un attacante, detto anche threat agent. Esistono due tipologie di attacco:

• attacco attivo: un tentativo di alterare le risorse di un sistema o le sue operazioni;
• attacco passivo: un tentativo di sfruttare informazioni provenienti dal sistema che non infieriscono sulle risorse del sistema stesso. È possibile classificare gli attacchi anche in base all’origine:
• attacco dall’interno: l’attacco viene avviato da un’entità posta all’interno della rete (detta insider), che spesso è un soggetto autorizzato ad accedere alle risorse, ma le utilizza in un modo non lecito rispetto alle autorizzazioni di cui gode;
• attacco dall’esterno: l’attacco è avviato dall’esterno del perimetro di riferimento, da un soggetto non autorizzato (detto outsider).

Superficie di attacco

Superficie di attacco: definizione

Con superificie di attacco si identifica un insieme di vulnerabilità raggiungibili e sfruttabili, presenti all’interno del sistema.

Le superfici di attacco possono essere classificate come segue:

• network attack surface, in cui rientrano le vulnerabilità relative alle reti enterprise, WAN o internet (vi fanno parte attacchi come DDoS);
• software attack surface, in cui rientrano vulnerabilità presenti in applicativi o nel sistema operativo;
• human attack surface, in cui rientrano le vulnerabilità insite nell’umano (errore, ma anche mediante tecniche di ingegneria sociale).

Attack tree

Un attack tree è una struttura dati gerarchica, costruita da rami, che rappresenta un insieme di potenziali tecniche per sfruttare vulnerabilità di sicurezza. Il nodo radice rappresenta l’obiettivo dell’attacco, mentre le modalità in cui si può raggiungere lo scopo sono rappresentate in modo iterativo ed incrementale come rami e sottonodi dell’albero. I nodi finali rappresentano i modi in cui si può iniziare un attacco, mentre nodi diversi da foglie sono nodi AND (tutti i sotto-obiettivi rappresentati dai sottonodi devono essere raggiunti) e OR (almeno uno dei sotto-obiettivi deve essere raggiunto).

Contromisure

Contromisura: definizione

Con contromisura si intende qualsiasi mezzo impiegato per affrontare un attacco.

Di solito, una contromisura viene ideata per prevenire che un attacco abbia successo; quando non è possibile (oppure fallisce per certi casi), l’obiettivo diventa quello di rilevare l’attacco e rimediare agli effetti dell’attacco. È bene notare che una contromisura può introdurre delle vulnerabilità e che può non coprire completamente tutte le vulnerabilità di un sistema, che possono permanere dopo l’implementazione della contromisura; queste possono essere sfruttate dai threat agent e rappresentano, pertanto, dei rischi per gli assets. Ciò che si persegue è la minimizzazione di questo rischio, dati altri vincoli.

Security design principles

• Economy of mechanism: il design della sicurezza implementato sia in hardware che in software, deve essere il più semplice e piccolo possibile. Più complesso è il meccanismo, più probabile è che questo contenga delle falle che possano essere sfruttate, mentre una minore complessità si associa a una minore probabilità di presenza di falle e una minore necessità di manutenzione;
• fail-safe default: le decisioni devono essere basate sui permessi tranne che sulle esclusioni^[Tutto bloccato, tranne…]. Questo consente di avere, in caso di errori, dei permessi negati, una situazione che è più sicura e facile da rilevare mentre, se si ragionasse al contrario, si avrebbe la tendenza di consentire permessi e potrebbe essere scoperta solo dopo molto tempo in caso di uso normale;
• complete mediation: ogni accesso deve essere controllato da un meccanismo di controllo degli accessi e il sistema non deve basare le sue decisioni, in merito agli accessi, da una cache^[Un esempio è dato dai sistemi che garantiscono accesso ai file, pur mancando di controlli che verificano variazioni dei permessi dopo l’apertura di un file. Per rendere questo possibile, il sistema dovrebbe avere la funzione di controllo degli accessi.];
• open design: il design di un meccanismo di sicurezza deve essere pubblico e non privato;
• separation of privilege: una pratica per la quale più attributi di un privilegio sono necessari per accedere ad una risorsa protetta^[Esempio: autenticazione a due fattori.];
• least privilege: ogni processo e ogni utente del sistema deve operare con il minor insieme di privilegi necessari per svolgere i propri compiti;
• least common mechanism: il design dovrebbe minimizzare le funzioni condivise tra utenti diversi, fornendo sicurezza mutua^[I rischi di sicurezza diminuiscono perché ci sono meno punti in comune che possono essere sfruttati.];
• psychological acceptability: i meccanismi di sicurezza non devono interferire eccessivamente col lavoro degli utenti e, al tempo stesso, soddisfare le necessità di chi deve autorizzare gli accessi;
• least astonishment: un programma dovrebbe sempre rispondere in modo che causi il minor stupore possibile nell’utente.

Isolation

Il principio di isolazione vuole che l’accesso pubblico ai sistemi sia isolato dalle risorse critiche per evitare fughe e manomissioni; l’isolazione può avvenire in modo fisico o logico. I processi e i file dei singoli utenti devono, inoltre, essere isolati l’uni dagli altri, tranne quando esplicitamente necessario. I meccanismi di sicurezza devono essere isolati in modo da prevenire l’accesso ai meccanismi stessi.

Encapsulation

L’incapsulamento è una specifica forma di isolazione basata su delle funzionalità orientate agli oggetti. La protezione viene fornita “incapsulando” una collezione di procedure e di dati in un dominio a parte, in modo che la struttura interna dei dati è accessibile solo da procedure del sottosistema protetto; la procedura può essere chiamata solo in specifici entry point del dominio.

Modularity

Si riferisce sia allo sviluppo di funzioni di sicurezza come moduli protetti e separati, sia all’uso di architetture modulari per l’implementazione e il design dei meccanismi stessi.

Layering

Si riferisce all’uso di più approcci di protezioni, sovrapposti, coprendo ogni aspetto del sistema informativo.

Policy di sicurezza

Policy di sicurezza: definizione

Una policy di sicurezza è una descrizione informale del comportamento del sistema.

Una policy di sicurezza si traduce in uno statement formale composto da regole e pratiche che specificano e regolano come il sistema deve fornire servizi di sicurezza per proteggere risorse critiche e sensibili. Per lo sviluppo di queste policy, si devono considerare:

• il valore dell’asset da proteggere;
• le vulnerabilità del sistema;
• potenziali minacce e probabilità di attacco. I compromessi cui sottostare sono:
• semplicità d’suo vs sicurezza offerta;
• costo della sicurezza vs costo del guasto e recovery.

Implementazione della sicurezza

L’implementazione della sicurezza comprende 4 aree di azione complementari:

1. prevenzione: in uno schema ideale, nessun attacco ha successo^[È difficile da realizzare, ma prevenire un gran numero di minacce è un’idea ragionevole.];
2. detection: pur non essendo possibile prevenire ogni attacco, si possono comunque rilevare;
3. risposta: se un attacco è rilevato, il sistema può rispondere in modo da interrompere l’attacco e prevenire ulteriore danno;
4. recovery: ad esempio, il recupero dei dati da una copia di backup.

Valutazione dei rischi di sicurezza

La valutazione dei rischi alla sicurezza è una fase critica, perché ci sono elevate possibilità che le risorse non vengano impegnate dove risulta più efficace, comportando sia rischi non considerati che introducono vulnerabilità, sia uno spreco di soldi e tempo nell’uso improprio di misure di protezione. Idealmente, si vorrebbe analizzare ogni asset e valutare ogni rischio connesso, col fine di adottare contromisure per ridurre il rischio ad un livello accettabile; tuttavia, richiederebbe uno sforzo elevatissimo, il che rende questo poco fattibile nella pratica. S’introduce un ulteriore problema, riguardante la decisione su cosa costituisce un livello appropriato di rischio. Idealmente si vorrebbe eliminare completamente ogni rischio; risulta, tuttavia, più realistico impiegare un ammontare di risorse in modo proporzionale al costo che un’organizzazione dovrebbe sostenere se quel rischio avviene, prendendo in analisi anche la probabilità che quel rischio, appunto, si verifichi. In questo senso, specificare un livello accettabile di rischio è indice di prudenza e consente di spendere in modo ragionevole il budget, il tempo e il personale dell’organizzazione.

Processo di valutazione dei rischi

Lo scopo del processo di valutazione dei rischi è quello di fornire una gestione, con le informazioni necessarie, per prendere decisioni ragionevoli su come impegnare le risorse a disposizione.

Si tiene, inoltre, un registro dei rischi in cui si annota l’esito del processo dell’analisi dei rischi, riportati solitamente in ordine decrescente, insieme a dettagli di varia natura (come sono stati valutati i vari item), con lo scopo di fornire tutte le informazioni necessarie su come prendere decisioni appropriate e come gestire i rischi identificati.

Identificazione delle minacce, rischi e vulnerabilità

L’obiettivo di questa fase è l’identificazione di potenziali rischi per degli asset che si prende in considerazione, precisando chi può danneggiare l’asset e come ciò può avvenire. Oltre a considerare le possibilità di calamità naturali e di altre potenziali minacce, si valutano anche gli aspetti legati a fattori umani, relativamente a:

• motivazione (perché si vuole attaccare l’organizzazione? Quanto si è motivati?);
• abilità (qual è il livello di abilità nello sfruttare la minaccia?);
• risorse;
• probabilità di attacco;
• deterrenza.

Approfondimento: valutazione delle vulnerabilità

La valutazione delle vulnerabilità è la ricerca costante di nuove vulnerabilità per mantenere sicura l’infrastruttura. Per ridurre il rischio di vulnerabilità, si possono fare alcune considerazioni:

• prima dell’acquisto, assicurandosi che il produttore rilasci costantemente patch per vulnerabilità note;
• ogni volta che un nuovo sistema è acquistato (senza consenso), accertandosi che tutte le vulnerabilità siano risolte prima dell’implementazione;
• quando si acquista un’organizzazione, controllando che le loro policy di sicurezza siano conforme con le proprie;
• quando un nuovo ufficio viene aperto, controllando sia vulnerabilità che impattino sulla disponibilità/ridondanza, ma anche per vulnerabilità fisiche alla sicurezza;
• quando ci si trasferisce in un’altra location, del tutto simile alla precedente;
• l’uso di terze parti, assicurandosi che non utilizzino apparecchiature che possano introdurre vulnerabilità al proprio ambiente. L’identificazione delle vulnerabilità è svolta principalmente con due approcci:

1. offensive cybersecurity, cioè la pratica di attaccare in modo attivo e sfruttare i sistemi per testare le difese in atto (ne è un esempio il penetration testing);
2. defensive cybersecurity, in modo da proteggere i sistemi e le reti dall’attacco identificando e mitigando vulnerabilità, oltre ad implementare misure per prevenire e rilevare attività e accessi non autorizzati. Nell’ambito della offensive cybersecurity, si identificano due gruppi principali di hacker^[La definizione di hacker è semplicemente quella di esperti il cui scopo è quello di usare conoscenze tecniche per risolvere i problemi e portare ai limiti le capacità dei sistemi informatici, senza necessariamente causare danno.]:

• cracker (o black hat hacker), il cui scopo è quello di entrare in sistemi e reti in modo intenzionale e illegale, per rubare dati, e causare, in generare, danno in modo deliberato;
• ethical hacker (o white hat hacker), il cui scopo è quello di sfruttare le proprie conoscenze per scopi difensivi. Ci si chiede cosa si deve proteggere, contro chi e quali risorse si possono spendere per ottenere protezioni, notando cosa può vedere un intruso sul sistema “vittima”, cosa può fare con quelle informazioni e se si può notare tracce di tentativi o di successo di un attacco. Esistono, tuttavia, anche delle figure intermedie (gray hat hacker) che, pur operando in modo responsabile nell’identificazione delle minacce, possono compiere operazioni tipiche dei cracker (eg. installare una backdoor dopo aver compiuto in modo diligente un’ispezione, per rivendere informazioni confidenziali così acquisite). Esistono diverse modalità di testing per la sicurezza:
• black box testing, in cui l’hacker non conosce dettagli del sistema target;
• white box testing, in cui l’hacker conosce tutti i dettagli del sistema e rappresenta una simulazione di un attacco dall’interno;
• gray box testing, in cui l’hacker conosce solo una parte dei dettagli del sistema e rappresenta una simulazione di un attaccante esterno che ha ottenuto accesso all’infrastruttura del sistema.

Trattamento dei rischi

Esistono 5 alternative per gestire i rischi identificati:

1. risk acceptance, con cui si sceglie di accettare un livello di rischio più alto del normale per motivi di business (elevato impiego di risorse), assumendo però la responsabilità di possibili conseguenze;
2. risk avoidance, con cui si sceglie di non realizzare la parte del sistema che crea il rischio (comportando una perdita nella convenienza di uso o di funzioni);
3. risk transfer, con cui si condivide la responsabilità del rischio con una terza parte (assicurazioni e joint-venture ne sono esempio);
4. reduce consequence, con cui si modifica la struttura o l’uso dell’asset a rischio per ridurre l’impatto sull’organizzazione se il rischio dovesse accadere (ad esempio sfruttando la ridondanza, dei backup off-site oppure sviluppando un piano di recupero);
5. reduce likelihood, con cui si implementano dei controlli per abbassare le possibilità che una vulnerabilità sia sfruttata (ad esempio, con l’uso di firewall).

Change management

Change management: definizione

Con change management si intende il processo usato per revisionare proposte di cambiamento ai sistemi con le implicazioni sull’utilizzo.

Cambiamenti a sistemi esistenti si rendono necessari per diverse ragioni:

• si verificano problemi o si desiderano miglioramenti;
• sono scoperte nuove minacce o vulnerabilità;
• notifica del produttore per patch o aggiornamenti hardware o software;
• avanzamenti di tecnologia;
• implementazione di nuovi servizi e funzioni legate all’IT, che richiedono cambiamenti nei sistemi esistenti;
• identificazione di nuove funzioni da svolgere, che richiedono cambiamenti ai sistemi. I cambiamenti includono non solo ambiti relativi alla sicurezza, ma anche problemi operativi più ampi.

Configuration management

Con la configuration management ci si occupa di tenere traccia della configurazione di ogni sistema in uso ed eventuali modifiche, come una lista di hardware e versioni software installati su ogni sistema. Ciò aiuta nel ripristino dei sistemi dopo un guasto e per conoscere quali patch o aggiornamenti sono rilevanti per quali sistemi.