Appunti di Servizi di rete e sicurezza, tutte le lezioni

Servizi di rete e sicurezza

A cura di Stefano Silvani

Lezione n. 1: Introduzione alla sicurezza - I parte

1) La sicurezza in ICT

Cos’è la sicurezza: “poter svolgere le proprie attività senza che qualcuno possa indebitamente interferire”.

La sicurezza è emozione. Tranquillità di fare le cose che vogliamo come le vogliamo fare. Se non abbiamo questa fiducia, non possiamo avere output sperati: proteggere i propri dati da raccolta e manomissione è proteggere il proprio uso dei propri servizi (home banking, connettività).

L’importanza della sicurezza deriva dall’importanza dell’IT:

• Spesso è sottostimata.
• Qual è il ruolo dell’IT in azienda? -> Di supporto alle attività operative dell’azienda e viene visto come un fatto strumentale e vincoli di budget e bilancio vincolano molto l’IT.
• Semplifica le cose ma se ne può fare a meno (credenza comune).

Evoluzione della sicurezza ICT

1. Gestione puramente tecnologica in carico all’IT (statico, legato alla infrastruttura).
2. Generica attenzione alla rilevanza di risorse e minacce (maggiore presa di coscienza).
3. Sicurezza come gestione dei rischi operativi (consapevolezza di rilevanza dell’IT in ottica di gestione del rischio).

(Questo sopra è il percorso tipico di maturazione di una azienda.)

1

UTIU - Il presente materiale è stato realizzato a scopi didattici e ne è vietata la vendita, la riproduzione e qualsiasi manipolazione.

Individuare le risorse

Le risorse non sono i computer. Sono le informazioni e i servizi. Su quelli si investe.

Le informazioni vanno gestite anche su palmari, cellulari, portatili ecc…

Gli avversari

Vanno conosciuti per valutare il rischio.

• Utenti interni.
• Malware.
• Concorrenti, governi, terroristi, ecc…
• Criminalità tradizionale.

Hanno differenza di mezzi e obiettivi, e possibilità di contrasto.

La sicurezza non è qualcosa di statico legato alle macchine. È qualcosa di dinamico legato all’organizzazione. Le persone sono componente fondamentale nella sicurezza.

Il tecnico ha visione chiara delle variabili tecniche e il manager di alto livello capisce l’impatto della minaccia e la probabilità che questa si verifichi. Quindi occorre tenere in considerazione entrambi gli aspetti.

Evoluzione delle minacce

La figura dell’hacker solitario è sempre stata troppo romantica ed ormai anacronistica. Più che hacker si dovrebbe chiamare Cracker.

La criminalità si è avvicinata a questi nuovi ambienti, sono cambiate le forme di attacco e la loro visibilità.

L’hacker solitario non esiste più. La criminalità si è avvicinata agli ambienti informatici e li sa usare. Si collabora su scala internazionale per produrre attacchi.

2

UTIU - Il presente materiale è stato realizzato a scopi didattici e ne è vietata la vendita, la riproduzione e qualsiasi manipolazione.

Attacchi non rilevati e non riportati

Gli attacchi riportati sono circa il 20% di quelli fatti. Poca capacità tecnologica di rilevare gli attacchi riusciti. Si ha anche paura di denunciare gli attacchi subiti perché qualcuno può essere licenziato.

Gli outsourcer non hanno stimolo a denunciare gli attacchi. C’è conflitto di interesse.

Un problema sempre aperto

Migliora la sicurezza ma aumentano:

• I servizi e la loro complessità.
• Gli utenti.
• La criticità delle risorse trattate.
• La rapidità delle transazioni.

L’informatica ha andamenti tipicamente esponenziali. Il numero di servizi informatici che introduciamo aumenta a dismisura.

Conseguenze

Il fatto che non siano rilevati attacchi non vuol dire che non ce ne siano stati.

Comunque, prima curiamo i backup!

Strumento spesso sottovalutato. Impone comportamenti umani fastidiosi. Ma è quella cosa che ci consente di ritornare ad un punto noto precedente. Il backup è momento critico nella sicurezza di un’organizzazione. Es. se devo fare backup da un sistema centralizzato, il momento di backup da sistema centrale, è punto critico per un eventuale attaccante. Inoltre, il backup può fotografare scenari già compromessi. I backup sono funzioni essenziali. I backup potrebbero anche non essere del tutto sicuri. Quindi prima di installare il backup bisogna verificarne la sicurezza.

