Sicurezza intranet e auditing per aziende ad alto rischio operativo

Transcript

1 Università degli studi di Torino Facoltà di Scienze Matematiche, Fisiche e Naturali Dipartimento di Informatica Anno Accademico Relazione di tirocinio Sicurezza intranet e auditing per aziende ad alto rischio operativo Relatore: Prof. Francesco Bergadano Candidato: Andrea Ratto Responsabile: Ing. Marco Molinaro

2 Ringraziamenti Ringrazio i colleghi di Blue Reply, disponibili e simpatici, il mio responsabile Marco Molinaro, sempre molto corretto, ed il mio relatore Prof. Bergadano. Un grazie speciale va ai miei amici intimi ed ai famigliari che mi hanno accompagnato sino a questo piccolo traguardo. Pag 2

3 Indice Indice generale Ringraziamenti...2 Introduzione I.Obiettivi...6 II.Abstract...7 III.Struttura del documento...8 Analisi delle problematiche 1 Introduzione e concetti Concetto di rischio La gestione del rischio Rischio operativo Basilea II e la definizione di rischio operativo Tipologie di rischio operativo Casi di alto rischio operativo Rischio operativo e sicurezza informatica Sistema informativo aziendale e sistema informatico Componenti di rischio operativo relative Sicurezza informatica Requisiti legali e standard Standard ISO ISO ISO Sarbanes Oxley Act Sviluppi storici Il contenuto legislativo La sezione I framework Altri standard e best pratices notevoli PCI DSS HIPAA Standard of Good Practice Insider threat, minacce dall'interno Caratteristiche del fenomeno...25 Pag 3

4 Indice 4.2 Dimensioni Alcuni esempi Componente umana del fenomeno Ruolo degli utenti privilegiati nell'insider threats Tipi di insider threat Frode Furto di informazioni confidenziali o proprietarie Sabotaggio informatico dall'interno Considerazioni Best practices per la sicurezza intranet Introduzione Una prospettiva sulla rete Pratiche generali Principi di sicurezza e rete interna Risk assessment Quality assurance per il sistema informatico Addestramento alla sicurezza informatica per gli utenti Documentare i controlli in atto Sicurezza delle applicazioni Architettura web Programmazione sicura Logging nelle applicazioni Corretta gestione delle credenziali nelle applicazioni Auditing del sorgente e penetration testing Utenti e gestione dell'identità Corretta definizione dell'identità digitale Politiche sulle password e single sign on Evitare l'uso di account amministrativi condivisi Separazione dei compiti e minimo privilegio Audit degli account Terminazione rapida degli account ed identità Sicurezza dei sistemi Layout sicuro della rete interna Minimizzare l'uso di account illimitati Difendersi attivamente dall'esecuzione di codice malevolo...65 Pag 4

5 Indice Attivare politiche sicure di backup e ripristino Correggere rapidamente e prevenire le vulnerabilità nei sistemi Auditing Registrare e monitorare le azioni sulla rete Individuare ed ispezionare anomalie e violazioni Effettuare il logging via rete su macchine sicure Memorizzazione sicura dei log Risposta agli incidenti...74 Progetto 1 Obiettivi e metodologia Introduzione a TCIM Funzionalità Componenti della suite Integrazioni possibili Origini ed evoluzione Architettura Target Opportunità in Italia Meccanismi di recupero dei log Il modello W7 per una politica di sicurezza centrale Il Generalized Event Model Grouping La politica di sicurezza W Centralizzare la politica di sicurezza Scenari dimostrativi Accesso illecito Accesso non autorizzato a dati sensibili Discussione critica Conclusioni Bibliografia e riferimenti online Indice delle illustrazioni Indice delle tabelle Pag 5

6 Introduzione Introduzione I. Obiettivi Questa relazione è il frutto dell'esperienza di lavoro e ricerca in ambito di sicurezza informatica svolta durante il mio tirocinio trimestrale presso Blue Reply S.r.l, società del gruppo Reply S.p.A e partner di IBM. Il primo obiettivo di questo documento è quello di analizzare le esigenze di sicurezza di un sistema informativo di un'impresa, derivanti dalle minacce a cui esso è soggetto, nonché dai requisiti legali o di altro tipo, e produrre una serie di regole valide per la sicurezza di aziende ad alto rischio operativo, i cui sistemi informativi trattano dati finanziari o sensibili di grande valore. Tali regole sono dedicate alla sicurezza della rete interna nel suo complesso, spaziando dalla programmazione degli applicativi, alla gestione dei sistemi, alle problematiche di amministrazione. Un'attenzione particolare è riservata al ruolo degli utenti legittimi del sistema informativo, in particolare ai suoi amministratori ed addetti ai lavori, ed alla sfida posta dalla necessità di difendersi da loro eventuali errori od attacchi, specialmente verso server critici, per i quali è richiesto un livello di confidenzialità elevato. Il secondo obiettivo è quello di analizzare un prodotto software venduto da IBM sotto il nome di Tivoli Insight Compliance Manager, per il monitoraggio e l'auditing centralizzato di utenti e sistemi, che viene proposto come la miglior soluzione sul mercato per contribuire a risolvere le problematiche individuate e facilitare il processo di conformazione e certificazione rispetto a diversi standard e regolamentazioni. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 6

7 Introduzione II. Abstract Il rischio operativo è legato a possibili conseguenze negative che un'impresa può subire nello svolgimento della sua attività ordinaria, derivanti da eventi come fughe di informazioni, frodi, malfunzionamenti, danneggiamenti o sabotaggi di infrastrutture ed altri. In molti casi il sistema informatico, per via delle sue funzioni di comunicazione, controllo computerizzato di apparecchiature e soprattutto di supporto al sistema informativo aziendale, è dove si concentra gran parte di tale rischio. In ambienti in cui esso è particolarmente rilevante si hanno situazioni definibili ad alto rischio operativo, caratterizzate da un'esigenza di sicurezza informatica molto forte. Minacce di diversi tipi interessano il sistema informatico di un'organizzazione, sia dall'esterno che dall'interno della rete aziendale, che può utilizzare degli standard internazionali ed altri framework per realizzare un sistema di gestione della sicurezza informatica efficiente e conforme alla legislazione. L'aspetto interno della sicurezza è stato tuttavia relativamente ignorato e solo negli ultimi tempi ci si comincia a rendere conto di come esso costituisca un fronte altrettanto importante nella difesa dei sistemi. I dati che emergono da alcune ricerche individuano come provenienti dall'interno della rete la metà degli attacchi informatici. Risulta che le imprese stanno spendendo poco per difendersi da minacce di questo tipo, sebbene ne stiano già subendo dannose conseguenze. La consapevolezza di questo fenomeno si sta diffondendo e nei prossimi anni è verosimile aspettarsi una maggiore attenzione alla sicurezza intranet, sia con maggiori investimenti da parte delle compagnie che con nuovi prodotti e soluzioni dagli operatori del settore IT. Si individuano tre categorie di minacce poste da membri interni all'azienda, o Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 7

8 Introduzione insider threat : frode, furto di informazioni e sabotaggio informatico dall'interno. Per difendersi da questi attacchi sono necessari numerosi accorgimenti, che mirano ad ottenere una rete sicura e monitorabile, su cui poter effettuare l'auditing, ovvero la verifica della correttezza delle azioni dei suoi utenti. Tivoli Compliance Insight Manager è una suite per facilitare questo processo che può raccogliere le informazioni contenute nei log di sistemi ed applicazioni, mettendole in relazione tra loro e verificandone l'ammissibilità in base ad una politica definita globale e centralizzata. Questo software, seppur con alcuni difetti, svolge un ruolo rilevante nella sicurezza intranet, per il quale poche altre soluzioni sono disponibili. III. Struttura del documento Oltre a questo capitolo, di carattere introduttivo, la relazione è divisa in due sezioni. Nella prima si esaminano le fondamenta della sicurezza informatica, il concetto di rischio ed il ruolo del sistema informativo nel rischio di impresa. Si fornisce una panoramica dei maggiori requisti legali e standard di sicurezza relativi al sistema informativo e si analizza a fondo la problematica di attacchi effettuati dall'interno della rete aziendale. Un importante capitolo è infine preposto a raccogliere le best practices e possibili soluzioni che sono state individuate per difendere la rete interna e monitorarne l'utilizzo in aziende il cui sistema informatico sia caratterizzato da alti rischi operativi. La seconda sezione è dedicata allo studio dell'applicativo Tivoli Insight Compliance Manager, di cui si descrivono funzionalità e architettura, effettuando infine un breve esame della sua validità come soluzione ad alcuni degli aspetti di sicurezza precedentemente esposti. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 8

9 Analisi delle problematiche Analisi delle problematiche 1 Introduzione e concetti Per affrontare le tematiche di sicurezza informatica in aziende ad alto rischio operativo è necessario presentare il concetto di rischio e definirne con precisione le caratteristiche della tipologia che chiamiamo operativa, introducendo anche la pratica della sua gestione. 1.1 Concetto di rischio Un concetto di rischio è sicuramente presente in tutti noi, ma, per comprenderlo e poterlo in qualche maniera misurare, è necessario trovarne una definizione più precisa. E' generalmente accettato definire il rischio come il prodotto tra due componenti, la prima riferentesi all'entità del danno derivante da un certo evento o circostanza, la seconda alla probabilità che tale evento si concretizzi. 1.2 La gestione del rischio Risulta semplice capire come persone ed organizzazioni si muovano costantemente tra numerosissimi rischi, legati agli infiniti eventi che possono arrecare dei danni; questa consapevolezza ha portato alla nascita di una teoria e delle pratiche di gestione dei rischi. La gestione del rischio è applicata in numerosi campi, tra cui l'attività di impresa, dove la disciplina prende il nome di enterprise risk management (ERM), ed anche ai sistemi informatici. L'ERM viene definito come un processo, posto in essere dal consiglio di Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 9

10 Introduzione e concetti amministrazione, dal management e da altri operatori della struttura aziendale, utilizzato per la formulazione delle strategie in tutta l organizzazione, progettato per individuare eventi potenziali che possono influire sull attività aziendale, per mantenere il rischio entro i limiti accettabili e per fornire una ragionevole sicurezza sul conseguimento degli obiettivi aziendali [COSO]. Di questo processo si riconoscono diverse fasi distinte: 1. Stabilimento del contesto Si identifica il rischio nel dominio di interesse, si stabiliscono metodologie e obiettivi, si pianifica lo svolgimento del processo. 2. Identificazione Si identificano e dettagliano i possibili eventi e circostanze che possono costituire dei rischi. Numerosi approcci sono disponibili per questa attività. 3. Stima Si stabilisce per ogni evento identificato la potenzialità in termini di danno e la sua probabilità di manifestarsi. 4. Analisi dei possibili trattamenti Per ogni rischio si analizzano le diverse possibilità di azione che ricadono tra le seguenti categorie principali: ritenzione, in cui il rischio viene mantenuto e accettato, eliminazione, in cui il rischio viene evitato del tutto, mitigazione, in cui si intraprendono delle azioni per ridurlo, trasferimento, in cui si trasferisce il rischio attraverso un'assicurazione. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 10

11 Introduzione e concetti 5. Stesura di un piano di mitigazione Viene scelta una linea d'azione per ogni rischio individuato. 6. Implementazione 7. Rivisitazione e valutazione del piano Nessun piano nasce perfetto e l'implementazione può far nascere delle esigenze di modiche al piano e fornire elementi rilevanti per il futuro. 1.3 Rischio operativo E' possibile definire delle categorie di rischio a seconda dell'oggetto interessato dalla conseguenza negativa o del tipo di evento che ne è alla base. Per le imprese sono state individuati molteplici tipi di rischi, ad esempio rischi legati a cambiamenti di mercato, al processo produttivo, a cambiamenti legislativi e politici, a parametri finanziari e a numerosi altri, formando una tassonomia più o meno completa e utilizzabile a diversi livelli di specificità, in base all'argomento di studio Basilea II e la definizione di rischio operativo Una definizione formale di rischio operativo, comunemente accettata è data dal Nuovo Accordo di Basilea, chiamato anche Basilea II. Tale accordo riguarda a livello internazionale i requisiti patrimoniali delle banche in relazione ai rischi assunti dalle stesse. L'accordo è stato siglato dal Comitato di Basilea, costituito dai governatori delle banche centrali dei dieci paesi più industrializzati, tra cui l'italia. Esso individua tipologie di rischio, metodologie di calcolo e di copertura al fine di imporre una gestione prudente del rischio e una maggiore trasparenza nella comunicazione tra le banche. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 11

12 Introduzione e concetti Si tralasciano in questa sede le implicazioni dell'accordo sulla gestione aziendale e patrimoniale delle banche e gli effetti sul mercato dei capitali, mentre ci si concentra sulla classificazione e definizione delle tipologie di rischio. L'accordo definisce rischio operativo come quello derivante da perdite risultanti da inadeguatezza o fallimenti di processi interni, persone e sistemi, o da eventi esterni [BASILEA 1]. La definizione risulta molto ampia, ma il termine operativo aiuta a comprendere come parlando di questo tipo di rischi si debba rimanere nell'ambito della normale attività di impresa, non considerando ad esempio i rischi strategici, legati ad eventuali errori nelle scelte di lungo periodo. Vengono poi esclusi esplicitamente i rischi di credito, relativi ad eventuali mancati pagamenti dai debitori, e quelli di mercato, come l'entrata di un nuovo concorrente, che sono trattati come categorie separate dall'accordo. Su alcune tipologie di rischio la definizione non risulta precisa e al riguardo le sono state mosse alcune critiche: ad esempio il rischio legale o il rischio di immagine non sono esplicitamente considerati nell'accordo; tale vaghezza tuttavia non risulterà rilevante in questa sede Tipologie di rischio operativo Basilea II individua alcuni tipologie ben precise di eventi alla base del rischio operativo [BASILEA 2]. Esse sono: frode interna, ad esempio in caso di alterazione intenzionale di dati, furto di informazioni riservate, ricatti; frode esterna, costituita da furti, falsificazioni, pirateria informatica, intrusioni nel sistema informativo e simili; Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 12

13 Introduzione e concetti incidenti sul posto di lavoro e nei rapporti di impiego, in casi di richieste di risarcimenti, violazioni di norme a tutela della salute o della sicurezza, pratiche discriminatorie; problemi relativi a clientela, prodotti e attività di impresa, come violazioni del rapporto fiduciario, fughe di informazioni, vendite di prodotti non autorizzati; danni a beni materiali, comprendente incidenti, vandalismo, catastrofi; disfunzioni e avarie di natura tecnica, tra cui anomalie di infrastrutture e applicazioni informatiche, problemi di telecomunicazione, interruzioni nell'erogazione di utenze; conformità esecutiva e procedurale, ad esempio in caso di immissione di dati errati, accessi indebiti, inadempimenti di controparti o fornitori, controversie legali con essi. Sebbene queste tipologie siano state pensate ed individuate in relazione ad istituti bancari, esse descrivono il problema in maniera sufficientemente generale da adattarsi ad ogni tipo di impresa, dimostrando come il rischio operativo sia infatti una componente ubiquitaria dell'attività imprenditoriale ed un elemento rilevante nella gestione di qualunque impresa Casi di alto rischio operativo Si hanno dei casi di rischio operativo alto quando uno o pochi singoli eventi tra le categorie sopraelencate siano sufficienti ad arrecare notevoli danni all'impresa, e la probabilità di tali eventi risulti non irrilevante. Le imprese ad alto rischio operativo sono dunque quelle che rischiano fortissime perdite in caso di problemi con i loro sistemi e processi. In questa sede Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 13

14 Introduzione e concetti si evita di considerare tra le imprese ad alto rischio operativo, quelle il cui business sia fondamentalmente basato su una o poche attività con inerenti alte probabilità di fallimento, le quali, sebbene soddisfino la definizione, hanno caratteristiche diverse e peculiari. Un banca è, ad esempio, considerabile a pieno titolo tra le imprese ad alto rischio operativo, infatti, in caso di errori o manomissioni nelle procedure di contabilizzazione o transazioni finanziarie, potrebbe perdere una fortuna in pochi attimi. Alti rischi operativi si possono riscontrare tuttavia in imprese operanti in disparati settori o anche solo in determinate aree e attività di imprese con rischi operativi mediamente bassi. Ad esempio per una centrale elettrica o uno stabilimento produttivo il rischio di un malfunzionamento e un interruzione dell'attività, come per un centro di ricerca il rischio di fuga di informazioni, possono dare luogo a situazioni con alti rischi operativi. 2 Rischio operativo e sicurezza informatica Una forte componente del rischio operativo interessa la rete aziendale ed il sistema informativo, facendo nascere l'esigenza di grande sicurezza in ambienti dove esso raggiunge livelli considerevoli. 2.1 Sistema informativo aziendale e sistema informatico Il sistema informativo aziendale è lo strumento preposto a raccogliere e custodire dati, elaborare informazioni a partire da essi e distribuirle in tutta l'azienda [EIS]. Esso è un elemento chiave dell'azienda, incaricato di trattare dati contabili e finanziari, dati legati alle procedure interne ed ai dipendenti, dati relativi al mercato e alla produzione. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 14

