Elementi di Sicurezza e Privatezza

Elementi di Sicurezza e Privatezza Proteggere dati e sistemi: aspetti organizzativi Lez. 15-16 1

I documenti di riferimento 2

Le politiche di sicurezza Per poter mettere in sicurezza il sistema informatico di una organizzazione devo necessariamente operare delle scelte: Quali asset proteggere? Con che priorità? Chi è responsabile delle attività? Di quali poteri dispone Ecc. 3

Politiche di sicurezza La risposta a questi quesiti presuppone un posizionamento strategico della sicurezza informatica ai fini del raggiungimento degli obiettivi aziendali Può quindi essere fornita solo dal top management attraverso la definizione di opportuni documenti 4

Politiche, Standard, e Linee guida Nell ambito di (NIST 800-14) è fortemente consigliata la realizzazione di tre tipi di politiche: Enterprise information security program Issue-specific information security policy Systems-specific information security policy 5

Politiche, Standard, & Linee Guida Policy: un insieme di indicazioni e regole che indicano quali sono le aspettative del management in termini di sicurezza informatica Standard: un documento più dettagliato rispetto alla policy, che da indicazioni più precise sulle attività da svolgere Procedure e linee guida: spiegano le diverse attività da svolgere, le modalità con cui realizzarle, nonché dettano norme comportamentali 6

Enterprise Information Security Policy (EISP) Detta la linea strategica, e gli obiettivi principali a cui devono essere orientati gli investimenti dell azienda in termini di sicurezza Il documento viene solitamente predisposto dal CISO e CIO Documento di alto livello; 2-10 pagine Assegna le responsabilità per i vari settori della sicurezza ICT, compresi La manutenzione delle politiche di sicurezza Training e supporto agli utenti ifnali Fornisce lineee guida per Lo sviluppo, l implementazione e la gestione di tutte le attività rigurdanti la sicurezza informatica 7

EISP EISP deve contenere: L indicazione degli obiettivi strategici della Sicurezza Ict in azienda Indicazioni sulla struttura organizzativa che si vuole predisporre per raggiungere gli obiettivi su prefissati Ruoli e responsabilità di tutte le persone coinvolte, sottolineando le responsabilità personali Previsioni di budget 8

Issue-Specific Security Policy (ISSP) Tre caratteristiche principali: Affronta problematiche legate alla tecnologia Richiede aggiornamenti frequenti Viene predisposta a partire da un problema sollevato in ambito di policy generale Argomenti tipici: Uso E-mail, Uso Internet e World Wide Web, Configurazione minima per la difesa contro malware, Divieti sull uso di particolari tool o procedure (penetration testing, etchical hacking) Uso risorse infomrtiche aziendali 9

Componenti di una ISSP Scopo Scopo e dominio di riferimento Definizione della tecnologia analizzata Responsabilità Accesso e uso della tecnologia Modalità d accesso degli utenti Modalità d uso accettate Protezione della Privacy Usi vietati della tecnologia Atti vandalici Atti criminali Violazione Copyrighte leggi sulla proprietà intellettuale Altre restrizioni 10

Componenti di una ISSP (Continua) System Management Gestione del materiale memorizzato Controllo dipendenti Virus Protection Sicurezza Fisica Encryption Violazione della politica of Policy Procedure per riportare violazioni della politica Provvedimenti disciplinari per violazioni Aggiornamenti e modifiche Programma per la revisione e modifica della politica Vincoli sulle responsabilità Dichiarazioni circa l esclusione di responsabilità 11

Quante ISSP? Tre approcci: Un ISSP per ogni tecnologia da gestire/trattare Un ISSP generico per tutte le tecnologie Un documento modulare formato da tanti capitoli gestito centralmente 12

Systems-Specific Policy (SysSP) Essenzialmente dei documenti che servono come standard o linee guida per la configurazione e gestione di sistemi Formati da due componenti: Direttive generali Specifiche tecniche 13