Codifica dell’attacco nello strumento

Gli attacchi informatici possono essere codificati in strumenti poi distribuiti o venduti.

Si individua una vulnerabilità, si realizza un malware, il malware viene distribuito tramite rete e poi la rete viene venduta a terzi.

3

UTIU - Il presente materiale è stato realizzato a scopi didattici e ne è vietata la vendita, la riproduzione e qualsiasi manipolazione.

Conseguenze

• Possibilità di automatizzare attacchi su vasta scala.
• Disponibilità degli strumenti per chi non ha la competenza per realizzarli (realizzare botnet: reti cattive e poi venduti a chi non è in grado di realizzarli. Tutti hanno a disposizione le botnet, anche chi non ha competenze IT).

La fiducia, un concetto importante

Ci si fida sempre di qualcuno o qualcosa. È importante capire di chi o di cosa ci si fida e perché. Se si pensa di non fidarsi di nessuno, significa che c’è qualcosa di sbagliato.

Sicurezza, l’approccio tecnologico

La sicurezza consiste nel garantire integrità, disponibilità e riservatezza delle risorse.

Questo è solo l’aspetto tecnologico della sicurezza. C’è bisogno di prendere in considerazione anche l’aspetto organizzativo e aspetti umani e di applicazione delle procedure.

Esigenze operative

• Quanto dobbiamo investire in sicurezza?
• Per proteggere cosa?
• Quanto ci aiuta usare uno strumento invece che un altro?

Sicurezza assoluta non esiste. Esistono i rischi ed esistono le tecniche per mitigare i rischi. Più investo e più mitigo i rischi. La parte residua di rischio è costosissima da mitigare. Il livello di sicurezza a cui ci si vuole porre è una decisione.

ISMS: information security management system.

ISO: international standard organization.

4

UTIU - Il presente materiale è stato realizzato a scopi didattici e ne è vietata la vendita, la riproduzione e qualsiasi manipolazione.

ISMS ISO 27001 e 27002

Standard per la sicurezza. Faccio il piano, lo implemento, lo controllo, lo attivo.

• Definizione di una politica di gestione degli ISMS.
• Definizione di un approccio per il risk assessment.
• Identificazione, analisi e valutazione del rischio.

Approccio olistico alla considerazione del rischio e prendere decisione informata sull’investimento e decisione verificabile. Perché abbiamo strumenti per controllare periodicamente, confrontare con altre organizzazioni e possibilità di aggiustare la via in itinere.

Introdurre tanta tecnologia di protezione non sempre è conveniente. Più i sistemi sono semplici più sono facili da proteggere. Con la complessità dei sistemi aumenta la probabilità di vulnerabilità. È importante che le persone aderiscano correttamente alle procedure.

2) Gestione del rischio di sicurezza ICT

Il rischio in ICT è una funzione di impatto e probabilità.

Rischio: probabilità e severità dell’impatto.

Valutare l’impatto almeno di

• Danno economico diretto.
• Costi di ripristino.
• Proprietà intellettuale.
• Danni reputazionali.
• Ritardi/rallentamento dei processi.

Probabilità

Siamo in grado di valutare la probabilità di accadimento degli incidenti?

Non sappiamo a fronte di un possibile danno qual è la probabilità che questo si verifichi (ammesso che ce ne accorgiamo, perché a volte ce ne accorgiamo per via dell’impatto che questo ha avuto).

Mancano i dati ed in un contesto in evoluzione i dati storici servono poco.

Serve seguire andamento minacce e confrontarsi con il resto dell’industria (fare benchmarking).

5

UTIU - Il presente materiale è stato realizzato a scopi didattici e ne è vietata la vendita, la riproduzione e qualsiasi manipolazione.

Tipicamente si guarda all’aspetto tecnologico e non a quello organizzativo.

Lezione n. 2: Introduzione alla sicurezza - II parte

1) Valutare e misurare la sicurezza

Log, monitoraggio, alert

I meccanismi forniscono informazioni su tentativi di violazione ed errori.

È necessario basarsi su alcune metriche. Considerando le registrazioni delle macchine e i dati provenienti dai sistemi di monitoraggio, e gli alert (segnalazioni di problemi) riscontrati da macchine e registrati su server di registrazione.

Abbiamo quindi un quadro della situazione.