15 Rischio operativo e sicurezza informatica In origine un sistema cartaceo, basato su procedure manuali, è oggi nella quasi totalità dei casi costruito su un supporto informatico e sempre più automatizzato. Inoltre è verosimile che dei sistemi informatici siano utilizzati anche per la il controllo elettronico di svariate componenti interni all'azienda, come macchinari, sistemi di sicurezza e postazioni di lavoro. Si delinea dunque un sistema informatico, costituito dai calcolatori interconnessi a formare la rete aziendale, che è di grande importanza e dal cui corretto funzionamento dipendono svariate aree dell'impresa. 2.2 Componenti di rischio operativo relative Se si riesaminano le categorie di rischio operativo, si può notare facilmente che molti di quei rischi siano relativi al sistema informatico. Tra le categorie di frode interna ed esterna, problemi relativi a clientela, disfunzioni e avarie di natura tecnica, conformità esecutiva e procedurale troviamo eventi come: alterazione di dati; furto e fughe di informazioni confidenziali; intrusioni nel sistema informativo; immissione di dati errati; malfunzionamenti di applicazioni e sistemi; problemi di telecomunicazione. Questo fa comprendere come il sistema informativo ed l'infrastruttura informatica costituiscano per molte aziende la componente più interessata dal rischio operativo. Conseguentemente, in situazioni caratterizzabili come ad alto rischio operativo relativo al sistema informatico, si presenta l'esigenza di grande affidabilità e sicurezza dei sistemi della rete aziendale. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 15

16 Rischio operativo e sicurezza informatica 2.3 Sicurezza informatica La sicurezza di un sistema sistema informatico è comunemente definita come la capacità di mantenere la confidenzialità, l'integrità e la disponibilità di dati e servizi che lo costituiscono [ISO27K]. Questa definizione, basata sulla cosiddetta triade CIA (Confidentiality, Integrity, Availability), è generalmente accettata, ma ci sono stati dei tentativi di aumentarla con altri concetti, come ad esempio quello di imputabilità, che prevede la corretta attribuzione delle responsabilità delle azioni commesse ai relativi utenti [WIKIPED 1]. Assicurare la sicurezza di un sistema consiste dunque nel difenderlo da svariati rischi di compromissione dei tre aspetti sopracitati. Per i sistemi informatici si dettaglia la definizione di rischio generica, indicandolo come la probabilità che una particolare minaccia possa sfruttare una vulnerabilità del sistema [CLUSIT]. Per minaccia si intende l'evento o circostanza che può arrecare il danno e vulnerabilità una debolezza nelle procedure, nelle implementazioni, nei controlli interni o nel progetto del sistema di sicurezza. Il concretizzarsi di un rischio, costituisce in questo caso un incidente di sicurezza informatica. La pratica di rendere sicuro un sistema informatico prevede quindi che vengano poste in essere delle contromisure, che ne riducano la vulnerabilità o le minacce da cui è confrontato. Fronti della sicurezza informatica I rischi di un sistema informatico possono a loro volta essere distinti in base alle tipologie di minacce o di vulnerabilità, individuando specifiche classi di attacco. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 16

17 Rischio operativo e sicurezza informatica Ad una prima distinzione si può separare tra attacchi fisici ed attacchi informatici, di cui in particolare, considerandone l'origine, si può distinguere tra interni ed esterni, a seconda che provengano dalla rete aziendale o dall'internet. Questa relazione si concentrerà sulla sicurezza intranet, ovvero sulle minacce di attacchi interni, che, come si vedrà, sono una componente molto rilevante della sicurezza informatica e del rischio operativo. 3 Requisiti legali e standard Le esigenze di sicurezza della rete aziendale non sono solamente legate al rischio operativo, ma vengono determinate anche alcune norme legislative e standard internazionali o di settore, per cui l'impresa deve ottenere e dimostrare la compliance. Nei prossimi paragrafi verranno esaminati gli standard di sicurezza ISO e e la legge americana conosciuta come Sarbanes Oxley Act sulla contabilità delle aziende quotate, che pone diversi requisiti al sistema informativo di tali compagnie. 3.1 Standard ISO IS e sono standard pubblicati dall'international Organization for Standardization (ISO) e l'international Electrotechnical Commission (IEC) sulla sicurezza informatica nel tentativo di fornire un riferimento in materia e stabilire una pratica riconosciuta e certificabile [ISO27K] ISO Questo standard fa parte della serie riguardo l'information Security Management System (ISMS) ed è quello per le quali le imprese possono ottenere Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 17

18 Requisiti legali e standard la certificazione ufficiale. Esso è l'evoluzione ed il rimpiazzo della seconda sezione del British Standard 7799 e si appoggia agli altri standard della serie per i dettagli e le pratiche di implementazione, limitandosi a definire gli aspetti generali ed il processo di verifica per la certificazione. L'ISMS, ovvero il sistema di gestione della sicurezza delle informazioni, individua un livello più in alto dei sistemi informatici, al quale sono attivati i processi che devono garantire la sicurezza del sistema informativo, il cui risultato consiste in azioni volte a proteggerlo ISO Al momento è lo standard più importante della serie di cui fa parte ed è intitolato Information technology Security techniques Code of practice for information security management, ovvero Informatica Tecniche di sicurezza Pratiche per la gestione della sicurezza informatica. Esso è semplicemente la rinumerazione, fatta a luglio 2007 per l'inclusione nella serie sulla sicurezza informatica, di uno standard esistente, l'iso del 2005, il quale era a sua volta il recepimento dell'iso della sezione 1 del British Standard 7799, datato Questo standard contiene precise indicazioni per l'isms, individuando 36 obiettivi di controllo e 133 controlli specifici. Gli obiettivi riguardano queste tematiche: organizzazione della sicurezza, ovvero infrastruttura di sicurezza, supporto del management, outsourcing e accesso di terze parti; classificazione e controllo dei beni: inventario dell'hardware e classificazione delle informazioni; Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 18

19 Requisiti legali e standard sicurezza per il personale, che copre procedure di risposta a problemi di sicurezza, addestramento del personale, definizione di mansioni e responsabilità; Sicurezza fisica ed ambientale, riguardante la protezione da manomissioni e danni di sistemi e cavi, il mantenimento di aree sicure; Gestione di comunicazioni e operazioni, definisce politiche di scambio di informazioni, procedure di backup, segregazione degli ambienti e separazione dei compiti. Controllo degli accessi, che interessa la gestione degli account, l'accesso a livello di applicazioni e sistemi operati, dalla rete e dispositivi mobili; Sviluppo e mantenimento dei sitemi: requisiti di sicurezza di sistemi ed applicazioni, sicurezza dei file, controlli crittografici, processi di sviluppo e testing. Conformità, relativamente a questo ed altri standard o norme legali. Gli obiettivi individuati hanno spesso carattere generale e, sebbene molti abbiano impatto sulla sicurezza intranet, non sono specificatamente pensati per ambienti ad alto rischio operativo. 3.2 Sarbanes Oxley Act Il Sarbanes Oxley Act è una legge federale degli Stati Uniti emanata nel E' conosciuta anche come Public Company Accounting Reform and Investor Protection Act, titolo che indica come i suoi obiettivi siano quelli di riformare la contabilità delle public company, ovvero le aziende quotate in borsa, e proteggere gli investitori. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 19

20 Requisiti legali e standard Sviluppi storici Fra il 2001 ed il 2002 si sono consumati episodi particolarmente gravi di cattiva amministrazione e scandali finanziari e contabili in aziende particolarmente grandi ed in vista, che hanno coinvolto anche banche e revisori dei conti. Prima tra questi è lo scandalo Enron [ENRON], seguito da quello WorldCom [WCOM]. In entrambi i casi c'è stata una vera frode perpetrata dal top management delle compagnie, volta a mantenere alto il valore delle azioni e presentare uno stato di salute finanziaria molto diverso da quello reale. Alla base c'è stato un management disonesto, con un forte interesse nel valore corrente delle azioni della società, per via di azioni o stock option possedute, insieme ad un sistema contabile viziato. Infatti in tali società vigevano dei meccanismi contabili complicati per fare sparire i debiti e fare apparire dei costi di esercizio tra le attività patrimoniali, all'insaputa o con il benestare dei rispettivi revisori. Quei crack finanziari hanno avuto costi tremendi per gli investitori, soprattutto i piccoli, alcuni dei quali anche dipendenti stessi delle compagnie. Questi eventi hanno minato la fiducia degli investitori e causato una diminuzione degli investimenti in borsa, facendo sì che ne soffrisse l'intero sistema. Dovendo agire rapidamente il Presidente degli Stati Uniti George W. Bush ha presentato una proposta d'azione rimasta conosciuta come ten point plan, contenente fondamentalmente un inasprimento delle pene per il falso in bilancio, una maggiore responsabilità personale del management, maggiori poteri e fondi agli organi di vigilanza, lasciando fondamentalmente intatto l'apparato normativo esistente. Il senato ha percepito tali misure come insufficienti per risolvere il problema, ed i senatori Sarbanes e Oxley si sono attivati per presentare rapidamente una loro Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 20

21 Requisiti legali e standard proposta di legge. Le loro due proposte congiunte hanno dato origine al decreto Sarbanes Oxley, rapidamente emanato dal Presidente Il contenuto legislativo Il decreto prevede una serie di modifiche alla precedente normativa relativa alle società quotate ed ai revisori contabili, tra cui le principali sono: la creazione di un organismo indipendente dedicato al controllo delle società di revisione; responsabilità del top management della veridicità dei bilanci e relative relazioni; aggravamento delle sanzioni in caso di frode nei confronti degli investitori; aumento dei finanziamenti alla SEC Security Exchange Commission, l'organo di controllo della borsa; maggiore trasparenza riguardo a situazioni che possano influire sul futuro della società, ma non rientrino nel bilancio; divieti di prestiti ai membri interni alla società e rigorosa regolamentazione delle operazioni in titoli effettuate da essi; istituzione di comitati composti da amministratori indipendenti e regole per assicurare l'indipendenza delle società di revisione; La sezione 404 La sezione 404 di SOX concerne l'istituzione di un sistema di controllo interno atto a garantire la correttezza e la completezza del processo di reporting Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 21

22 Requisiti legali e standard finanziario, che il revisore è tenuto a verificare annualmente. Si presuppone inoltre che tali controlli siano basati su un certo insieme di regole e pratiche, definito come framework, più ampiamente riconosciuto. L'uso di un framework facilita l'implementazione e la completezza dei controlli, nonché evita soluzioni arbitrarie portate avanti nelle singole aziende, che un revisore difficilmente riuscirebbe a valutare integralmente e obbiettivamente I framework Due framework sono riconosciuti quello del CoSO (Committee of Sponsoring Organizations of the Treadway Commission) e il COBIT (Control Objectives for Information and related Technology). Il CoSO è una iniziativa finanziata privatamente e sponsorizzata dalle maggiori associazioni ed istituti di contabilità americani. Il framework creato da CoSO si occupa di controlli interni, oltre che di enterprise risk management [COSO]. Tali controlli interni sono formati da cinque componenti in relazione tra loro: Ambiente di controllo: insieme di variabili come valori etici, stile di leadership e delega, che influenzano la consapevolezza dell'elemento di controllo sulle persone che lo compongono. Stima dei rischi: include l'identificazione e la stima dei rischi a cui si è soggetti nel raggiungere gli obiettivi. Attività di controllo: le politiche e le procedure che il management ha a disposizione per sincerarsi che le sue direttive vengano eseguite. Include approvazioni e autorizzazioni, resoconto di rendimento, strumenti di sicurezza, separazione dei compiti. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 22

23 Requisiti legali e standard Informazione e comunicazione: una comunicazione efficace e la diffusione dell'informazione tra i reparti sono elementi chiave dei sistemi di controllo interni. Monitoraggio: i sistemi di controllo vanno monitorati e valutati, in modo da correggerne le mancanze. Il COBIT è invece una raccolta di obiettivi e relative pratiche creata e mantenuta dall'information Systems Audit and Control Association [ISACA]. Nato nel 1992 e successivamente aggiornato diverse volte, esso riguarda l'it governance, ovvero l'amministrazione del reparto IT e dei rispettivi rischi. E' in molti aspetti simile agli standard ISO della serie Entrambi i framework hanno chiaramente un certo impatto, oltre sulle persone e le procedure di governo dell'impresa, sulla configurazione dei sistemi informatici. 3.3 Altri standard e best pratices notevoli Vale la pena dedicare qualche riga anche ad altri standard e legislazioni che possono influire sulle politiche di sicurezza, specialmente per ambienti ad alto rischio operativo. Tra di essi vi sono PCI DSS, HIPAA ed lo Standard of Good Practice di Information Security Forum PCI DSS PCI DSS, ovvero Payment Card Industry Data Security Standard, è indirizzato a compagnie operanti nel settore dei pagamenti digitali ed è stato sviluppato dai principali gestori di carte di credito, tra cui VISA, Master Card e American Express. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 23

24 Requisiti legali e standard Esso individua dodici requisiti di sicurezza informatica per compagnie che vogliano fare business con questi grandi nomi e altri HIPAA L'Health Insurance Portability and Accountability Act, è una legge americana del 1996 a proposito di sanità ed assicurazioni mediche. Tra le altre cose, stabilisce dei requisiti di riservatezza delle informazioni sanitarie con conseguenze per il sistema informativo delle aziende operanti nel settore, che devono implementare e poter dimostrare un efficace controllo e registrazione degli accessi a tali dati Standard of Good Practice Lo Standard of Good Practice è un documento molto accreditato, redatto da Information Security Forum, con l'intento di raggruppare le migliori pratiche di sicurezza informatica per le aziende, anche nell'ottica di semplificare in futuro un eventuale processo certificazione IS o utilizzo di COBIT per la conformità a SOX. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 24

25 Insider threat, minacce dall'interno 4 Insider threat, minacce dall'interno Si vedrà nelle prossime pagine come sul fronte interno della rete aziendale si siano intensificati il numero e la pericolosità degli attacchi informatici. Si analizzeranno le caratteristiche di questo fenomeno, sui piani economico, umano e tecnico, per concludere come esso sia al momento non sufficientemente riconosciuto, ma rappresenti la sfida della sicurezza informatica dei prossimi anni. 4.1 Caratteristiche del fenomeno Parlando di minacce per il sistema informativo il pensiero cade innanzitutto sugli attacchi e gli accessi non autorizzati che possono originarsi da Internet o comunque dall'esterno della rete aziendale. Qualora si voglia invece concentrarsi su qualcosa che possa danneggiare la rete dall'interno si pensa più facilmente ai virus, trojan horse ed altri malware che possono finire sui pc e sui server aziendali, ma si tratta comunque di minacce che nascono e provengono dal di fuori. In linea di massima i prodotti software per la sicurezza, si sono concentrati sino ad oggi a difendere i sistemi da attacchi ed attaccanti all'esterno di un certo perimetro, che racchiude e separa la rete interna dell'azienda dall'internet. Questa tendenza è stata indubbiamente motivata dalla necessità di difendersi da una rete esterna, sulla quale non si può avere un controllo diretto, che ospita la grandissima parte di potenziali attaccanti dei propri sistemi. Negli ultimi anni le aziende si sono dotate di potenti firewall per filtrare il traffico di rete diretto ai propri sistemi interni e si sono inoltre preoccupate che i servizi esposti ad Internet fossero sicuri e separati, rendendo così la rete interna un ambiente protetto in cui un attaccante sarebbe penetrato difficilmente. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 25

26 Insider threat, minacce dall'interno Grazie alla protezione di cui gode, la rete aziendale adotta misure di sicurezza che sono di molto inferiori di quelle dispiegate verso il resto del mondo e debolezze, come password che transitano in chiaro o politiche di accesso basate sull'indirizzo di rete, sono considerate in molti casi ammissibili, non giudicando che valesse la pena di sostenere il costo di misure più efficaci. Sebbene questa strategia abbia sicuramente combattuto il problema più immediato degli attacchi esterni, il patrimonio informativo dell'impresa è stato lasciato poco protetto da un attaccante che si trovi all'interno. Con il crescere dell'infrastruttura IT, sia per dimensioni che per importanza e delicatezza dei dati trattati, il rischio legato ad attacchi informatici è aumentato parecchio, ma mentre le difese hanno contenuto la crescita del rischio legato a minacce esterne, la pericolosità e la probabilità di minacce sfruttanti una vulnerabilità interna alla rete sono aumentate più delle rispettive contromisure. Queste minacce interne o più precisamente minacce originanti da chi è all'interno, come meglio rende il termine inglese insider threat, sono sempre esistite e non sono per nulla vincolate al sistema informativo. Per definizione l'insider threat consiste nella possibilità che un utente legittimo abusi della fiducia che gli è stata accordata. Un tale abuso può avvenire in maniera volontaria, quando l'intento è quello di frode, spionaggio industriale, ricatto o vendetta nei confronti dell'organizzazione, oppure può generarsi da un semplice errore umano, commesso da un dipendente in buona fede. Questa definizione generale pone l'accento sugli aspetti più umani della questione, il che suggerisce che una difesa a questo livello fortunatamente sia possibile. Infatti per un dipendente che voglia commettere degli atti tali da danneggiare l'impresa per cui lavora, eventualmente traendone un profitto, c'è il grosso Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 26