Direttive generali Scritte dal management Danno indicazioni generali sulle modalità con cui procedere ala gestione manutenzione dei sistemi, nonché sulle responsabilità dei sysadmin 14

Specifiche Tecniche Specificano il modo effettivo con cui mettere in opera le direttive che provengono dal management Due metodi generali: Access control lists Configuration rules 15

Come sviluppare le politiche Processo in cui vanno previste due fasi 1. Disegno e sviluppo (o riprogettazione) 2. Avvio di un processo aziendale che consenta il perpetuarsi del processo di analisi e ridefinizione delle politiche 16

Coverage Matrix 17

CONTINGENCY PLAN 18

Che cos è il Contingency Plan? Contingency plannining (CP) Progettare le attività per gestire un evento inatteso e dannoso per l organizzazione RILEVARE, RISPONDERE (react) e RIPRISTINARE il sistema da eventi che ne hanno la sicurezza delle risorse e delle informazioni Obiettivo principale: Ripristinare nel minor tempo possibile e con il minimo costo, la modalità operativa normale a seguito di un attacco distruttivo 19

Introduzione Quando la tecnologia viene messa fuori uso e le normali attività dell organizzazione rischiano il collasso è necessario disporre di una serie di procedure che consentano all organizzazione di continuare a svolgere almeno le funzioni essenziali Più del 40% delle organizzazioni vittime di un evento anomalo, che non avevano predisposto un CP sono fallite nell arco di un anno dall evento 20

CP: componenti Incident response (IRP) Focalizzato sulla risposta immediata Disaster recovery (DRP) Focalizzato sul restore delle operazioni dopo che il disastro è avvenuto Business continuity (BCP) Focalizzato sulla ripresa delle operazioni su un sito remoto, in attesa del ripristino del sito originale 21

Timeline 22

CP contenuti Al fine di predisporre un CP è necessario: Sulla base del core business dell organizzazione identificare le funzioni critiche allo svolgimento dello stesso Identificare le risorse che supportano lo svolgimento delle funzioni critiche Prevedere potenziali criticità o disastri che possono affliggere tali risorse Selezionare i piani di recupero Implementare tali piani Testare e revisionare periodicamente i piani 23

CP: operativamente Nel contingency planning sono coinvolte 4 tipi di professionalità: CP team Incident recovery (IR) team Disaster recovery (DR) team Business continuity plan (BC) team 24

Incident Response Plan IRP: Insieme dettagliato di processi e procedure che descrivono gli eventi inattesi che possono compromettere risorse e sistemi, ed indicano anche come rilevare e mitigare gli stessi Incident response (IR): Insieme di procedure da attivare nel momento in cui viene rilevato un incidente 25

Incident Response Plan (Continua) Una minaccia diventa un attacco e quindi un incidente di sicurezza ICT quando: È diretta contro sistemi informatici Ha una certa probabilità di essere eseguita con successo Minaccia confidenzialità, integrità e disponibilità IR è una misura reattiva non preventiva 26

Incident Response Plan Deve contenere procedure che specificano: Cosa fare per rilevare un incidente (Detection phase) Cosa fare quando un incidente si è verificato (Reaction phase) Come ripristinare il tutto (Recovery phase) Post mortem 27

Detection Come rilevare un possibile tentativo di intrusione Report dagli utilizzatori dei sistemi, allarmi degli IDS, antivirus, Log correlation, ecc. Fondamentale il coinvolgimento degli utenti finali Problema Definire il limite entro cui un evento sospetto diventa attacco Incident classification: Una volta individuato un evento anomalo è necessaria una sua classificazione al fine di individuare le casistiche più adeguate per il suo trattamento 28

Reaction Una volta che un incidente è stato dichiarato e classificato è necessario avviare la procedura di reazione Allertare persone e organizzazioni chiave Contenere gli effetti dell attacco: circoscriverne la diffusione e possibilmente bloccarlo 29