Nota: un buon attaccante lascia poche tracce, sparpagliate su più sistemi e quindi è importante prendere informazioni in forma aggregata.

6

UTIU - Il presente materiale è stato realizzato a scopi didattici e ne è vietata la vendita, la riproduzione e qualsiasi manipolazione.

I meccanismi di sicurezza non funzionano se lasciati da soli. Gli uomini devono considerare le info. È importante esaminare queste informazioni.

I meccanismi di sicurezza non funzionano se abbandonati a sé stessi.

Misurare la sicurezza

È importante valutare ed evidenziare l’efficacia degli investimenti.

Non possiamo “misurare” la riduzione del rischio, ma possiamo misurare altri parametri che ci aiutano a capire quanto sono efficaci le nostre scelte. Non si può misurare il rischio, possiamo misurare la stima del rischio.

Misurare la sicurezza

Domande:

• Sono più sicuro dell'anno scorso?
• Ho speso bene i miei soldi?
• Come sono messo rispetto ad aziende simili?

No informazioni ai concorrenti sulle ns info. Ma per categorie di mercato i rischi sono analoghi e i metodi di difesa sono analoghi, quindi è utile avere un confronto. Le persone che si occupano di sicurezza fanno bene a confrontarsi per capire la correttezza degli investimenti e a fronte di nuovi tipi di rischi è necessario capire se ci siamo protetti bene.

Misurare quanto costa l'insicurezza

• Ripristino di sistemi danneggiati.
• Gestione di malfunzionamenti.

L’insicurezza può essere misurata come:

• Gestione di incidenti.
• Danni diretti (spesso unico aspetto considerato).
• Correzioni (sostituzione di prodotti, fix di codice...).

Queste cose hanno un costo, e con la corretta politica di sicurezza questi costi possono essere mitigati.

Altre misure

• Virus rilevati.
• Segnalazioni di strumenti interni.
• Segnalazioni relative al codice (es. nei controlli di qualità o in test).
• Tempi di applicazione delle patch.

Quanto si riducono i costi?

Non è una misura diretta della riduzione del rischio, in quanto manca la componente probabilistica. Aiuta comunque a capire l'efficacia degli investimenti. Difficilmente può essere scomposta per singoli controlli.

Avere una corretta gestione della sicurezza ci aiuta a contenere i costi derivanti dal verificarsi delle anomalie. Tutto questo dipende dall’impatto e probabilità di evento anomalo. Occorre componente probabilistica nella valutazione del rischio. Più probabilità e impatto sono alti più devo investire. Devo capire se l’investimento è adeguato. Non ci si può limitare a considerare le singole componenti, anche quando hanno poca probabilità di rischio, se combinate con altre funzioni, e processi, possono avere rischi elevati. Se hai 1 o N componenti ritenute sicure, non significa che quando integrate sono ancora sicure. Bisogna mantenere un atteggiamento olistico. (Catena forte quanto anello più debole.)

Nota: sicurezza non si vede, insicurezza si!

2) Principi di progettazione sicura

Sicurezza dall’inizio

Tanto più tardi viene affrontata la sicurezza in un progetto:

• Più è difficile inserire delle misure efficaci.
• Più è costoso inserirle.

Scelte poco significative sotto altri aspetti, possono esserlo molto per la sicurezza.

Keep it simple: as simple as possible

Le cose complesse sono difficili da rendere sicure:

• Difficili da progettare.
• Difficili da implementare correttamente.
• Difficili da capire/analizzare/monitorare.
• Difficili da verificare.
• Difficili da aggiornare/modificare.

Ridondanza e difesa “in profondità”

Nessun meccanismo è perfetto (anche l’orologio rotto dice l’ora giusta due volte al giorno).

Le protezioni devono essere ridondanti e su più livelli -> È uno dei punti più difficili da far apprezzare a chi paga.

Le persone passano ma i sistemi e procedure restano.

Fail secure: se fallisce il meccanismo di sicurezza

Se un meccanismo fallisce, il risultato deve essere maggiore sicurezza e meno funzionalità, non viceversa.

Se architettura di sicurezza fallisce:

• Se è ridondante, il primo sistema fallisce e continua il secondo sistema.
• Se il sistema non è pari (ridondante) e fallisce, il sistema deve comunque essere in sicurezza.

Il fallimento della sicurezza deve condurre ad un'altra situazione sicura. Anche se meno funzionale.