27 Insider threat, minacce dall'interno deterrente rappresentato dal licenziamento ed eventualmente dalla persecuzione a norma di legge. Esso costituisce una forte linea di difesa per l'organizzazione quando le probabilità che un atto di questo tipo sia individuato rapidamente e ricondotto alla persona che l'ha perpetrato sono molto alte. Questo tipo di minacce ha tuttavia una rilevanza molto più ampia quando è collegata al sistema informativo computerizzato dell'azienda, in quanto ciò ne aumenta sia il fattore di danno potenziale, per via della rilevanza di questo componente all'interno dell'impresa, sia quello della probabilità di manifestarsi. Infatti in primo luogo è molto più facile occultare o falsificare la propria identità sulla rete informatica, che nel mondo reale, ed un attacco attraverso i sistemi informatici richiede sicuramente meno spostamenti o interazione con persone fisiche che si potrebbero insospettire, pertanto il rischio di venire scoperti è in linea di massima molto minore e, di conseguenza, anche l'effetto deterrente di possibili sviluppi negativi è molto più debole. In secondo luogo le minacce interne trovano terreno fertile nelle politiche permissive delle reti locali delle aziende, dove spesso sono aiutate da password deboli e utenti impreparati. Infine è possibile che, per la natura ormai pervasiva del supporto informatico, informazioni e sistemi vitali al funzionamento dell'impresa siano posti sotto il controllo dei calcolatori e quindi che tecnici e utenti con un certo livello di accesso a tali sistemi abbiano un potere di danneggiare l'azienda superiore addirittura a quello di manager di medio livello. Per tali motivi il rischio legato al sistema informatico posto da minacce interne è cresciuto geometricamente, diventando oggi una componente fondamentalmente nuova ed anche relativamente trascurata per numerose organizzazioni. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 27

28 Insider threat, minacce dall'interno 4.2 Dimensioni L'annuale studio CSI FBI del 2005 sui crimini informatici riconosce che il numero di incidenti originati dall'interno e dall'esterno siano all'incirca pari [CSI FBI]. L'indagine americana sulle frodi del 2006 stima il costo totale di questi attacchi in 400 miliardi di dollari ogni anno, una cifra enorme e molto più alta dei costi di attacchi esterni [NFS]. A livello di singola impresa tale perdita può valere circa il 6% del fatturato. A fronte di tali costi tuttavia oltre l'80% delle organizzazioni dedica meno del 3% del fatturato alla sicurezza dei propri sistemi. In una ricerca del Ponemon Institute [PONEMON], svolta nel 2006 su 461 impiegati nel settore IT di altrettante aziende americane, si sostiene che il costo medio annuale derivante dal solo accesso ed eventuale divulgazione di informazioni riservate sia di circa 3,4 milioni di dollari per organizzazione, mentre l'investimento preventivo raramente supera il milione. Solo 49% degli intervistati ha riconosciuto che l'amministrazione stesse prendendo sul serio questo tipo di minacce, mentre oltre il 90% ha lamentato scarsità di risorse dedicate per le contromisure. Inoltre lo studio fa emergere che oltre il 70% delle aziende riconosce come verosimile l'aver subito almeno una breccia nei propri dati sensibili che non è stata riportata o riscontrata, dunque il fenomeno potrebbe non essere stato valutato completamente ed essere parecchio più significativo nel suo complesso. 4.3 Alcuni esempi Le insider threat non sono però solamente limitate alle fughe di dati, ma includono anche ricatti, frodi o sabotaggi nei confronti dell'azienda. Eventi di Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 28

29 Insider threat, minacce dall'interno questo tipo non sono rari come può sembrare in principio ed è possibile trovarne numerose testimonianze. Anche questo evento è però difficilmente osservabile nella sua completezza e si può supporre che sia più esteso di quanto appare, in quanto è verosimile che numerosi incidenti vengano gestiti in un totale silenzio verso l'esterno dalle relative organizzazioni. Per dare un'idea della tipologia di questi eventi si vogliono citare alcuni casi realmente accaduti: Una professionista responsabile dei sistemi informativi di una struttura militare scopre di essere considerata in esubero. Decide di crittografare considerevoli parti del database dell'organizzazione e tenerle in ostaggio. In seguito contatta l'amministratore e richiede dollari a titolo di liquidazione e la promessa di non intraprendere ulteriori azioni nei suoi confronti in cambio della chiave dei dati. L'offerta viene accettata prima di contattare le autorità e viene ad essere un impedimento alla formulazione di accuse giudiziarie[shaw]. Un ingegnere in uno stabilimento energetico è frustrato con il suo nuovo supervisore privo di competenza tecnica. Sta avendo un periodo difficile anche nella vita privata, con la moglie gravemente malata, e dopo un periodo di verifica, in seguito ad episodi di collera sul posto di lavoro, viene licenziato. Qualche tempo dopo si scopre che aveva attuato sostanziali modifiche ai sistemi di controllo e sicurezza dell'impianto e quando gliene viene chiesto conto si rifiuta di fornire le password, minacciando la produttività e la sicurezza dello stabilimento [SHAW]. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 29

30 Insider threat, minacce dall'interno Un intermediatore finanziario trucca i dati relativi alle proprie transazioni e maschera una performance mediocre con una eccellente. Dopo alcuni anni egli gode ormai della massima reputazione tra gli intermediari del suo settore e quando la società comincia a riscontrare le prime incongruenze è uno degli ultimi ad essere sospettato. Egli inoltre si offende moltissimo e minaccia il licenziamento, così le indagini deviano e altro tempo intercorre prima che l'azienda sia certa che fosse lui il vero responsabile delle incongruenze. Il danno totale ammonta a 791 milioni di dollari. Quando gli viene chiesto, in una intervista in carcere, come avesse potuto occultare così a lungo una tale discrepanza e ingannare tanto bene la società sulle sue performance egli risponde che era stato facile, in quanto era anche il programmatore della relativa applicazione [CERT 2]. 4.4 Componente umana del fenomeno Elemento comune di questi eventi è certamente il fattore umano, specie la mancanza di soddisfazione personale o lealtà verso l'organizzazione. Non a caso tra i principali responsabili delle fughe di informazione individuati dal Ponemon Insititute vi sono in ordine di rilevanza: impiegati negligenti o demotivati, impiegati temporanei, impiegati insoddisfatti ed ex impiegati. Come il problema si origina dalle persone, così ci sono mezzi per prevenirlo a quel livello, come i controlli del background del personale, un ambiente lavorativo piacevole e un trattamento corretto, che stimolino un naturale senso di lealtà verso l'azienda ad albergare tra i dipendenti. Benché alcuni considerino solamente l'aspetto umano e psicologico del fenomeno, Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 30

31 Insider threat, minacce dall'interno proponendo delle linee guida per combatterlo su quel terreno, è facile capire che con il passare del tempo e la progressiva crescita di importanza dei sistemi informativi, non si può lasciare il sistema poco protetto e basarsi solamente sulla fiducia nelle persone che lo usano e lo amministrano. Per quanto degne di considerazione dal punto di vista del buon funzionamento dell'azienda, questo ci sembra un problema che non può essere eliminato alla radice e che va quindi affrontato a livello informatico. E' dunque sicuramente più efficace cercare di far sì che il sistema informativo non ammetta le azioni che possano danneggiare l'organizzazione, o quanto meno allerti immediatamente chi di dovere, piuttosto che stabilire un profilo dell'attaccante tipico. In aggiunta questa è l'unica strada per ridurre il rischio operativo, adempiere a certi obblighi di legge e conformarsi rispetto agli standard di sicurezza. La componente umana va comunque tenuta presente perché può fornire un valido aiuto a individuare le situazioni a rischio e gli attacchi sul nascere. Gli utenti privilegiati Per utente privilegiato si intende un utente che abbia accesso e controllo illimitato su un certo componente dell'infrastruttura IT. Ad un utente privilegiato corrisponde un account privilegiato su un sistema operativo, su un database o su una applicazione interna. Mentre le fughe di informazione sono in gran parte originate da impiegati con il ruolo di utenti comuni del sistema informativo, eventi più gravi, come quelli d'esempio, hanno quasi sempre origine da utenti privilegiati, come amministratori di sistemi, di database e sviluppatori. Tale categoria di utenti è tanto indispensabile quanto pericolosa. Al giorno d'oggi nessun sistema informatico nega il controllo totale da parte dell'uomo e anzi tutti Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 31

32 Insider threat, minacce dall'interno necessitano di una figura particolare, un account a cui viene garantito ogni privilegio di utilizzo. Questo ruolo è richiesto soprattutto per configurare inizialmente il sistema, per risolverne i problemi o farne manutenzione e fortunatamente è spesso inutile nel funzionamento quotidiano. E' bene notare che quando una macchina è sotto il controllo dell'utente privilegiato essa può essere plasmata a suo totale piacimento, nei soli limiti delle sue competenze. Un utente con accesso amministrativo può facilmente leggere dati privati, modificare i sistemi di autenticazione ed ottenere le password di altri utenti o impersonarli direttamente, cancellare le proprie tracce e forgiare eventi fittizi nei log della macchina, catturare il traffico di rete e crearne di arbitrario, portando avanti degli attacchi ad altre macchine, eccetera. Il potere derivante da un accesso illimitato è tale da poter asserire che la fiducia che si può riporre in un sistema è sempre al massimo pari a quella che si può porre nel suo amministratore Ruolo degli utenti privilegiati nell'insider threats Il Computer Emergency Response Team individua questa categoria come fonte del 87% di tutti gli attacchi interni, sebbene costituisca meno del 5% del totale tra gli utenti [CERT-1]. Gli account privilegiati presentano una sfida particolarmente interessante, poiché risulta auspicabile includere anch'essi nelle politiche di sicurezza dell'organizzazione, ma è pressoché impossibile contenere efficacemente il loro accesso, in quanto essi stessi possono decidere di disabilitare ogni eventuale protezione che li ostacoli. Gli utenti privilegiati sono inoltre quelli dotati delle più elevate capacità tecniche Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 32

33 Insider threat, minacce dall'interno e conoscenze della rete aziendale, perciò è presumibile che sappiano sfruttare al meglio il loro accesso. Questo ci porta a pensare che un sistema informativo non possa difendersi autonomamente da una simile minaccia, ma che possa al limite cooperare e sia richiesta una certa attenzione umana. L'oggetto di tale attenzione sono chiaramente le azioni degli amministratori, che quindi devono essere il più possibile tenute sotto controllo, in modo che una eventuale anomalia dia subito l'allarme e un intervento sia intrapreso il più in fretta possibile. Stabilito che le azioni compiute dagli amministratori sono di grande rilevanza sorge il problema del come monitorarle efficacemente, in quanto senza misure specifiche gli utenti privilegiati possono facilmente nascondere le loro stesse azioni. Si vedranno in seguito alcune best practices volte a contenere il problema. 4.5 Tipi di insider threat Il CERT è l'organizzazione che ha trattato il problema dell'insider threat più da vicino sino ad oggi, arrivando a proporre una classificazione e alcuni schemi degli attacchi al sistema informatico dall'interno. Si individuano tre macro categorie di cui gli attacchi possono far parte: sabotaggio informatico dall'interno (insider IT sabotage), frode e furto di informazioni riservate o proprietarie. La gran parte degli attacchi cade in una sola di queste categorie, ma non è escluso che un attacco possa comprendere elementi di più di una. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 33

34 Insider threat, minacce dall'interno La prossima immagine riassume proporzioni ed intersezioni delle tre tipologie: Illustrazione 1: Tipi e proporzioni di insider threat Frode Cadono in questa categoria gli attacchi che vedono un impiegato, presente o passato, o un fornitore di un servizio abusare intenzionalmente del proprio livello di autorizzazione ai sistemi e alle reti aziendali con l'obiettivo di ottenere immeritatamente proprietà, servizi o benefici tramite l'inganno e la manipolazione. Il principale danno per l'azienda è in questo caso una perdita economica. Alcune note d'interesse per questo tipo di casi sono: la quasi totalità degli attaccanti aveva un accesso legittimo al tempo dell'attacco ed i due terzi ha usato il proprio account per portare l'attacco; Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 34

35 Insider threat, minacce dall'interno la gran parte degli utenti aveva un certo controllo sulle informazioni manipolate, ma non erano tecnici o utenti privilegiati; gli attacchi sono stati individuati principalmente con mezzi non tecnici, come notifiche di problemi da parte di clienti o impiegati, revisori di conti o tutori della legge Furto di informazioni confidenziali o proprietarie In questa categoria rientrano gli attacchi che vedono un dipendente od un fornitore abusare intenzionalmente della propria autorizzazione sui sistemi aziendali con l'obiettivo di portare informazioni riservate o proprietarie fuori dall'organizzazione. Questo tipo di attacco è sicuramente il più diffuso e riconosciuto, rientrando perfettamente nella definizione di spionaggio industriale. E' probabilmente l'attacco meno dannoso per l'impresa, ma anche il meno scoperto e riportato. La motivazione alla base è fondamentalmente la vendita delle informazioni ad un concorrente, il quale spesso assume anche l'impiegato. Non sono richieste forti competenze tecniche qualora i dati riservati siano accessibili durante il lavoro ordinario. Ecco alcuni punti salienti di questo caso: gran parte degli attaccanti ha commesso il furto quando dipendente dell'impresa, ma quasi la metà aveva già un accordo con un nuovo datore di lavoro; nel 75% dei casi il proprio account è stato usato per rubare le informazioni; in molti casi i log di sistema o delle sono state la chiave per identificare l'attaccante. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 35

36 Insider threat, minacce dall'interno Un esempio di furto di informazioni abbastanza celebre si è avuto di recente (2007) con la storia di spionaggio industriale tra i team di Formula 1 McLaren e Ferrari, nella quale la prima era in possesso di documenti confidenziali della seconda e la ricostruzione di uno scambio di tra un membro della Ferrari e il capo progettista della McLaren ne ha chiarito la provenienza. L'informatica non può proteggere molto contro questi furti, qualora siano perpetrati da un utente con accesso legittimo per quei dati. La migliore soluzione è quella di limitare il più possibile l'esposizione al problema, accertando la fiducia e limitando il numero delle persone che lavorano su informazioni di valore, stipulando con esse accordi di riservatezza e non concorrenza. Per casi estremi si possono predisporre ambienti fisicamente sicuri, sconnessi dalla rete e privi di supporti di memorizzazione rimovibili, ma tali eventualità esulano dal perimetro di interesse di questa relazione. In alcuni casi il furto di informazioni è stato utilizzato come base per una frode, cadendo quindi in due categorie ed ereditando gran parte degli elementi della frode Sabotaggio informatico dall'interno Cadono in questa categoria gli attacchi che vedono un impiegato, collaboratore o ex dipendente usare intenzionalmente il proprio livello di autorizzazione sulla rete aziendale con l'obiettivo di danneggiare l'organizzazione o un individuo al suo interno [CERT 2]. Le conseguenze negative per la compagnia sono svariate: si va dalla pubblicità negativa, alla perdita di informazioni, alla paralisi della produzione o di altri settori. In certi casi le conseguenze negative sono ravvisabili da un solo individuo e in possono variare da mancati avanzamenti di carriera al licenziamento. Si Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 36

37 Insider threat, minacce dall'interno riporta come esempio per questa seconda modalità il caso di un amministratore di sistema, scontento del proprio supervisore, che ha scaricato una logic bomb1 dalla rete, quindi modificato i log per far sì che il suo supervisore fosse implicato. Avendo egli segnalato la cosa a livelli più alti il supervisore fu licenziato. Tra i vari attacchi è sicuramente il più tecnico e difficile da perpetrare. Alcune caratteristiche principali sono: Fondamentalmente ognuno degli attaccanti aveva manifestato sentimenti personali negativi riguardo all'azienda o ad un superiore. la maggioranza degli attaccanti non aveva un accesso legittimo al momento dell'attacco. Oltre la metà degli accessi veniva effettuata con account compromessi o creati ad hoc, il resto usava per la gran parte credenziali di altri impiegati o backdoor2. Accessi con account di amministrazione o condivisi costituiscono più di un decimo del totale; oltre un terzo degli attacchi ha richiesto tecniche avanzate, come l'installazione di rootkit3, la scrittura di programmi e script od il cracking delle password; un quarto degli attacchi è avvenuto dopo un periodo di preparazione tecnica e testing di una certa durata. Questo tipo di attacco è quello più strettamente legato alla problematica posta dagli utenti privilegiati. Infatti sabotaggi informatici compiuti da utente normali hanno spesso portata molto ridotta e raramente entrano tra i casi di studio. 1 Software predisposto per danneggiare il sistema dopo un certo periodo di tempo o al verificarsi di un certo evento. 2 Programma per fornire un accesso remoto e nascosto. 3 Insieme di software per nascondere la compromissione dei sistemi, mantenendone il controllo. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 37