Strategie di contenimento Disconnettere i sistemi coinvolti Modificare dinamicamente le regole di accesso al firewall Disabilitare gli account compromessi Disabilitare servizi compromessi o in odore di Disconettere server Disconettere l intera rete aziendale 30

Documentazione Immediamente dopo aver attivato la fase di reazione è necessario avviare la fase di documentazione dell incidente: È necessario tenere traccia di tutte le azioni intraprese durante la gestione dell incidente in particolare di ogni attiivtà è necessario indicare chi, cosa, quando, dove e perchè Serve per l analisi post-mortem 31

Escalation Durante la gestione di un incidente l IRP può realizzare di non essere più in grado di contenerne gli effetti che possono estendersi anche ad altre organizzazioni È compito di chi prepara il CP determinareil punto in cui un incidente diventa un disastro 32

Recovery Incident Recovery Inizia quando un attacco è stato contenuto e IRT ha ripreso il controllo della situazione A questo punto è necessario determinare l estensione del danno e individuare tutti i sistemi coinvolti ed il livello di danno subito Tutti questi elementi vanno accuratamente documentati e in caso di causa civile e/o penale è necessario conservare l evidenza dei danni subiti 33

Recovery Il processo di recovery consiste in: Identificare e risolvere le vulnerabilità che hanno consentito il verificarsi dell attacco Individuare criticità nei sistemi di protezione che non hanno consentito agli stessi di rilevare l attacco Eventualmente installare nuovi sistemi di monitoring e detection 34

Recovery (Continua) Ripristinare dati dai back-up Ripristinare processi e sistemi che si sono disabilitati durante la gestione dell incidente Continuare a monitorare il sistema Ripristinare la confidenza nel sistema da parte degli utenti finali e della parti coinvolte nell incidente 35

Post-mortem Al termine dell attività di recovery, IRT deve analizzare attentamente tutte le fasi della gestione dell incidente al fine di individuare eventuali criticità che fossero emerse durante le diverse fasi di gestione dell incidente per un loro miglioramento 36

Law Enforcement Un attacco informatico di norma è un reato previsto da nostro codice penale e come tale va denunciato all autorità giudiziaria 37

DISASTER RECOVERY 38

Disaster Recovery DRP Preparazione al recovery del sistema dopo un disastro naturale o artificiale Un incidente diventa un disastro quando: L organizzazione non è in grado di controllare o contenere gli effetti dell attacco Il livello di danno e distruzione dell attacco è così severo che l organizzazione non è nemmeno in grado di mettere in atto le procedure di recovery Scopo primario del DRP: ristabilire l operatività del sistema danneggiato 39

Classificazione dei disastri Naturali vs. generati dall uomo (la più comune) Velocità di propagazione: Rapidi: terremoti, incendi, alluvioni, black-out Lenti: degrado ambientale, deforestazione, carestie, ecc 40

Pianificare i disastri Classificare i potenziali disastri in funzione dell impatto Esistono a questo proposito opportune metodologie di impact analysis Punti chiave di un DRP: Chiara definizione di ruoli e responsabilità Elenco delle entità da allertare e coinvolgere Chiara definizione delle priorità Documentazione del disastro Attività di mitigazione dell impatto Alternative implementative dei sistemi critici Il DRP va testato periodicamente 41

Crisis Management DRP potrebbe fare riferimento ad un processo di CM Insieme di attività intraprese durante e dopo il disastro per assistere le persone coinvolte Attività tipiche di un team di crisis management: Supporto a persone e loro familiari durante la crisi Stabilire l impatto del disastro sulle normali attività ed eventualmente dichiarare lo stato di crisi Comunicare con il mondo esterno 42

Respondere al disastro Nella realtà gli eventi catastrofici possono superare ogni previsione DRP deve essere flessibile a configurabile a situazioni non previste Quando un disastro minaccia le sedi operative e più importanti di un organizzazione DRP diventa anche BCP 43