Questo può essere in contrasto con altre esigenze: es. se manca la corrente, la porta resta aperta o chiusa?

Compartimentazione e segregazione

Attività diverse, con diverse criticità e requisiti devono essere separate:

• Perché dalla compromissione dell’una non derivi la compromissione dell’altra.
• Per ridurre i vincoli sulla progettazione e gestione.

8

UTIU - Il presente materiale è stato realizzato a scopi didattici e ne è vietata la vendita, la riproduzione e qualsiasi manipolazione.

Il numero di interoperabilità tra sotto-parti di un sistema complesso deve essere ridotto al minimo necessario. Questo per minimizzare il rischio di vulnerabilità. I vari sottodomini (sottosistemi) interagiscono tra loro il minimo possibile.

Es: un sistema considerato trusted (fidato), se violato, quando interagisce con altri sistemi, li danneggia perché viene fatto entrare (proprio perché trusted).

Compartizione e segregazione può essere fatta a diversi livelli:

• Reti e sistemi: firewall su intranet, VPN.
• Codice: funzioni separate per gli aspetti di sicurezza.
• Personale: sistemisti con diversi ruoli e “clearance” (autorità di accedere) non deve esistere solo una persona con accesso a tutto!
• Ambienti: test, produzione (necessario dividere l’ambiente di test da quello di produzione).

Security through obscurity

È la sicurezza basata sulla speranza che l’attaccante non conosca le nostre difese.

È diverso dal “non conoscere la chiave”.

• Nel momento in cui l’informazione esce, la sicurezza è persa.
• In realtà il “segreto” è noto a molti.
• Manca la peer review, come ad esempio, in crittografia.

In realtà l’informazione è nota a molti, ai fornitori, agli utenti ecc..

La sicurezza quindi non è solo un fattore tecnologico.

Il paradigma security through obscurity non è valido. Mi manca anche il confronto con altre persone, proprio perché se devo tenere tutto segreto non posso parlarne all’esterno.

Evitarla non vuole dire che dobbiamo raccontare a tutti le nostre difese.

In una logica di mitigazione del rischio, se non conosce le nostre difese l’attaccante ha più difficoltà e può farsi scoprire più facilmente.

Monitoraggio

I meccanismi devono fornire informazioni su tentativi di violazione ed errori, ma ci vuole qualcuno che analizzi i dati e li capisca.

Flessibilità

Per i meccanismi di sicurezza è importante perché se i meccanismi di sicurezza non sono compatibili con nuove esigenze:

• Vengono disabilitati.
• Devono essere riprogettati (e pagati) daccapo.

I sistemi di sicurezza devono accompagnare la vita dell’organizzazione. Es. le patch possono produrre funzionamenti diversi. È necessario poter fare modifiche per continuare ad essere funzionali nel monitoraggio, analisi dati, protezione. A fronte di un’evoluzione di un sistema, se l’architettura di sicurezza non può evolvere, la decisione è di disabilitare l’architettura. Quindi il sistema deve essere flessibile, potersi adeguare all’organizzazione, progettata bene fin dall’inizio, semplice ecc.. è un vantaggio competitivo nel medio/lungo periodo.

9

UTIU - Il presente materiale è stato realizzato a scopi didattici e ne è vietata la vendita, la riproduzione e qualsiasi manipolazione.

Diversità

Avere sistemi diversificati può evitare che una vulnerabilità interessi tutti i componenti.

La diversità serve a rendere i sistemi più resilienti.

Importante nella difesa in profondità. Utilizzare strumenti/configurazioni inusuali può essere un vantaggio o uno svantaggio:

• Gli attacchi standard possono essere inefficaci.
• L’attaccante è probabilmente meno preparato.
• Anche le soluzioni comuni possono essere inefficaci.
• È più difficile (e costoso) trovare le competenze necessarie.

Qual è l’architettura migliore?

Quella che si conosce meglio.

È utile avere i sorgenti e la garanzia di una peer review, ma il fatto che il codice sia open source non è in sé una garanzia.

Lez. 03 - Autenticazione - I parte

1) Introduzione

Contesto

Autenticazione in rete:

• Client – server (anche P2P).
• Contesto client + contesto server.
• Protezione sulla connessione.

Logica di autenticazione in rete e non di autenticazione direttamente ad un sistema.

Per meccanismi di autenticazione