38 Insider threat, minacce dall'interno Questo è un attacco informatico di cui ci è resi conto in tempi molto recenti, per il quale esistono pochissime soluzione tecniche e solo alcune trattazioni teoriche Schema del sabotaggio informatico interno Analizzando meglio questo tipo di attacchi si può individuare un certo schema e trarne delle importanti conclusioni. Come si è detto un sentimento negativo verso l'azienda è presente nell'attaccante tipo. Tale sentimento può derivare da svariate situazioni, come promozioni o bonus mancati, pericolo di perdita del posto di lavoro, incomprensioni con i superiori e altre, ma fa sì che l'impiegato possa avere un desiderio di vendetta nei confronti della compagnia o voglia ricattarla per ottenere un beneficio che crede di meritare. Per decidere di intraprendere un'azione di sabotaggio sono di solito necessari periodi lunghi, nel quale questi sentimenti negativi vengono solitamente espressi nel comportamento o nella performance lavorativa. Litigi, demotivazione, ritardi al lavoro, lamentele o dichiarazioni accusatorie e minacce sono elementi ricorrenti nei casi di sabotaggio informatico e costituiscono il campanello di allarme di un possibile attacco. In questa fase nessuna risoluzione è stata presa dal potenziale attaccante ed un intervento del management che eliminasse lo scontento potrebbe evitare del tutto l'attacco. Ciò nondimeno a questo punto è prudente iniziare il monitoraggio tecnico delle azioni di tale impiegato, specie se dotato di un account con particolari privilegi. Un'organizzazione che in questa fase non abbia già adottato le giuste pratiche di difesa, sarà priva sia di efficaci contromisure, sia di mezzi per monitorare l'utente. Nel momento in cui la decisione di effettuare un attacco di sabotaggio viene presa comincia la fase di pianificazione e preparazione. Avendo attivato un processo di monitoraggio dell'utente lo si potrebbe vedere raccogliere informazioni o Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 38

39 Insider threat, minacce dall'interno preparare un percorso di accesso sconosciuto ai sistemi, attraverso un account, una backdoor o lo sfruttamento di una falla di programmazione o configurazione. Se non ci accorge di questa fase ci si troverà inevitabilmente esposti e una volta che il percorso di accesso sia attivo l'attacco colpirà come un fulmine a ciel sereno. La prevenzione di questi attacchi può essere molte semplice, come il cambiare delle password o disabilitare degli account, e questo pone l'accento sulla necessità di individuare eventuali attacchi nella fase di preparazione Il licenziamento di un amministratore di sistema Il licenziamento di un amministratore di sistema è un'operazione molto delicata per questi due motivi: 1. il licenziamento potrebbe facilmente costituire la causa scatenante del desiderio di vendetta e della decisione di sabotaggio e, non lavorando più per la società, nessuno si potrebbe accorgere di questi sentimenti ed intenzioni; 2. l'amministratore ha verosimilmente già le informazioni che gli servono per portare a compimento l'attacco. In questo scenario l'attacco potrebbe arrivare senza ulteriori campanelli d'allarme a livello comportamentale o tecnico, qualora non si provveda il più rapidamente possibile a chiudere tutti i percorsi di accesso dell'ex amministratore. E' inoltre importante avere attivi dei meccanismi per essere sufficientemente sicuri che l'amministratore non si sia procurato altri percorsi d'accesso durante il suo periodo di normale impiego. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 39

40 Insider threat, minacce dall'interno 4.6 Considerazioni Il fenomeno dell'insider threat è dunque una sfida aperta per la sicurezza informatica. Esso pone dei problemi tecnici considerevoli, come la questione degli utenti privilegiati, e include una componente umana, gettando una nuova prospettiva sulla sicurezza IT che include anche gli utenti come parte del sistema da proteggere. Giudicando dalle cifre che lo riguardano è ipotizzabile che stia nascendo un mercato di una certa dimensione per chi si occupa di sicurezza e che questo porti nuovi e migliori strumenti per difendersi. Un principio di questo si può già riscontrare oggi, ma è lecito pensare che l'insider threat possa essere tra i tema più attuali per l'industria della sicurezza informatica nei prossimi anni. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 40

41 Best practices per la sicurezza intranet 5 Best practices per la sicurezza intranet In questo capitolo si affronteranno, alla luce di quanto detto sulle minacce interne, le diverse pratiche adottabili per la sicurezza intranet, cominciando da principi generali per proseguire con indicazioni più dettagliate raggruppate per tematica. 5.1 Introduzione Avendo visto come sulla rete aziendale gravi una cospicua parte del rischio operativo e esaminato come gli attacchi originanti dall'interno della rete sono numerosi e pericolosi, si deve ora passare a cercare delle contromisure. In ambienti definibili ad alto rischio operativo la rete aziendale ha meritatamente dei requisiti di sicurezza molto alti e non si può pensare di difenderne solo il perimetro da attacchi esterni, ma si deve dedicare altrettanta attenzione alla sicurezza intranet. Adottare misure di sicurezza più stringenti ha spessissimo conseguenze negative sulla facilità di utilizzo dei sistemi e può impattare negativamente sulla produttività, così come far aumentare i costi. Tuttavia, come si è riportato, i danni derivanti da attacchi dall'interno possono erodere anche il 6% del fatturato e le imprese stanno oggi investendo relativamente poco per difendersi, perciò un impegno maggiore potrebbe essere spesso giustificabile. Attuare adeguate contromisure può richiedere cambiamenti significativi ed un certo periodo di tempo, ma è comunque necessario che siano attive al tempo di un pericolo specifico per poterlo controllare e dopo un incidente ci potrebbe volere ancora più lavoro per ripristinare la sicurezza della rete. Occuparsi della sicurezza intranet dunque dovrebbe essere un'attività da non rimandare troppo a lungo. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 41

42 Best practices per la sicurezza intranet I riferimenti della sicurezza informatica, come gli standard ISO della serie 27000, il COBIT o lo Standard of Good Practice, non sono ancora sufficientemente coscienti del fenomeno dell'insider threat. Il CERT, vero pioniere di questo campo, arriva a proporre una serie di linee guida per difendersene con il buon senso [CERT 3], ma delle vere pratiche attuabili e riconosciute al riguardo non sono ancora entrate a far parte del panorama della sicurezza informatica. Si cercherà nei prossimi paragrafi di raggruppare e individuare le best practices per la sicurezza lato intranet, analizzando nel frattempo le problematiche implementative e reali del prevenire attacchi da utenti legittimi o addirittura amministratori di sistemi e applicazioni Una prospettiva sulla rete La rete aziendale è fisicamente un insieme di computer, server, router, switch ed altri hardware interconnessi tra loro. Su questo supporto hardware l'azienda ha interesse a far funzionare le proprie applicazioni e conservare i propri dati. Per fare ciò computer, server e tutto il resto sono dotati di sistemi operativi, programmi di supporto e configurazioni particolari. Si possono dunque individuare due livelli: quello delle applicazioni e quello del sistemi, costituito dagli ambienti software in cui tali applicazioni sono eseguite. L'hardware vero e proprio viene lasciato fuori da questa semplificazione, in quanto la sicurezza fisica dell'hardware e dei cablaggi rappresenta una tematica diversa e ampiamente trattata separatamente, anch'essa fondamentale alla sicurezza globale della rete aziendale. Oltre a sistemi e applicazioni è necessario includere nello scenario anche gli utenti della rete aziendale. Essi sono anzi una componente centrale e preponderante: sono gli utilizzatori e gli sviluppatori delle applicazioni così come gli Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 42

43 Best practices per la sicurezza intranet amministratori dei sistemi Inoltre, poiché si sta considerando solamente la sicurezza intranet, gli utenti sono anche la fonte delle minacce alla sicurezza di applicazioni e sistemi. Illustrazione 2: Aree della sicurezza intranet Questo modello della rete aziendale, formato da applicazioni, sistemi e utenti, è utilizzabile per separare le diverse zone di attenzione per la sicurezza della rete. Banalmente si individuano due aree relative alla sicurezza delle applicazioni ed alla sicurezza dei sistemi. Una terza area si individua relativamente all'utenza e va sotto il nome gestione dell'identità digitale, comprendente l'assegnazione degli account, la distribuzione dei privilegi e le politiche sulle password. Infine merita dedicare un'ultima area di attenzione all'interazione degli utenti con applicazioni e sistemi, il cui oggetto sia la verifica della correttezza delle operazioni degli utenti ed il monitoraggio delle modifiche a dati e sistemi, attraverso un insieme di controlli e attività di revisione, indicabili come auditing del sistema informatico. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 43

44 Best practices per la sicurezza intranet La trattazione delle best practices comincerà da questioni di carattere generale sulla gestione della sicurezza informatica, per poi procedere attraverso le quattro aree individuate. 5.2 Pratiche generali Principi di sicurezza e rete interna Proteggersi da minacce originanti all'interno della rete, richiede innanzitutto di abbandonare il paradigma di difesa del solo perimetro. L'approccio comune è quello di separare e proteggere con potenti filtri la rete locale dall'internet e, nel caso sia necessario offrire dei servizi sulla rete pubblica, predisporre una DeMilitarized Zone (DMZ), in una porzione della rete locale distinta dal resto della rete interna. Nella DMZ i singoli server sono molto protetti ed il traffico di rete verso il resto della rete locale viene ristretto allo stesso modo di quello con origine da internet. In molti ambienti è comune ritenere la difesa da minacce esterne necessaria, adottando la soluzione firewall e DMZ, e quella della rete interna superflua, sgradita agli utenti e negativa per la produttività. Questo è il paradigma da cambiare di fronte alle statistiche precedentemente citate, che dimostrano come gli attacchi interni siano ormai dannosi come quelli esterni. Adottando un approccio che non ignora la sicurezza neanche a livello intranet, si possono estendere i principi comuni di sicurezza a tale area. Alcuni di tali principi possono essere: ridondanza, ovvero avere più strati di sicurezza in caso che uno di essi sia oltrepassato o disabilitato; Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 44

45 Best practices per la sicurezza intranet globalità: la resistenza delle misure di sicurezza è simile a quella di una catena, cioè pari a quella dell'anello più debole, pertanto va trattata a livello globale; minimo privilegio, che indica come ogni soggetto di un sistema informatico dovrebbe poter accedere all'insieme minimo di oggetti che gli necessitano; unico punto di contatto, ovvero far sì che la sicurezza del sistema dipenda da pochi punti controllabili; modularità: preferire oggetti piccoli e semplici da controllare; semplicità, poiché la complessità è più difficile da gestire ed analizzare, dunque un sistema complesso è maggiormente prono a presentare difetti che potrebbero costituire vulnerabilità. In particolare due principi generali acquistano maggiore rilevanza nella sicurezza intranet, essi sono: principio della politica di sicurezza ben definita, ovvero passare da un approccio dove quello che non è espressamente proibito è permesso, ad uno dove quello che non è esplicitamente permesso è vietato. Questa politica detta anche come di default deny è raramente applicata all'interno della rete interna perché richiede una politica ben articolata e definita per garantire una buona utilizzabilità dei sistemi. principio di Kerckhoffs, mutuato dalla crittografia ed applicabile generalmente, esso afferma che un sistema deve essere sicuro anche quando tutti i dettagli implementativi sono noti, ad eccezioni delle chiavi [KERKH]. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 45

46 Best practices per la sicurezza intranet Shannon ha rielaborato questo in una massima, che recita il nemico conosce il sistema, in pieno contrasto con il concetto di security through obscurity, sicurezza attraverso l'oscurità. Questo significa che la segretezza dell'implementazione non è una valida misura di sicurezza e ciò vale maggiormente in ambiente intranet, poiché è facile che attaccanti all'interno della rete siano in possesso di molte informazioni sul sistema, o possano procurarsele facilmente. Stabilito che la sicurezza della rete interna eredita, con al più qualche cambio di prospettiva, i principi comuni della sicurezza, vale la pena ora concentrarsi maggiormente sulle difese specifiche contro le insider threats Risk assessment A livello di ISMS, il risk assessment, ovvero l'attività di stima dei rischi, è un punto cardine. Il sistema informatico contiene informazioni e applicazioni di valore, che costituiscono degli asset, dei beni, di cui l'impresa dispone che vanno individuati e valorizzati come tali. Avendo individuato gli asset relativi al sistema informatico, sono chiari quali siano gli aspetti da proteggere e si può proseguire analizzando le minacce a cui sono esposti. L'attività di risk assessment deve essere effettuata periodicamente riguardo al sistema informatico, perché è il punto di partenza della sua messa in sicurezza. Non si può pensare di proteggere tutto e non avrebbe neanche senso dal punto di vista del rapporto costi/benefici, pertanto individuare che cosa vada protetto è il primo passo. In seguito si può effettuare il risk assessment vero e proprio, acquisendo consapevolezza sulle minacce che insidiano gli asset principali, stimando effettivamente i rischi i termini di danni potenziali e probabilità. Solo conoscendo le minacce da cui ci si deve difendere ci si può efficacemente Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 46

47 Best practices per la sicurezza intranet dedicare alla ricerca delle vulnerabilità e alla messa a punto delle contromisure, infatti il risk assessment è alla base sia dello standard ISO, sia dei framework CoSO e COBIT Quality assurance per il sistema informatico Fare controllo di qualità, o quality assurance, è una pratica diffusa in molte aziende per quello che riguarda la produzione. Costituisce un'innovazione parlarne per il sistema informatico, ma è un'attività che merita di essere estesa ad esso nell'ottica della difesa dalle insider threat. Dovendo assicurarsi che amministratori ed altri utenti privilegiati non facciano modifiche ai sistemi, salvo quelle richieste e approvate, è necessario istituire delle pratiche di controllo, per far sì che la confidenzialità dei sistemi sia la più alta possibile. Ad esempio quando un server per una applicazione critica o un nuovo sistema di autenticazione debbano essere messi in produzione, si può attivare un controllo di qualità, attuato da un amministratore diverso da quello che ha curato il setup, con lo scopo di verificare l'integrità dell'installazione e la completezza delle misure di sicurezza. Sebbene non sia pensabile di controllare esaustivamente i sistemi dopo ogni modifica, questi controlli di qualità costituiscono un incremento della sicurezza, proteggendo da errori ed omissioni, ma anche dalle minacce poste da utenti privilegiati, sia direttamente sia come deterrente. Forzare dei controlli di qualità per il sistema informatico deve pertanto entrare a far parte della gestione dei sistemi informativi in ambienti ad alto rischio operativo. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 47

48 Best practices per la sicurezza intranet Addestramento alla sicurezza informatica per gli utenti Riconoscere la centralità del ruolo degli utenti nella rete aziendale è senza dubbio una buona cosa per chi deve occuparsi della sicurezza. Gli utenti devono essere in possesso di una conoscenza base di quelli che sono i problemi di sicurezza a cui è soggetta la loro rete, per comprendere meglio le conseguenze delle loro azioni ed i motivi di certe regole. Utenti privi inconsapevoli dei pericoli per la sicurezza di un sistema possono rappresentare facilmente il famoso anello debole della catena e commettere errori sfruttabili da un attaccante. Inoltre la pratica del social engineering, o ingegneria sociale, che consiste nello sfruttare una relazione di fiducia per ottenere delle informazioni o altri aiuti per un'attività illecita da un essere umano, trova terreno fertile tra utenti inesperti di problemi di sicurezza [MITNICK]. Diversi casi documentati di attacchi dall'interno comprendevano elementi come l'utilizzo di terminali incustoditi, la condivisione di password e contraffazione di . Infine, con un minino di addestramento, aumentano le probabilità che un'anomalia pericolosa venga individuata e riportata a chi di dovere Documentare i controlli in atto Documentare i controlli di sicurezza è di per sé una pratica necessaria per dimostrare la conformità a SOX o la certificazione ISO 27001, ma si riveste di una nuova funzionalità nei termini di difesa dalle minacce interne. Alla violazione di una politica di sicurezza l'azienda deve poter rispondere in maniera precisa e inequivocabile, specie nei casi in cui si ha a che fare con impiegati in cattiva fede. Per evitare spiacevoli conflitti e inutili violazioni delle misure di sicurezza è opportuno che si documenti bene che cosa è permesso e cosa non lo è, così come le relative conseguenze, possibilmente stabilendo un Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 48

49 Best practices per la sicurezza intranet procedimento con cui gestire i casi di violazione con gli impiegati responsabili. Eventi come elevazioni non autorizzati di privilegi o utilizzo di terminali non approvati possono sembrare relativamente innocue per l'impiegato che le commette, ma sono invece molto pericolose dal punto di vista dell'azienda, così la documentazione delle misure di sicurezza può contribuire a evitare incidenti ed inutili esposizioni a vulnerabilità. Tali documenti devono essere sottoposti agli utenti, in maniera che non vi sia possibilità di disconoscere le regole quando si viene accusati di una violazione, soprattutto nell'eventualità di un'azione legale nei confronti dell'impiegato, in seguito ad un fatto grave. 5.3 Sicurezza delle applicazioni Si è stabilito che l'azienda ha interesse ad usare eseguire le proprie applicazioni e memorizzare i propri dati sulle piattaforme costituite da hardware e software di supporto. Le applicazioni possono essere acquistate come prodotti finiti o sviluppate in maniera personalizzata, internamente all'azienda o da una società specializzata. Nel caso di prodotti finiti non si può fare altro che valutarne la sicurezza, possibilmente a prima dell'acquisto, e curarne l'installazione nella maniera più sicura possibile. Per applicazioni sviluppate ad hoc è invece possibile influenzare ogni fase dello sviluppo ed accedere al codice sorgente per ottenerne e verificarne il livello di sicurezza desiderato Architettura web Nella maggior parte dei casi le applicazioni di un'impresa sono di tipo personalizzato e sono strutturate secondo il paradigma client server con interfaccia web. Sono composte da tre livelli separati: dati, logica e presentazione, Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 49