Business Continuity Planning (BCP) Garantire che un organizzazione possa continuare ad erogare e svolgere le sue funzioni primarie anche a fronte di un disastro È necessaria quindi un analisi preliminare per l identificazione di queste funzionalità e delle infrastrutture di supporto Solitamente effettuato di concerto con CEO Si attiva e viene eseguito concorrentemente con DRP Ristabilisce le funzioni primarie in siti alternativi (DRP è invece concentrato sul recupero delle funzioni sul luogo in cui avviene il disastro) 44

BCP: problematiche I costi sono sempre un fattore determinante per la selezione della soluzione più appropriata Opzioni per siti alternativi ad uso esclusivo: Hot site Warm site Cold site Opzioni per siti alternativi ad uso condiviso : Timeshare Service bureau Mutual agreement 45

Hot Sites Uso esclusivo Computer facility completamente configurate a replica dei servizi da rimpiazzare Warm Sites Come sopra, ma con servizi sw non completamente allineati Cold Sites Si predispone un sotto insieme di sistemi in grado di ospitare, quando necessario, i servizi da rimpiazzare 46

Uso condiviso Timeshare Sito dedicato ma preso in affitto Service Bureau Agenzie che forniscono HW su richiesta Mutual Agreement Contratti con altre organizzazioni per mutua assistenza in caso di disastro Altre soluzioni: Siti mobili Risorse di memorizzazione esterne 47

Dati Affinché un BCP possa entrare in azione il più velocemente possibile, è necessario che l organizzazione coinvolta disponga nel sito remoto dei dati necessari Le possibili opzioni sono: Electronic vaulting: batch-transfer dei dati al sito remoto, anche su base periodica Remote Journaling: trasferimento in tempo reale delle transazioni, sul sito remoto Database shadowing: copia integrale e in tempo reale dei dati critici 48

Standard Per facilitare la realizzazione dei documenti legati ad un piano della sicurezza, sono state proposte e sono in continua revisione una serie di metodologie ISO 17799 RFC 2196 NIST SP 49

BS 7799 Una metodologia molto discussa e molto diffusa in Europa BS 7799:1 Information Technology Code of Practice for Information Security Management, Originariamente nota come British Standard BS 7799 Ora ISO/IEC 17799 (since 2000) BS 7799:2 Information Security Management: Specification with Guidance for Use Scopo ISO/IEC 17799 (BS 7799:1) Fornire raccomandazione a tutti coloro che devono predisporre, implementare o gestire un sistema per la sicurezza delle informazioni e dei sistemi in una organizzazione 50

BS 7799 (II) Volume 2 Fornisce indicazioni su come implementare effettivamente quanto descritto nel volume I Come predisporre una Information Security Management Structure (ISMS) È possibile anche richiedere una certificazione del proprio ISMS, effettuata da personale opportunamente certificato Questo standard non è stato adottato tra gli altri, da USA, Germania, Giappone 51

Le dieci sezioni di ISO/IEC 17799 1. Organizational Security Policy 2. Organizational Security Infrastructure objectives 3. Asset Classification and Control 4. Personnel Security objectives 5. Physical and Environmental Security objectives 6. Communications and Operations Management objectives 7. System Access Control objectives 8. System Development and Maintenance objectives 9. Business Continuity Planning 10. Compliance objectives 52

RFC 2196 Site Security Handbook RFC 2196 Creato dal Security Area Working Group di IETF Contiene discussione e suggerimenti sulle più importanti problematiche relative alla sicurezza, con suggerimenti in merito alla loro implementazione Aspetti considerati security policies, security technical architecture, security services, and security incident handling 53

NIST Security Models Il NIST ha predisposto una serie di documenti pubblici che affrontano con diversi livelli di approfondimento diverse tematiche: SP 800-12, Computer Security Handbook SP 800-14, Generally Accepted Security Principles & Practices SP 800-18, Guide for Developing Security Plans SP 800-26, Security Self-Assessment Guide-IT Systems SP 800-30, Risk Management for Information Technology Systems La standard de facto per la PA statunitense 54