50 Best practices per la sicurezza intranet quest'ultima effettuata tramite linguaggio HTML renderizzato direttamente sul browser del client. Il livello dei dati è solitamente gestito tramite un database, mentre la logica è costituita da un programma in esecuzione presso un application server. L'architettura web è al momento molto apprezzata per la sua flessibilità ed è la soluzione comunemente adottata per le applicazioni aziendali. Di seguito si vedranno alcune regole per la sicurezza delle applicazioni, in particolare di quelle con architettura web Programmazione sicura Difetti di programmazione possono essere fonte di problemi di sicurezza in molti modi. Lo sviluppo di applicazioni destinate al solo uso interno è stato spesso esonerato dal conformarsi alle norme di programmazione sicura, ma per difendersi dalle insider threat è necessario estenderne l'adozione anche ad esso. L'architettura web in particolare è soggetta a tutta una serie di attacchi specifichi per cui vanno predisposte le relative contromisure. L'OWASP è una iniziativa comunitaria che ha proposto una raccolta ed una classificazione per rilevanza dei pericoli relativi alle applicazioni web [OWASP]. Le più comuni falle in cui può incorrere una applicazione web sono legate a: cross site scripting (XSS), quando dati forniti dall'utente sono ottenuti dall'applicazione e restituiti ai browser dei client senza validazione o codifiche del contenuto, che può contenere degli script; iniezione di codice, in particolare SQL, quando l'input dell'utente diventa senza precisi controlli parte di un comando fornito ad un interprete; esecuzione di file malevoli, nei casi in cui del codice fornito dall'utente può essere mandato in esecuzione sul server; Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 50

51 Best practices per la sicurezza intranet riferimento insicuro ad un oggetto, quando un elemento implementativo, come ad esempio un file, viene esposto e può essere manipolato; cross site request forgery (CSRF), che si ha nei casi in cui il browser del client viene sfruttato per inviare una richiesta ostile ad una applicazione web a cui si è già autenticato; fughe di informazioni e cattiva gestione degli errori, consistente in informazioni sulla configurazioni e meccanismi interni che vengono esposte all'utente in caso di certi errori; sistemi deboli di autenticazione e gestione della sessione, manipolabili da un attaccante per compromettere password o assumere altre identità; memorizzazione crittografica insicura, che permette di accedere a dati sensibili; comunicazione insicura, che si ha nei casi in cui il traffico di rete non viene cifrato e contiene dati sensibili. Particolarmente rilevante in ambiente intranet, in quanto le possibilità di sniffare il traffico di rete sono più alte; errata restrizione dell'accesso agli URL, quando l'applicazione discrimina le funzionalità offerte semplicemente mostrando o meno certi URL, cui un attaccante può accedere direttamente. La sicurezza delle applicazioni è un argomento in sé vastissimo e non si discuterà ulteriormente in dettaglio. Il nodo fondamentale è che lo sviluppo delle applicazioni deve essere un'attività consapevole delle problematiche di sicurezza e non può astenersi dall'adottare le opportune misure. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 51

52 Best practices per la sicurezza intranet Logging nelle applicazioni Si è individuata come area di interesse per la sicurezza della rete aziendale quella costituita dall'interazione tra utenti, applicazioni e sistemi. Per avere dei dati su cui verificare le politiche di sicurezza con l'auditing è necessario che le applicazioni proprietarie dell'azienda implementino in maniera sicura e completa il logging delle azioni degli utenti Corretta gestione delle credenziali nelle applicazioni Per le applicazioni lato server è una buona pratica di sicurezza, ampiamente adottata, quella di usare account di sistema, creati appositamente con i privilegi minimi per garantirne il funzionamento. In caso di compromissione del processo del server un attaccante otterrebbe un accesso molto limitato, il che è preferibile ad uno amministrativo. Spesso questo accorgimento viene omesso per alcune applicazioni accessibili solo dalla rete interna, ma è consigliabile adottarlo in ogni caso. Nelle applicazioni a più livelli (tier), come quelle web, i dati sono gestiti verosimilmente da un database con cui il processo dell'applicazione si interfaccia. Per connettersi al database è obbligatorio che l'applicazione fornisca delle credenziali d'accesso e spesso per ogni applicazione viene creato un account sul database con i soli privilegi per garantire l'accesso ai suoi dati e nell'applicazione vengono memorizzate le informazioni di connessione al database. Questo approccio non crea grossi problemi finché la stessa applicazione non deve trattare diverse prospettive e livelli di accesso ai dati a seconda dell'utente collegato. Ad esempio si potrebbe desiderare che un impiegato del magazzino Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 52

53 Best practices per la sicurezza intranet possa solamente visualizzare e modificare alcuni dati, mentre il CFO 4 possa avere un accesso più ampio, ma magari non possa modificare i dati del magazzino. In uno scenario del genere, abbastanza comune, si può considerare una soluzione alternativa. I database hanno un ottimo supporto alla multiutenza e possono stabilire i privilegi con una granularità molto fine. A livello applicativo invece il supporto ai diversi livelli di accesso va programmato nel codice. Questa situazione ha alcune problematiche: in primo luogo le credenziali di accesso al database vanno memorizzate in qualche punto sul server, pertanto qualche utente potrebbe impossessarsene; programmare le restrizioni di accesso aggiunge indubbiamente complessità all'applicazione e se un suo difetto viene sfruttato per circonvenire il processo di autenticazione o le limitazioni di un dato account, un attaccante otterrebbe l'accesso totale al database; le capacità di logging del database perdono gran parte del loro valore, poiché tutte le operazioni eseguite dall'applicazione risultano compiute sempre con le stesse credenziali. Per questi motivi una buona pratica di sicurezza, rispondente al principio dell'unico punto di contatto, è quella di far sì che le applicazioni usino per interfacciarsi al database delle credenziali relative ad ogni singolo utente. In questo modo la protezione dei dati può essere centralizzata proprio sul database dove sono memorizzati, sfruttandone le caratteristiche di multiutenza, e ottenendo una traccia corretta delle operazioni sui suoi log. Un approccio di questo tipo è 4 Chief Financial Officer, capo del reparto finanziario. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 53

54 Best practices per la sicurezza intranet raccomandabile nei casi in cui la stessa applicazione debba fornire diverse prospettive sui dati anche molto importanti Auditing del sorgente e penetration testing Per applicativi sviluppati all'interno dell'azienda, specie se di importanza critica o trattanti dati di valore, può essere prudente effettuare un processo di auditing del codice sorgente per eliminarne eventuali irregolarità, bachi o backdoor. Tale attività deve chiaramente essere effettuata da personale esterno alla società o comunque diverso dagli sviluppatori dell'applicazione. Complementare all'auditing del sorgente può essere eseguita un'attività di penetration testing, anche conosciuta come ethical hacking, ovvero una verifica della buona programmazione attraverso dei tentativi di attacco condotti da professionisti della sicurezza informatica. 5.4 Utenti e gestione dell'identità Avendo osservato come gli utenti siano una parte centrale della rete aziendale e che rappresentino inoltre l'origine della minacce alla sua sicurezza, è necessario provvedere ad adottare pratiche sicure di gestione dell'identità Corretta definizione dell'identità digitale L'identità è un concetto astratto che indica la possibilità di individuare con precisione un soggetto, ovvero identificarlo. Per consentire l'identificazione si considerano le caratteristiche essenziali ed uniche del soggetto [IDCS] e, a seconda dei casi, possono esserne richieste alcune o altre, in minore o maggior numero. Una definizione di identità digitale afferma che essa è la rappresentazione Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 54

55 Best practices per la sicurezza intranet virtuale dell'identità reale che può essere usata durante interazioni elettroniche con persone o macchine [FIM]. Essa fondamentalmente consiste di uno o più account sui sistemi informatici che danno diritto ad effettuare certe operazioni. L'identità digitale presenta delle problematiche legate alla debolezza del legame con una identità reale od alla segmentazione, dovuta all'avere numerosi account diversi per una singola persona. Il primo passo di una corretta gestione dell'identità è quello di assicurare la definizione dell'identità, ovvero garantire che un certo account del sistema informatico corrisponda sempre ad una sola persona fisica. Tale corrispondenza è un elemento della sicurezza della rete aziendale, in quanto necessaria per poter monitorare l'uso dei sistemi e punire i colpevoli di eventuali reati informatici. L'identità digitale è più facilmente falsificabile che quella fisica e questo può far si che un attaccante dei sistemi informatici rimanga anonimo e quindi impunito. In una tale situazione anche l'effetto deterrente di una condanna viene meno, rendendo dunque un attacco anche più probabile. La definizione dell'identità si ottiene con una gestione degli account in maniera che la corrispondenza con la persona fisica sia sempre assicurata e idealmente il rapporto sia di uno ad uno, ovvero che ogni utente abbia solamente un account sulla rete aziendale e non di più. A questo va aggiunto un processo di riconoscimento dell'identità, o meglio di autenticazione, difficilmente aggirabile. Solitamente l'autenticazione avviene mediante un segreto condiviso, la password, ma sono disponibili anche sistemi più forti, che includono ad esempio smart card o dispositivi di riconoscimento biometrico. Soluzioni per la gestione dell'identità digitale nelle imprese sono disponibili e possono portare notevoli benefici, sia in sicurezza che in manutenibilità della rete, Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 55

56 Best practices per la sicurezza intranet tuttavia non si vuole in questa sede addentrarsi nell'argomento, ma notare che per società che avessero già adottato una simile soluzione la sicurezza intranet potrebbe essere un traguardo più vicino Politiche sulle password e single sign on La compromissione delle password di un collega è un elemento comune a diversi casi di insider threat. Alla base di ciò c'è spesso la scelta di una password debole o peggio poca tutela della sua segretezza da parte del relativo utente. Ad esempio ottenendo il file delle password di un sistema con molti utenti è molto facile che se ne possano scoprire diverse in pochi minuti con un programma per il password cracking. In altri casi la password od il relativo hash possono viaggiare in maniera non protetta sulla rete ed essere catturati. Precise norme di sicurezza devono dunque essere adottate al riguardo al fine di: stabilire regole di complessità e resistenza; vietare il passaggio sulla rete in chiaro delle password e possibilmente anche degli hash; definire termini massimi di durata di una password. Il problema delle password è una battaglia aperta della sicurezza informatica che dura da anni, in quando password sicure sono umanamente difficili da ricordare e da inventare. Inoltre accade in molti ambienti che gli utenti debbano ricordare e inserire diverse password durante l'utilizzo dei sistemi, causando loro frustrazione e costituendo una forte tentazione di scegliere una password breve o semplice da memorizzare. Per questo motivo parte della soluzione al problema consiste nel facilitare la vita degli utenti facendo sì che la parola d'ordine venga chiesta il meno possibile, Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 56

57 Best practices per la sicurezza intranet attraverso un sistema di single sign on, grazie al quale l'utente deve immettere la password solo all'inizio della sua attività e con quella risulta autenticato automaticamente per tutte le applicazioni che deve usare. Una tale soluzione ha anche il pregio di accentrare il controllo dell'autorizzazione e ostacolare l'uso di più account per ogni persona fisica. Infine l'addestramento degli utenti dovrebbe insistere molto sulla questione della password e dell'identità digitale, responsabilizzandoli riguardo alle conseguenze di una gestione imprudente delle loro credenziali Evitare l'uso di account amministrativi condivisi Gli account di sistema, indispensabili per l'installazione o la manutenzione dei sistemi operativi e dei database costituiscono un doppio problema. In primo luogo sono intrinsecamente dotati del più alto livello di privilegio e pertanto sono difficilmente monitorabili. Questo fa si che si vogliano usare il meno possibile, cosa che ha dei risvolti più tecnici e sistemistici, poiché per la gestione delle macchine è necessario a volte usare questo tipo di account. In seguito, parlando di sicurezza dei sistemi, si vedrà più in dettaglio questo aspetto. Il secondo problema è che gli account amministrativi sono difficilmente associabili alle persone fisiche perché comunemente accade che le persone che devono accedere alle macchine con i privilegi amministrativi siano più d'una e questo spesso porta alla condivisione delle credenziali d'accesso e dunque ad una cattiva definizione dell'identità. Questo non si risolve semplicemente vietando la condivisione delle password, in quanto i sistemi andrebbero poi ripartiti tra gli amministratori e questo diminuirebbe la produttività, lasciando comunque scomodo il tracciare a chi effettivamente corrispondono gli account da una prospettiva globale. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 57

58 Best practices per la sicurezza intranet La soluzione è quella di usare gli account amministrativi inclusi nei software il meno possibile, aprendo per gli amministratori degli account appositi e personali, distinti dai loro account non privilegiati se necessario. Specialmente la pratica di effettuare il login con un account amministrativo è controproducente per garantire la definizione dell'identità e andrebbe assolutamente scoraggiata. Questa primo accorgimento facilita soltanto l'individuazione della persona fisica qualora si verificassero incidenti legati all'attività di amministrazione delle macchine Separazione dei compiti e minimo privilegio Stabilita la pericolosità degli account illimitati, pertanto è semplice capire come sia desiderabile limitare il più possibile i privilegi degli utenti. Il minimo privilegio è un principio riconosciuto della sicurezza informatica, citato in precedenza. In questo contesto è interpretabile come dare ad ogni utente l'accesso al minimo insieme di servizi che gli permettono di svolgere le sue mansioni agevolmente. La separazione dei compiti è più propriamente una contromisura per le insider threat, specialmente frodi e sabotaggi, che consiste nel dividere le funzioni in modo che la collaborazione di altre persone sia necessaria per portare avanti un'attività delicata. E' un elemento che può mitigare effettivamente il rischio di attacchi interni, in quanto è generalmente meno probabile che gli impiegati intraprendano azioni dannose per l'azienda se devono collaborare con altri, per il rischio di dover rivelare le proprie intenzioni e la rarità di dipendenti con motivazione sufficiente. La separazione dei compiti è applicabile a molti livelli ed è una pratica adottata Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 58

59 Best practices per la sicurezza intranet comunemente, ma alle volte persa un po' di vista quando si tratta del sistema informatico. Ad esempio essa è positivamente applicabile tra: chi amministra la rete e gli utenti del sistema informativo; sviluppatori di applicativi e relativi utilizzatori; chi inserisce dati critici e chi li approva; amministratori di sistemi e di database; chi effettua la manutenzione dei sistemi e chi il controllo qualità; chi scrive il codice dei programmi e chi lo revisiona. Moltissime situazioni si presentano adatte a pratiche di separazione dei compiti e una violazione di questa regola espone l'azienda ad eventuali effetti dello strapotere di un singolo su una certa componente del sistema Audit degli account Quali siano le misure di sicurezza attive nel sistema informatico una compromissione degli account può portare un attaccante ad ottenere un accesso anonimo e privilegiato, risultante in una quasi totale sconfitta delle prime. L'insieme degli account ed i relativi privilegi sono dunque una base su cui poggia il resto della sicurezza e come tale è necessario garantirne la massima solidità. Istituire periodiche operazioni di revisione degli account è la miglior pratica per assicurarsi della corretta gestione degli account e verificare effettivamente che i principi di cui si è detto sinora siano applicati: definizione dell'identità, separazioni dei compiti e minimo privilegio, terminazione puntuale. Un particolare pericolo da cui ci si vuole difendere con questa operazione è la Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 59

60 Best practices per la sicurezza intranet creazione di account backdoor, ovvero account fasulli, magari anche apparentemente leciti, destinati a fornire un accesso non autorizzato e anonimo. I casi di insider threat che comprendevano l'uso di account backdoor o privilegi non assegnati correttamente sono tra i più comuni e coprono tutti i tipi di attacchi. Diversi di essi avrebbero potuto essere evitati con un corretto processo di audit degli account, che costituisce dunque un punto molto importante nella difesa da tali minacce Terminazione rapida degli account Finché dipendenti dell'azienda gli utenti sono in possesso di un accesso legittimo ed autorizzato al sistema informatico, ma, al termine del rapporto di lavoro, verosimilmente la cosa non vale più. Un'organizzazione deve disabilitare gli account relativi ad un ex dipendente in maniera rapida e puntuale, altrimenti la rete rimane vulnerabile ad accessi non autorizzati. In casi reali ex dipendenti hanno saputo mostrare molte risorse nell'accedere nuovamente alla rete e questo fa sì che sia importante poter tracciare con precisione quali percorsi di accesso siano disponibili ad un determinato utente e assicurarsi di disabilitare ognuno di essi. E' preferibile anche stabilire delle politiche e procedure formali al riguardo per ridurre il rischio di pericolose omissioni. Per aziende che desiderano garantire l'accesso a certi servizi informativi dopo una terminazione in circostanze favorevoli, deve essere predisposta una chiara politica di sicurezza concordata con l'ex dipendente e comunque rivisti i suoi privilegi ed identità L' è un mezzo usato in maniera sempre più intensiva per comunicazioni sia Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 60

61 Best practices per la sicurezza intranet interne alla società che con il resto del mondo. Nel suo uso interno la posta elettronica è diventata uno strumento per il funzionamento della catena di comando. Capi, supervisori e simili la usano correntemente per dare ordini, specialmente quando si tratta di questioni legate all'uso dei computer, come richieste di file o modifiche al sistema informatico. L' tuttavia costituisce un mezzo non sufficientemente sicuro per questi utilizzi in quanto non assicura la confidenzialità del contenuto, ma soprattutto non garantisce per nulla l'identità del mittente, in quanto l'indirizzo del mittente può essere facilmente falsificato. Questa condizione lascia ampissimi spazi alle tecniche di ingegneria sociale, attraverso le quali un impiegato, o anche un ex impiegato, in cattiva fede potrebbe impersonare un superiore e fare richieste con la sua autorità. Sono realmente accaduti casi in cui questo espediente è stato usato come parte di una frode, ad esempio falsificando una richiesta di maggiori privilegi per il proprio account. Sebbene possa essere di fatto scomodo adottare alcuni accorgimenti per la sicurezza delle , costituisce il rafforzamento di un punto spesso particolarmente privo di difese della infrastruttura informatica dell'azienda. La crittografia a chiave pubblica, fornisce la soluzione più efficace alle mancanze della posta elettronica, garantendo l'integrità ed eventualmente la segretezza del contenuto, così come l'identità del mittente, grazie al meccanismo della firma digitale. Implementazioni che rendono il meccanismo di firma e cifratura quasi trasparente all'utente sono possibili e costituiscono sicuramente una pratica consigliabile per la sicurezza intranet. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 61

62 Best practices per la sicurezza intranet 5.5 Sicurezza dei sistemi Costituendo il supporto all'esecuzione degli applicativi e alla memorizzazione di dati, i sistemi sono la componente alla base della sicurezza della rete. Si vedranno dunque ora le principali pratiche di gestione e configurazione di sistemi operativi, software di utilità e comunicazioni di rete atte a garantire un ambiente sicuro per l'utilizzo aziendale in casi di alto rischio Layout sicuro della rete interna Si è accennato come la difesa da minacce esterne porti nella quasi totalità dei casi ad una topologia di rete prevedente un firewall come separatore tra rete interna, esterna ed una terza zona per ospitare i servizi pubblici che prende il nome di DMZ. Tuttavia per garantire una maggiore facilità di protezione della rete interna, può essere efficace adottare una topologia particolare anche lì. La comune architettura client server aiuta effettivamente a separare la parte gli asset più importanti, come dati e i server ospitanti le applicazioni critiche, dalle postazioni comuni di lavoro. Tale divisione può essere ottenuta tramite un router IP, o meglio un firewall. L'incanalamento del traffico attraverso un unico punto di accesso dei client all'area dei server critici, porta alcuni benefici immediati come: limitazioni ai possibili attacchi legati ai protocolli di rete di basso livello, facilità di applicazione di un sistema di intrusion prevention (IPS) o intrusion detection (IDS), separazione del traffico di rete tra sistemi critici e sistemi client, e Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 62

63 Best practices per la sicurezza intranet applicabilità di politiche di sicurezza diverse tra le due. ulteriore stato difensivo per minacce esterne. maggiore ordine e logica nella topologia della rete interna. Ecco una rappresentazione riassuntiva del layout proposto: Illustrazione 3: Layout per la sicurezza della rete interna Il pregio principale di questa topologia è quello di separare gli oggetti degli attacchi dalle probabili fonti, individuando un punto monitorabile per intercettare azioni pericolose da parte degli utenti comuni e circoscrivendo la zona di attenzione per quelle degli amministratori. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 63

64 Best practices per la sicurezza intranet Minimizzare l'uso di account illimitati Si è già discusso delle pericolosità connesse con gli account amministrativi parlando della gestione degli account. Avendo stabilito che gli account predefiniti nei sistemi operativi o nei database sono possibilmente da non usare, preferendone altri riferiti personalmente ai singoli amministratori, rimane comunque il problema dell'impossibilità di monitorare efficacemente questi account comunque dotati di privilegi illimitati. La soluzione va dunque cercata nel diminuire il più possibile il loro utilizzo. Questo è un punto veramente centrale della riduzione del rischio associato alle insider threat, in quanto nella maggior parte dei casi, specialmente tra i più dannosi, vi è alla base il misuso di privilegi amministrativi. E' bene notare anche che per fronteggiare realmente la minaccia legata a questa tipologia di utenti altre pratiche complementari devono essere adottate, tra cui la separazione dei compiti e il controllo di qualità. Il ruolo degli account illimitati non è del tutto eliminabile, in quando essenziale a certe operazioni, ma al di fuori dell'installazione e configurazione iniziale può essere relegato a interventi di manutenzione straordinaria. La soluzione risiede nell'automatizzare il più possibile le operazioni di gestione ordinaria, in modo che l'attività umana sia ridotta al minimo. Per attività potenzialmente pericolose, che non ci si sente di automatizzare, ma che vanno effettuate relativamente spesso, come ad esempio l'installazione di un aggiornamento o il riavvio della macchina o di un suo servizio, si può cercare un sistema che consenta di usare i privilegi massimi in maniera limitata e controllabile. In ambiente Unix tale soluzione è rappresentata dal programma sudo, Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 64

65 Best practices per la sicurezza intranet contrazione di super user do, ovvero fare come super utente. Esso è incluso in maniera predefinita in gran parte dei sistemi Unix, di cui costituisce un comando importante. Sudo permette di garantire a singoli utenti o a gruppi la capacità di eseguire certi comandi con i privilegi massimi. Può essere finemente configurato per chiedere la password di root o accontentarsi della password di utente, permettendo anche di stabilire che alcuni comandi non richiedano alcuna password. Attraverso il suo uso si riesce ad evitare l'apertura di una shell dei comandi con i privilegi di root, che è difficilmente monitorabile, sostituendola con una serie di comandi prefissati da sudo, i quali lasciano una precisa traccia nei log di autenticazione Difendersi attivamente dall'esecuzione di codice malevolo Il primo pensiero parlando di protezione da codice malevolo va sicuramente ai programmi antivirus e antispyware, esplicitamente richiesti anche dallo standard ISO riguardo a questa tematica. Essi sono però fondamentalmente strumenti di difesa da attacchi esterni, indiretti e su larga scala. Senza nulla togliere alla loro utilità, per difendersi da codice personalizzato o creato ad hoc, è necessario qualcos'altro. Con il supporto del sistema operativo è possibile ottenere che venga ammessa l'esecuzione di soli binari firmati digitalmente con certe chiavi. Configurare un ambiente del genere è un processo lungo, ma fortunatamente sono disponibili anche strumenti detti file integrity checkers, per individuare eventuali cambiamenti di file, in seguito magari dell'installazione di un rootkit, una logic Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 65

66 Best practices per la sicurezza intranet bomb o la sostituzione con una versione vulnerabile di un programma già presente. Per poter controllare realmente l'integrità dei sistemi è necessario tuttavia qualche cambiamento a livello di pratiche di gestione delle configurazioni software dei sistemi, che merita un punto a sé stante Formalizzare procedure e controlli relativamente alle configurazioni software Relativamente al software di supporto alle memorizzazione di dati ed all'esecuzione degli applicativi aziendali si vuole accertare l'integrità ed, in caso di compromissione, trovarne le alterazioni apportate, l'origine temporale ed il responsabile. Questo richiede una gestione delle modifiche di configurazione dei sistemi critici con procedure regolamentate e registrate. Il primo passo è quello di far corrispondere alle attività di installazione e manutenzione dei sistemi un'attività di verifica delle configurazioni. Le due vanno svolte da diverso personale, secondo il principio di separazione dei compiti, e costituiscono una procedura integrabile con il controllo di qualità. Innanzitutto un'organizzazione deve identificare le configurazioni software di base corrispondenti ai vari bisogni informatici che si presentano nelle diverse aree come server, piattaforme di sviluppo, postazioni di lavoro per impiegati e manager. Delle varie configurazioni base individuate si deve quindi attuarne una caratterizzazione, ovvero annotarne le caratteristiche in modo dettagliato, comprendendo: nomi e versioni dei software installati, somme crittografiche di controllo dei file, file di configurazione, Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 66

67 Best practices per la sicurezza intranet opzioni di periferiche, BIOS e numeri seriali. Le singole installazioni potranno ora essere validate rispetto alle configurazioni base. Gli interventi di manutenzione, come gli aggiornamenti, saranno dettagliatamente registrati e le caratterizzazioni verranno aggiornate per eseguire nuove validazioni in futuro. Questo sistema permette dunque di verificare l'integrità dei sistemi ed il tenere traccia delle modifiche e di chi le effettua, se si rispettano anche le altre best practices, ad individuare il responsabile ed il periodo di inizio di una compromissione Attivare politiche sicure di backup e ripristino Prevenire gli attacchi è la prima linea di difesa, ma l'esperienza insegna che ogni tanto qualcosa fa breccia e in quel caso meglio essere preparati. A tal punto infatti standard di sicurezza e framework includono tutti dei punti sulle procedure di backup e ripristino. Avere backup recenti di dati e sistemi, in coppia con un efficiente processo di ripristino può evitare il verificarsi di: molte ore di downtime dei sistemi per il ripristino, giorni o settimane di inserimento manuale di dati, mesi o anni per ricostruire l'insieme di informazioni perduto. I backup sono anche frequentemente oggetto di attenzione degli attaccanti nei casi di sabotaggio dall'interno, pertanto la loro sicurezza deve essere tutelata. Alcuni modi per farlo sono: Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 67

68 Best practices per la sicurezza intranet applicare la separazione dei compiti tra chi gestisce i sistemi e chi i rispettivi backup; difendere fisicamente i mezzi fisici dei backup dalla degenerazione, dal furto e dalla distruzione; applicare le procedure di gestione delle configurazioni ai sistemi di backup come ai sistemi critici; eventualmente incaricare diverso personale di custodire differenti copie di backup Correggere rapidamente e prevenire le vulnerabilità nei sistemi Sistemi operativi, servizi di utilità e librerie sono continuamente soggetti ad aggiornamenti per risolvere i problemi di sicurezza che vengono mano a mano scoperti. Alle volte i difetti di sicurezza sono resi di pubblico dominio prima che sia disponibile un aggiornamento. In tal caso sono comunque spesso attivabili delle contromisure temporanee, in gergo work around. In ogni caso alla pubblicazione di un aggiornamento viene, esplicitamente o implicitamente, dettagliata anche la falla che esso va a riparare. Il tempo che intercorre tra diffusione dei dettagli sulla falla e l'installazione dell'aggiornamento rappresenta una finestra di vulnerabilità per i sistemi interessati e dunque un rischio per l'azienda. Ci sono due vie per mitigare questo tipo di rischi. La prima consiste nel velocizzare il processo di installazione degli aggiornamenti, che comprende: adottare meccanismi di automazione delle installazioni, Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 68

69 Best practices per la sicurezza intranet definire delle procedure per il testing rapido degli aggiornamenti, utilizzare software per il controllo centralizzato dello stato di aggiornamento delle varie macchine. La seconda invece è quella del prevenire il più possibile le conseguenze in termini di sicurezza dello sfruttamento di molte vulnerabilità. Ad esempio molti problemi di sicurezza sono legati alla corruzione della memoria durante l'esecuzione, che permette di deviare il flusso del programma. Attraverso l'uso di librerie e programmi compilate con tecniche particolari, questa intera categoria di problemi può essere in gran parte privata di conseguenze sulla sicurezza. A molte fonti possibili di problemi di sicurezza corrispondono particolari soluzioni software che vi pongono un rimedio, tra cui chroot jail e mandatory access control, per citarne alcune, volte a costituire strati ridondanti di sicurezza, proprio secondo uno dei principi precedentemente individuati. L'attività di rendere gli ambienti software più resistenti a problemi di sicurezza viene spesso detta hardening, letteralmente indurimento, ed è una pratica assolutamente auspicabile a cui sottoporre i sistemi critici. 5.6 Auditing L'auditing per la rete aziendale ha la finalità di sapere e registrare cosa accade nei sistemi per verificare la conformità del loro utilizzo. Le attività degli utenti, i cambiamenti delle configurazioni e i messaggi di sistemi operativi ed applicazioni sono gli eventi su cui si basa il processo di auditing, per condurre le analisi e trarne dei risultati. Un'attività di auditing diligente ha molti pregi, tra cui trovare eventuali: comportamenti anomali o sospetti degli utenti; Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 69

70 Best practices per la sicurezza intranet violazioni delle politiche di sicurezza; configurazioni errate; dinamiche di incidenti e attacchi riusciti o sventati. Riguardo alle insider threat essa è in grado di far rilevare eventi come impiegati che stiano accedendo, o tentando di accedere, ad informazioni riservate ed amministratori di sistemi che effettuino operazioni non richieste. L'auditing costituisce l'unica vera linea di difesa e prevenzione efficace contro questa minaccia ed contribuisce moltissimo alla sicurezza intranet complessiva. Per le aziende il cui sistema informatico rappresenti una forte componente del rischio operativo attivare un processo di auditing globale è indubbiamente necessario. Attraverso le prossime pratiche si presenteranno le premesse per un auditing efficace Registrare e monitorare le azioni sulla rete Se politiche e procedure relative ad account e password sono predisposte e applicate, l'organizzazione ha una buona probabilità di associare con chiarezza le azioni sulla rete con il dipendente che le compie, attraverso i registri degli eventi di applicazioni e sistemi. Gli utilizzi degli asset principali e dei relativi sistemi vanno correttamente dettagliati, siano essi dei file, delle tabelle in un database o dei dati di un'applicazione. I log sono il punto di partenza per il processo vero e proprio di auditing e la loro qualità e completezza è essenziale. In particolare nonostante si tratti di dati provenienti da fonti diverse, magari con formati diversi, deve comunque essere Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 70

71 Best practices per la sicurezza intranet ricostruibile la visione d'insieme e un'azione deve essere chiaramente imputabile all'utente che la commette, secondo il principio della non disconoscibilità, cui si è accennato dando riguardo alla definizione di sicurezza informatica Individuare ed ispezionare anomalie e violazioni Il cuore dell'attività di auditing è proprio rappresentato dal rivedere i dati raccolti per ricavarne delle informazioni sullo stato di sicurezza della rete. Con esso si può verificare se effettivamente le misure di sicurezza attive sulla rete corrispondono alla politica globale, provvedendo a correggerle qualora si noti un evento non previsto. Inoltre si possono tener d'occhio le azioni degli utenti ed individuare da errori in buona fede, ad atteggiamenti sospetti od ostili, sino ad attacchi veri e propri. Qualora si noti un'anomalia di questo tipo è buona norma indagare sulla questione per identificarne le ramificazioni. In seguito ad attività sospetta sulla rete o ad atteggiamenti personali preoccupanti, si può condurre un monitoraggio tecnico delle azioni del relativo utente, eventualmente prevenendo un attacco prima del compimento. L'auditing dovrebbe essere sia continuativo nel tempo che casuale. Se gli impiegati sono consapevoli della regolarità e continuità dei controlli, ciò può servire da deterrente per le insider threat. Ricavare le informazioni dai log è un procedimento arduo se fatto manualmente, in quanto essi sono: sparsi in diversi punti della rete aziendale privi di riferimenti uno con l'altro Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 71

72 Best practices per la sicurezza intranet in formati diversi difficilmente leggibili Pertanto i meccanismi di auditing dovrebbero essere il più possibile automatizzati, per semplificare la raccolta dei log, per migliorare le capacità di indagine, distinguere rapidamente gli eventi più significativi e ridurre il ritardo tra il verificarsi di un evento e la sua ispezione. L'attività di auditing rappresenta il livello più alto della protezione della rete aziendale, essa costituisce una difesa potente contro le minacce interne, nonché un ottimo strumento per il buon governo dell'infrastruttura IT, ma è chiaramente dipendente dai livelli sottostanti, costituiti dalle altre aree di attenzione di cui si è trattato in precedenza Effettuare il logging via rete su macchine sicure Si è osservato come in presenza di un accesso amministrativo ad un sistema, la compromissione di quella macchina potrebbe essere immediata ed i log alterati a piacere. Avendo adottato le best practices presentate sino a questo punto, l'utilizzo di account privilegiati dovrebbe essere fatto raramente ed in maniera monitorabile, senza mai assumere il controllo totale della macchina. Tuttavia per un amministratore che volesse effettuare modifiche di nascosto, basterebbe cancellare le proprie tracce, modificando i log. L'unica difesa da questa situazione è quella di usare il logging via rete, grazie al quale sul server che riceve il log risulterebbe almeno una riga relativa all'apertura di una sessione con i privilegi massimi. Questo è il massimo che si può sperare di ottenere in maniera affidabile, in quanto tutto ciò che verrebbe inviato dopo potrebbe essere stato contraffatto o filtrato. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 72

73 Best practices per la sicurezza intranet Questo tipo di eventi, nonostante sia indicato da una sola riga nei log, va comunque considerato di estrema rilevanza e bisogna assolutamente verificare che si sia trattato di un intervento richiesto in seguito a qualche evento straordinario, altrimenti prendere dei provvedimenti. Una nuova validazione della configurazione sarebbe inoltre consigliabile. Il sistema destinato a ricevere i log dalla rete è un pezzo vitale della sicurezza intranet ed una sua mancanza o compromissione annullerebbe gran parte della capacità di controllo sulla rete. Esso deve dunque essere progettato in maniera da avere il massimo uptime possibile e non ammettere alcuna manomissione. Sui server di log non deve essere possibile effettuare l'accesso da remoto e non deve essere attivo nessun servizio superfluo, che potrebbe presentare delle falle. L'accesso alla console dovrebbe essere controllato fisicamente Memorizzazione sicura dei log In caso di attività illecite sulla rete l'attaccante vorrà il più possibile coprire le proprie tracce [PYWN]. I log di sistema sono inoltre uno strumento per capire la dinamica di un attacco, con la finalità di individuarne i danni specifici, ma anche per eventuali procedimenti giudiziari, in cui essi possono avere efficacia probatoria. Perché possano svolgere queste funzioni i log, oltre a dover essere raccolti in maniera completa e affidabile, vanno inoltre memorizzati in una maniera sicura, che neghi la possibilità della loro eliminazione e fornisca la garanzia che nessuna alterazione abbia avuto luogo. L'azienda dovrebbe quindi dotarsi di un sistema di log management molto automatizzato e tale che: recuperi i log dalle macchine, usando preferibilmente una connessione Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 73

74 Best practices per la sicurezza intranet sicura, assicuri la loro origine e ne protegga l'integrità: la firma digitale dei file è la soluzione migliore, li memorizzi in un ambiente sicuro, o meglio in più di un posto, per un lungo periodo di tempo, visto che certi incidenti possono essere scoperti in ritardo e strumenti di attacco come le logic bomb, possono fare effetto anche dopo diversi mesi. Le macchine che entrano a far parte di questo sistema dovrebbero essere considerate critiche anch'esse. 5.7 Risposta agli incidenti In termini informatici si intende come incidente l'atto di violare una politica di sicurezza implicita o esplicita. Al verificarsi di un incidente occorre prendere molte decisioni riguardanti molteplici aspetti, come: contattare chi di dovere, ottenerne i dettagli, limitare i danni se un attacco è ancora in corso, scoprire l'estensione della compromissione, recuperare informazioni e sistemi attaccati, cercare di individuare l'origine e le dinamiche dell'attacco, per prevenirne di futuri e per eventuali procedimenti giudiziari, Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 74

75 Best practices per la sicurezza intranet attivare rapidamente le attività di ripristino. Una struttura efficace di risposta agli incidenti permette di non farsi cogliere impreparati ed agire correttamente e rapidamente in tutti gli aspetti ora elencati. Diverse metodologie sono proposte per una risposta efficace, comunemente vengono individuate queste fasi principali [IBM ISS]: raccolta di informazioni e relativa analisi, con un approccio rigoroso, costituisce una applicazione informatica della scienza forense. Prevede la documentazione di quanti più aspetti possibili dei sistemi interessati, come memoria volatile, connessioni e attività di rete, contenuto dei dischi ed eventi monitorati, nonché delle attività relative alla gestione dell'incidente. Completata la documentazione, viene intrapresa l'analisi detta post mortem dei sistemi compromessi, con lo scopo di far risultare tra i dati gli indizi sulle dinamiche effettive dell'incidente, nonché di raccogliere prove che possano essere utilizzate in una eventuale azione legale. Per queste attività può essere necessaria la partecipazione delle forze dell'ordine o di consulenti esterni specializzati. contenimento: la prima priorità è determinare che cosa è messo a rischio dall'eventuale diffusione dell incidente, quindi di solito si procede a terminare le operazioni del sistema e alla sua disconnessione dalla rete, specialmente se contiene informazioni sensibili. Non è una fase da compiere troppo frettolosamente, poiché si potrebbero perdere informazioni concernenti l'attacco e la sua origine. In alcuni casi si può addirittura ritardare il contenimento per registrare l attività dell'attaccante. eliminazione, consistente nel correggere la vulnerabilità in seguito alla Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 75

76 Best practices per la sicurezza intranet quale l'incidente ha potuto verificarsi, così che non possa ripetersi. ripristino, attraverso i backup si passa a ripristinare lo stato del sistema precedente all'incidente. In imprese al alto rischio operativo, per quanto spiacevole, deve essere studiato e tenuto pronto un piano di risposta, insieme a dei responsabili della sua attuazione, per non incorrere nei numerosissimi possibili errori di una situazione tanto delicata. Inoltre lo standard ISO dedica due obbiettivi di controllo a questo aspetto della sicurezza. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 76

77 Progetto Progetto 1 Obiettivi e metodologia Nella prima sezione di questa relazione è stata analizzata la problematica della sicurezza interna in ambienti caratterizzati da alti rischi operativi connessi al sistema informatico aziendale. Le esigenze messe in luce sono quella di facilitare il processo di conformità e la relativa dimostrazione, nonché di difendere la rete da minacce originante dall'interno del suo perimetro. Per quest'ultima si è proposta una raccolta di best practices relative a tutte le aree della sicurezza, ma con un particolare riguardo per gli utenti e le loro azioni su applicazioni e sistemi. A tal fine si è sottolineata l'importanza di registrare gli eventi sulla rete ed associarli correttamente con i rispettivi utenti, usando questi log per svolgere attività di auditing sull'uso e la gestione dei sistemi per conoscere quello che avviene, individuare anomalie e problemi, prevenire ed intercettare attacchi od indagare su di essi. Gran parte delle pratiche esposte sono volte a fornire un sistema monitorabile, in quanto di fronte all'insider threat l'unica aspettativa ragionevole è quella che il sistema informatico cooperi ad individuare i pericoli e al più allerti chi di dovere. Il processo di auditing è il punto più alto della difesa, dove si colgono i frutti delle politiche adottate nelle varie altre aree, e per questo non si può tollerare che sia scadente. A proposito di questa attività, si è notato come emerga la necessità di utilizzare un sistema apposito, sia per il log management che per la revisione vera e propria dei dati, che possa semplificare la ricerca delle violazioni della politica di sicurezza. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 77

78 Obiettivi e metodologia Il mercato dei prodotti software per auditing e gestione dei log non è attualmente molto vasto, ma sta crescendo ed IBM ne è entrata da poco lanciando Tivoli Compliance Insight Manager, d'ora in poi brevemente TCIM, la soluzione che verrà analizzata nelle prossime pagine [TCIM]. TCIM è particolarmente promettente, poiché integrabile con altri prodotti, IBM e non, destinati alle altre aree di sicurezza intranet ed offre moduli specifici per generare la documentazione necessaria alle verifiche di conformità per diverse regolamentazioni; le sue caratteristiche verranno discusse in dettaglio nel prossimo capitolo. Il progetto svolto su TCIM ha l'obiettivo di testare la sua efficacia nel risolvere i problemi di log management e facilitare il processo di auditing, valutandone le qualità. Esso è stato condotto come parte dello stage presso l'azienda Blue Reply S.r.l, società del gruppo Reply S.pA, contribuendo a formare in azienda una base di esperienza sull'applicativo. In futuro questo risultato potrebbe tornare utile per una eventuale proposta del prodotto ai propri clienti, nell'ambito della attuale partnership con IBM. Il progetto è stato portato avanti tramite la simulazione sequenziale di alcuni scenari di attacco. L'installazione del componente principale dell'applicazione è stata effettuata su una macchina di test dedicata, con sistema operativo Windows Server 2003, e un altro pc e alcune macchine virtuali sono state usate come fonti di eventi; quest'ultime per lo più utilizzavano sistemi CentOS e Debian GNU/Linux. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 78

79 Introduzione a TCIM 2 Introduzione a TCIM Tivoli Compliance Insight Manager è una suite software per il monitoraggio completo dei sistemi di grandi aziende, il log management e la generazione di resoconti mirati a velocizzare il processo di verifica della conformità a diverse regolamentazioni. E' formato da diversi componenti secondo la logica client server e dotato di un'interfaccia web accessibile con un browser. Nei prossimi paragrafi si esamineranno più in dettaglio le sue caratteristiche e funzionalità, esaminando inoltre l'architettura implementativa. 2.1 Funzionalità TCIM svolge diversi compiti: gestisce i log, facilita il processo di auditing e genera automaticamente dei resoconti, specialmente quelli utili alla compliance. Log management La prima importante funzione che TCIM è in grado di svolgere è quella di gestione centralizzata dei log. Esso è in grado di recuperare i log da svariati punti della rete, detti fonti di eventi, attraverso diversi meccanismi, di cui si tratterà più avanti. I log vengono depositati in un'area detta depot, sul filesystem delle macchine in cui è installato TCIM o su un supporto condiviso nella rete Windows. Nel depot essi sono organizzati in una gerarchia di file e cartelle secondo la macchina di provenienza e l'arco temporale di riferimento. Nessuna eliminazione automatica dei file di log viene effettuata, così eventuali obblighi di legge relativi alla durata massima della loro memorizzazione devono essere osservati con procedure automatizzate, create separatamente, oppure Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 79

80 Introduzione a TCIM manualmente. Attraverso l'interfaccia web, grazie alla vista Log Manager, si può verificare l'andamento delle attività di raccolta per individuare eventuali errori, così come scaricare i dati originali, specificando dei parametri di ricerca, anche relativi ai contenuti dei log, che sono indicizzati. Illustrazione 4: La vista Log Manager Auditing La funzionalità principale di TCIM è quella di interpretare ed elaborare i dati raccolti, automatizzando parte del processo di auditing. La vista iview, accessibile mediante browser, permette di visualizzare gli eventi verificatisi e sfruttare le capacità del programma per rivolgere la propria attenzione rapidamente sulle questioni di maggiore importanza. E' possibile navigare agilmente tra gli eventi Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 80

81 Introduzione a TCIM rilevati su diverse piattaforme, filtrarne quelli che non si vogliono considerare e verificarne la conformità rispetto ad una politica di sicurezza globale. La dashboard di iview è una sorta di cruscotto che raduna molti indicatori riassuntivi della situazione globale della rete. Da essa si procede aumentando il livello di dettaglio su quello che si reputa degno di un approfondimento e, trovando un problema che richieda ulteriori investigazioni, si può aprire un ticket, che costituisce una segnalazione ed una richiesta di chiarimenti per quell'evento. In seguito più utenti potranno visualizzare il ticket, fare le loro investigazioni e aggiungere delle note, collaborando per comprendere le cause ed eventualmente approntare una soluzione. Infine TCIM è in grado di mandare avvisi via e mail in corrispondenza di determinati eventi, giudicati sufficientemente rilevanti. Compliance e generazione di resoconti La vista iview contiene una sezione dedicata alla generazione ed alla consultazione di resoconti. Alcuni di essi dettagliano precisi aspetti della sicurezza e possono essere utilizzati per individuare specifiche anomalie, altri invece riepilogano questioni più complesse, fornendo delle viste generali fruibili dal management o dai meno esperti. Le operazioni di auditing possono essere velocizzate utilizzando questi report o creandone di nuovi personalizzati, eventualmente facendo sì che siano inviati in maniera automatica a determinate figure all'interno dell'organizzazione. Inoltre TCIM dispone di moduli appositi per la conformità a diversi standard e regolamentazioni, distribuiti come plugin installabili separatamente, dopo i componenti principali. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 81

82 Introduzione a TCIM Vi sono plugin specifici per: Basilea II, GLBA5, HIPAA, ISO (ora ISO 27001), Sarbanes Oxley. Ognuno di essi consiste semplicemente in una serie di resoconti predefiniti, relativi ai diversi punti di cui si costituisce lo standard o il requisito legale, che si possono usare nel processo di compliance sia per tenere d'occhio lo stato corrente ed individuare eventuali scostamenti, che per dimostrare al revisore l'effettiva adozione degli opportuni controlli. Illustrazione 5: Schermata dei report per ISO Gramm Leach Bliley Act, legge americana relativa a banche ed assicurazioni, che impone l'adozione di una politica di sicurezza relativa ad integrità e riservatezza dei dati finanziari. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 82

83 Introduzione a TCIM 2.2 Componenti della suite Si è parlato di TCIM definendolo una suite, poiché è suddiviso in componenti separati, che possono venire installate in diversi punti e combinazioni, a seconda dell'architettura e della dimensioni della rete che si vuole monitorare. Actuator L'actuator è il programma che si occupa di gestire la raccolta dei log. E' tra tutte la componente di minori dimensioni e l'unica disponibile nativamente per numerose piattaforme: HP UX, IBM AIX, Solaris, Windows. Esso è utilizzabile per raccogliere dati sia dal sistema su cui è installato, sia da altri sistemi in maniera remota, con i meccanismi che si vedranno più avanti. Tivoli Compliance Insight Manager Server Il componente principale di TCIM è responsabile di gestire e coordinare gli actuator, ricevere i log, elaborarli, verificare la conformità alla politica di sicurezza e produrre i resoconti. Il Tivoli Compliance Insight Manager Server è a sua volta un elemento complesso costituito da più programmi che interoperano, anche se installati e configurati in una operazione unica e trasparente all'utente. Il primo di questi è l'interfaccia web per l'utilizzo comune di TCIM, fornita mediante un'istanza dell'application server Tomcat, software open source del progetto Apache. Esso non risponde direttamente alle richieste dei client, ma viene utilizzato in collaborazione con Internet Information Services (IIS), il webserver specifico dei sistemi operativi Microsoft. Le viste iview, Log Manager ed i moduli per la compliance sono tutte disponibili dalla pagina principale di questa interfaccia, che costituisce una sorta di portale. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 83

84 Introduzione a TCIM Illustrazione 6: Il portale dell'interfaccia web Vi è quindi il motore relazionale, il database che viene usato per elaborare gli eventi, costituito da un Oracle Database 10g. La sua installazione è curata dal primo dei tre cd del prodotto ed è effettuata in maniera che sia ottimizzato per TCIM ed nascosto agli utilizzatori del sistema, anche se rimane tecnicamente possibile riutilizzarlo per altri dati. Il suo consumo di risorse è tale da renderlo il collo di bottiglia nelle prestazioni di tutta la suite. In particolare si è riscontrata una scarsa propensione a scalare verso il basso, ovvero ad adattarsi a situazioni di basso carico, in quanto il suo consumo di memoria RAM è rimasto elevatissimo anche a fronte di quantità irrisorie di dati gestiti. La configurazione e addirittura la scelta di usare questo database sono certamente opinabili, poiché per l'uso che ne viene fatto non vengono assolutamente sfruttate le sue qualità, ma si pagano i difetti in termini di prestazioni e verosimilmente anche in costi di licenza. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 84

85 Introduzione a TCIM Ad esempio si è notato che: la dimensione dei dati caricati è sempre limitata e non cresce indeterminatamente; non si arriva sicuramente ad avere un grosso numero di connessioni simultanee; le operazioni di inserimento sono semplici e concentrate in periodi temporali ristretti, non si hanno quasi mai operazioni di aggiornamento di dati esistenti; i dati sul database sono comunque ricavabili direttamente dai log, quindi una perdita di contenuti del database non costituisce un problema; i dati non vengono conservati molto a lungo e sono di norma sostituiti da dati nuovi, il che può rendere le creazioni di molti indici in anticipo un lavoro inutile. Insomma la scelta di Oracle Database 10g come motore sembra più dettata da questioni di prestigio del marchio e semplificazione dello sviluppo, che da una reale necessità dei suoi pregi. Infine vi è il servizio che fornisce le funzionalità proprie di questo componente della suite. Si tratta di una applicazione scritta per gran parte in Java (versione 1.4.2), che funziona sempre background, avviata dal sistema operativo come servizio. Il Tivoli Compliance Insight Manager Server è disponibile solo per sistemi Windows 2000 Advanced Server e Windows 2003 Server, entrambi con filesystem NTFS. Questo rappresenta una limitazione relativamente significativa per un prodotto di sicurezza informatica e, vista la disponibilità di Oracle Database, Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 85

86 Introduzione a TCIM Tomcat e di Java per diverse piattaforme, il supporto a sistemi Unix non dovrebbe essere un traguardo irraggiungibile. Dall'utilizzo di questo programma le uniche funzionalità specifiche del sistema operativo Windows, che vengono attivamente utilizzate sono: la compressione trasparente di alcune cartelle, fornita dal filesystem NTFS, IIS, il servizio di indicizzazione dei file. Le prime possono oggi essere facilmente sostituite con una controparte Unix, mentre l'indicizzazione dei file richiederebbe probabilmente uno sforzo maggiore. Management Console La Management Console, è la console di amministrazione del componente Tivoli Compliance Insight Manager Server, attraverso cui si possono aggiungere le fonti degli eventi, definire come caricare i dati nel database e mettere a punto la politica di sicurezza con la quale vengono confrontati. Si tratta di un'applicazione nativa Windows, dall'interfaccia non particolarmente gradevole ed usabile, forse residuo delle versioni più vecchie dell'applicazione. Alcune delle sue funzionalità relative alla gestione delle politiche sono già presenti anche nell'interfaccia web e si spera che anche le altre vengano migrate in futuro, così da unificare l'amministrazione con il resto delle funzioni e rendere superflua l'installazione di di un client apposito. 2.3 Integrazioni possibili Uno dei maggiori punti di forza di questa suite è senza dubbio l'ampissimo spettro di programmi monitorabili. Per dare un'idea della varietà delle sorgenti di eventi Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 86

87 Introduzione a TCIM supportate si include di seguito una lista, peraltro non completa, dei software di cui TCIM può comprendere i log: Sistemi operativi: Hewlett Packard HP UX, Hewlett Packard OpenVMS, Hewlett Packard Tru64, IBM AIX, IBM OS/400, Microsoft Windows, Novell Novell Netware, Novell Suse Linux, Red Hat Linux, SUN Solaris Sistemi di BMC Identity Manager, CA etrust (Netegrity) SiteMinder, IBM Tivoli autenticazione: Identity Manager, IBM Tivoli Access Manager, RSA Authentication Server (Ace) Server di posta e IBM Lotus Domino (Notes), Microsoft Exchange Server groupware: Server proxy: Blue Coat Systems ProxySG series Server web: Microsoft Internet Information Server (IIS), SUN iplanet Web Server on Solaris Pacchetti applicativi: Misys OPICS, SAP R/3 Database: IBM DB2, IBM UDB, Microsoft SQL Server, Oracle database server, Sybase ASE Firewall: Check Point FireWall 1, Cisco PIX, Symantec (Raptor) Enterprise Firewall IDS, IPS, scanner di ISS RealSecure, McAfee IntruShield IPS Manager, Snort (Open vulnerabilità: Source) IDS, ISS System Scanner Router e switch di rete: Cisco Router, Hewlett Packard ProCurve switch Antivirus McAfee epolicy Orchestrator (epo), TrendMicro ScanMail, Symantec AntiVirus Corporate Edition VPN: Cisco VPN Concentrator 3000 Tabella 1: Sorgenti di eventi supportate da TCIM Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 87

88 Introduzione a TCIM Tra i prodotti supportati è facile notare la presenza di tutti i maggiori sistemi operativi, groupware e IDS, oltre ad un buon numero di sistemi di autenticazione, database ed antivirus. Sicuramente un'organizzazione di grandi dimensioni avrà già diverse applicazioni tra quelle in lista attive nella propria struttura IT, ma è bene notare che, una volta adottato TCIM, le scelte future di applicativi e piattaforme da utilizzare saranno in qualche modo influenzate, se non vincolate, dalle possibilità della suite, la quale tende a concentrarsi sui prodotti di mercato successo di grossi vendor, per coprire le configurazioni software dal lungo ciclo di vita che i clienti hanno già operative. Questo senza dubbio tenderà a limitare la possibilità di innovazione nell'infrastruttura informatica ed eventualmente aumentarne il costo, in quanto soluzioni applicative giovani o economiche non sembrano essere contemplate come degne di supporto. A dimostrazione di ciò è l'assenza tra le sorgenti monitorabili del server web Apache o del server proxy Squid, applicazioni open source e gratuite dal chiaro successo e perfettamente valide anche per il mercato enterprise. Punto di forza di TCIM è invece il supporto all'auditing dei database, che può rappresentare per le grandi imprese il vero motivo di acquisto, vista la relativa scarsità soluzioni concorrenti e la grandissima rilevanza per un impresa che custodisca nei propri database informazioni sensibili o finanziarie. Particolare menzione merita anche la presenza di SAP R/3, la nota piattaforma di ERP. Per le applicazioni aziendali personalizzate o non presenti tra le supportate è possibile insegnare a TCIM come leggere i loro log, tramite dei file, basati sulle espressioni regolari, scritti in GSL (General Scanning Language), ma verranno solamente usati dal Log Manager per la ricerca e non per l'auditing. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 88

89 Introduzione a TCIM E' bene notare che TCIM può essere integrato con strumenti di sicurezza che riguardano gli altri aspetti della sicurezza intranet evidenziati nella prima sezione. Per quanto riguarda la sicurezza dei sistemi abbiamo i prodotti scanner di ISS, che sono in grado di individuare configurazioni errate o potenzialmente pericolose e tracciare lo stato di aggiornamento dei sistemi, identificando prontamente le patch non installate e velocizzando il processo di correzione delle vulnerabilità (paragrafo 5.5.5). Il supporto a diversi IDS/IPS può tornare utile nel caso si adotti una topologia di rete come quella descritta al paragrafo Anche dal punto di vista della gestione dell'identità si osservano alcune integrazioni interessanti, come quelle con il Tivoli Access Manager ed il Tivoli Identity Manager, che forniscono i servizi di amministrazione degli account e single sign on di cui si è parlato ai paragrafi e Queste caratteristiche rappresentano una possibilità di vedere TCIM come una parte, anche consistente, di una soluzione di ampio raggio all'insider threat, con cui aumentare ulteriormente i benefici in termini di sicurezza delle pratiche e degli strumenti in uso per le varie arie della rete. 2.4 Origini ed evoluzione Il software oggetto di questa progetto ha origine presso una società chiamata Consul, con il nome di Consul Insight. Consul è nata nel 1986 ed ha operato in tutto il mondo con oltre 350 imprese clienti e con due sedi, in Olanda e negli Stati Uniti [CONSUL]. La compagnia è stata acquisita da IBM il 24 gennaio 2007 ed è ora in fase di integrazione nel suo assetto aziendale. In futuro Consul non esisterà più come azienda in sé e la sua offerta sarà gestita direttamente da IBM. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 89

90 Introduzione a TCIM La suite Insight costituiva il suo prodotto principale, affiancata dalla suite zsecure, in tutto simile, ma dedicata al mondo mainframe; le due suite erano poi declinate in alcuni prodotti minori e più specifici. Consul era una società di medie dimensioni, sviluppatasi negli anni principalmente attorno a questo software. A luglio 2007 questo software ha debuttato nell'offerta IBM di prodotti legati alla sicurezza con il nome di Tivoli Compliance Insight Manager e numero di versione 8. Questa prima versione di IBM non fornisce sostanziali cambiamenti ed è molto simile alla versione 7 di Consul, ma con il brand IBM Tivoli [TIVOLI]. Da IBM è lecito comunque aspettarsi cambiamenti rilevanti in futuro ed una integrazione sempre maggiore con i propri prodotti, soprattutto quelli della suite Tivoli, nell'ambito di quello che è conosciuto in gergo dagli addetti ai lavori come blue wash. Esso consiste nell'adattamento di una applicazione agli standard IBM e nella sua integrazione con l'offerta del gigante del software, chiamato anche Big Blue. Tra le modifiche che paiono più probabili come risultato del processo ci sono: nuovo approccio multipiattaforma, indipendente dal sistema operativo, sostituzione di Tomcat con Websphere come application server, utilizzo del JRE6 IBM invece di quello Sun Microsystem, supporto ad altri database, verosimilmente ad IBM DB2. E' lecito insomma riporre buone aspettative nel futuro di questo prodotto, almeno dal punto di vista tecnologico. 6 Java Runtime Environment, la macchina virtuale e le librerie java. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 90

91 Introduzione a TCIM 2.5 Architettura I singoli componenti di cui è composta la suite TCIM sono installati in diverse locazioni quando si deve monitorare una rete estesa. Questa architettura prevede un Tivoli Compliance Insight Manager Server primario, più fino a tre altri server di espansione per formare un cluster, ed in agiunta un numero variabile di actuator, installati su altre macchine, a seconda della topologia della rete esistente e delle piattaforme monitorate. I server sono dotati anche delle funzionalità di actuator, pertanto si parla di entrambi come point of presence (POP), punti dai quali è possibile raccogliere i dati dalle macchine sottoposte ad auditing. I dati viaggiano da un POP ad un server del cluster, dove sono elaborati ed immagazzinati. Ogni server di espansione è associato con i propri actuator e li controlla, gestendo indipendentemente un sottoinsieme della rete, relativamente al quale fornisce tutte le normali funzioni di TCIM con la sua interfaccia web iview. Il server primario è invece il nodo deputato a consolidare i dati di tutta la rete comunicando con i server di espansione. La sua interfaccia è l'unica dotata sia della vista iview che di quella Log Manager, dalla quale si può ricercare tra i log di tutta la rete e scaricare i dati originali. E' inoltre il responsabile di ricevere e propagare le modifiche di configurazione effettuate attraverso la console di gestione. Quest'ultima fa parte dell'installazione normale di un server primario, ma è anche installabile ed utilizzabile separatamente, dovunque sia possibile connettersi al cluster. Nonostante i server di TCIM funzionino in cluster, non c'è alcun meccanismo di ridondanza o recupero in caso di fallimento di uno di essi. In una tale situazione Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 91

92 Introduzione a TCIM gli eventuali actuator gestiti dal server inattivo rimangono in attesa ed i log non lasciano le macchine di origine. Illustrazione 7: Architettura di TCIM 2.6 Target Per comprendere la validità dell'offerta di TCIM ed i suoi benefici è necessario tener presente il target al quale questo prodotto è rivolto, ovvero le caratteristiche dei suoi potenziali clienti. Questo prodotto è destinato alle grandi e grandissime imprese, con migliaia di dipendenti e una infrastruttura IT eterogenea. Tra gli utilizzatori della versione 7.0 di Consul vi sono, ad esempio, alcune compagnie tra le Standard & Poor's 500 o con oltre dipendenti. Per una di queste imprese l'obiettivo di conformità alle regolamentazioni è un risultato importante, per cui essa è disposta a sostenere ingenti costi, e la decisione di appoggiarsi ad un software per facilitarne il raggiungimento viene presa dopo lunghe considerazioni delle alternative, con un ben definito processo aziendale. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 92

93 Introduzione a TCIM In organizzazioni così grandi l'installazione di TCIM è un processo lungo anche diversi mesi, che prevede una discreta partecipazione di personale del venditore o di un suo partner. Inoltre è probabile che qualche dipendente dell'azienda cliente frequenti dei corsi di addestramento specifici e che vengano di tanto in tanto utilizzati i servizi di consulenti esterni. E' necessario tenere presente tale aspetto mentre si affronta la tecnologia di questo prodotto, in quanto esso è pensato per essere installato ed usato con il supporto della casa venditrice e non in maniera assolutamente indipendente. 2.7 Opportunità in Italia Ad oggi (2007) la diffusione di Insight sino alla versione 7 non è certamente alta e in Italia particolarmente questa suite risulta praticamente assente, mentre la versione 8 di TCIM è ancora troppo recente per aversi conquistato una clientela. Con il passare del tempo è verosimile che nasca in Italia un mercato per questo prodotto e che, in seguito all'acquisizione da parte di IBM, che ha già una propria presenza e delle imprese partner in Italia, esso possa raggiungere una certa diffusione anche nel nostro paese. In Italia tuttavia il modello di public company non è altrettanto in voga come negli altri paesi industrializzati, specie gli Stati Uniti, e questo fa sì che il problema della buona governance d'impresa e di un corretto e trasparente reporting finanziario sia leggermente meno sentito. Infatti al momento in Italia non ci sono obblighi legislativi relativi all'infrastruttura IT per le imprese quotate sulla borsa nazionale e la domanda di software per la compliance è dunque molto ridotta. Sembra comunque probabile che le nostre imprese e la nostra legislazione calchino le orme di quelle americane e di altri paesi europei, anche se con un po' di ritardo, portando anche le imprese quotate in Italia ad avere qualche obbligo di Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 93

94 Introduzione a TCIM conformità che interessi il loro supporto informatico, in relazione al reporting finanziario. Oltre che dalle aziende quotate anche negli Stati Uniti, la domanda di questo tipo di software proviene inoltre da imprese bancarie, vincolate dall'accordo di Basilea 2 di cui l'italia ha fatto parte e da quelle che cercano una gestione efficiente ed efficace della sicurezza informatica, secondo le best practices individuate dai vari framework e da ISO Queste considerazioni ci portano a pensare che il mercato di questa applicazione non possa che espandersi anche nel nostro paese e che questo si concretizzerà in un'opportunità per le imprese italiane nel settore della consulenza e della sicurezza informatica, per la collaborazione con IBM nella vendita e nel supporto di TCIM. Questo produrrà anche una richiesta di competenza tecnica su questo prodotto e quindi sarà a sua volta un'opportunità per un consulente che voglia apprendere il know how. 3 Meccanismi di recupero dei log Ci sono diverse possibilità per raccogliere ed accentrare i log, con comunicazioni di rete che sfruttano l'infrastruttura TCP/IP esistente; ciò fornisce una discreta flessibilità e facilita il processo di installazione di TCIM. La raccolta viene temporizzata e coordinata dal componente server, il quale segnala agli actuator di sua competenza di procurargli i nuovi dati. I singoli actuator possono utilizzare diversi meccanismi per leggere i dati, quindi si preoccupano di inviare al server i chunk contenenti nuovi dati, ovvero dei segmenti dei log originali contenenti solo le righe non ancora lette, più un riferimento alla loro fonte. Le comunicazioni tra actuator e server avvengono tramite connessioni crittografate. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 94

95 Meccanismi di recupero dei log Per prelevare i log da un POP, si hanno a disposizione le seguenti modalità: raccolta locale: quando i log vengono prelevati direttamente da un actuator installato sulla stessa macchina sottoposta ad auditing, attraverso il filesystem o l'esecuzione di programmi specifici. raccolta remota per sistemi Windows: attraverso delle API di gestione degli eventi proprie di questa piattaforma si possono ottenere i dati attraverso una connessione TCP. raccolta remota con SSH7: dotando TCIM di un account su un server Unix con il demone SSH installato, esso è in grado di collegarsi alla macchina effettuando l'autenticazione con chiavi crittografate asimmetriche e recuperare i log con una serie di comandi shell. ricezione di messaggi Syslog o SNMP8: i pop sono in grado di ricevere direttamente messaggi di questo sistema di logging tipico di Unix, così come quelli del protocollo SNMP. Non si tratta però di un meccanismo molto performante, in grado di gestire ampi volumi di traffico. utilizzo di API specifiche: nel caso non sia possibile prelevare un file di log TCIM può utilizzare chiamate a funzioni specifiche di una certa fonte di eventi. meccanismi personalizzati: nel caso che non sia possibile ottenere i log con nessuna di queste modalità, si può ricorrere ad un meccanismo personalizzato che depositi i file in una cartella del sistema sui cui è attivo l'actuator, ad esempio un upload via FTP9. 7 Secure Shell, strumento di accesso remoto alla riga di comando Unix. 8 Simple Net Management Protocol, protocollo di scambio di semplici informazioni sui sistemi in rete. 9 File Transfer Protocol, meccanismo di trasferimento di file su rete. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 95

96 Il modello W7 per una politica di sicurezza centrale 4 Il modello W7 per una politica di sicurezza centrale Si è parlato di come TCIM consenta un approccio multipiattaforma all'auditing, evitando la necessità di un'analisi spezzettata per ogni singolo componente dell'infrastruttura. Senza un software come questo bisogna interpretare i log delle varie fonti e questo richiede una certa esperienza specifica. Rimane inoltre da correlare i dati che si apprendono, se si vuole avere una visione di insieme su un certo evento e questo può richiedere un notevole sforzo di sincronizzazione tra diverse persone. Illustrazione 8: Auditing senza TCIM TCIM invece permette di semplificare molto questo processo, attraverso una operazione di centralizzazione e normalizzazione dei vari log, ovvero di trasformazione in un formato di linguaggio simil naturale, in inglese, con la conseguente possibilità di individuare correlazioni tra gli eventi in maniera molto più rapida. Alla base di questo processo c'è il cuore della tecnologia di questa suite, che verrà esposta nei prossimi paragrafi in maniera dettagliata. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 96

97 Il modello W7 per una politica di sicurezza centrale Illustrazione 9: Auditing con TCIM 4.2 Il Generalized Event Model Per la gestione degli eventi TCIM usa un modello generalizzato, il Generalized Event Model (GEM), indipendente dal formato all'origine. Dalla lettura dei log si passa attraverso un processo di mappaggio al modello GEM, il quale viene usato come base per tutte le operazioni compiute da TCIM ed è in questo formato che avviene anche il caricamento del suo database. Per descrivere ogni tipo di evento sono sufficienti sette attributi, essi sono: 1. who: l'utente che da inizio all'evento, 2. what: l'azione effettuata, 3. when: collocazione temporale, 4. where: il sistema su cui si verifica l'evento, 5. on what: l'oggetto del sistema su cui viene esercitata l'azione, Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 97

98 Il modello W7 per una politica di sicurezza centrale 6. where from: il sistema origine dell'evento, 7. where to: il sistema a cui è destinata l'azione. Da questa scelta di attributi deriva il nome di metodologia W7, di analisi degli eventi, per la quale è stato depositato un brevetto, attualmente in attesa dell'approvazione finale. Non sempre tutte i sette attributi sono necessari a descrivere un evento, ma non accade mai che dell'informazione significativa venga lasciata fuori nel modello GEM. Illustrazione 10: Mappaggio W7 da log a GEM I log dapprima vengono scomposti nelle diverse parti che costituiscono i singoli attributi, in seguito si procede al mappaggio vero e proprio, per il quale è necessario introdurre il concetto di gruppo. Andrea Ratto Sicurezza intranet ed auditing per aziende ad alto rischio operativo Pag 98