Risk Assessment and Security Test. Information Security Assessment Un Information Security assessment è il processo che determina quanto efficacemente.

Risk Assessment and Security Test

Information Security Assessment

• Un Information Security assessment è il processo che determina quanto efficacemente un’entità (host, sistema, rete, procedure, persone, note come gli assessment object) incontra gli obiettivi di sicurezza. Tre tipi di assessment possono essere condotti:– Il testing, ovvero il processo di esercitare uno o più assessment object

sotto specifiche condizioni per comparare il comportamento reale con quello atteso;

– L’examination, ovvero il processo consistente nel controllare, ispezionare, revisionare, osservare, studiare o analizzare uno o più assessment object per facilitare la comprensione o ottenere evidenze.

– Interviewing, ovvero il processo di condurre discussioni con individui o gruppi all’interno di un’organizzazione per facilitare al comprensione o per ottenere evidenze.

Obiettivi dell’assessment• I risultati di un assessment sono utilizzati per supportare la

determinazione di controlli di sicurezza e per monitorare e valutare la loro efficacia.

• L’assessment che si intende realizzare produrrà, dunque i seguenti documenti:– Una security assessment policy, ovvero identificare i requisiti di sicurezza in

base ai quali stabilire l’assessment e fornire le responsabilità per i ruoli e o gli individui per assicurarsi che tali requisiti siano rispettati

– Una metodologia di assessment che sia documentata e ripetibile, ovvero fornire consistenza e struttura all’assessment, preparare un nuovo staff per l’assessment, identificare tutti i vincoli e le risorse necessarie all’assessment.

– Sviluppare tecniche di risk mitigation, ovvero fornire le soluzioni che possono rimuovere le sorgenti di un rischio, ridurne la probabilità o contenerne l’impatto sugli asset di valore.

Processo di Security Testing

Establishing the Context• Business Context:

– Information Classification – l’informazione ufficiale che è memorizzata, processata e o trasmessa dal sistema informativo deve essere classificata in opportuni livelli di clearances

– Business Processes Supported – i processi di business e gli obiettivi supportati dal sistema informativo. Questo dovrebbe includere ogni processo secondario, dipendente o di supporto.

– Users of the System – i differenti tipi di utilizzatori del sistema informativo. Questo dovrebbe includere il livello di privilegi che loro richiedono per realizzare i loro compiti o per utilizzare il sistema. Gli utenti possono includere gli utenti di business, lo staff di supporto all’esecuzione del processo, e gli utenti esterni di servizi.

– Security and compliance Requirements – i requisiti di confidenizalità, l’integrità, la disponibilità (CIA) e di privacy dell’informazione archiviata, processata o trasmessa dal sistema informativo.

Establishing the Context• Contesto Tecnico

– Service Owner – il responsabile del servizio è colui in grado di identificare i componenti e definire i confini di un sistema informativo che è il raggio di competenza del risk assessment

– Enterprise or Solution Architect – l’Architect è resposabile di identificare i componenti e definire i confini di un sistema informativo che è all’interno della competenza del risk assessment.

– Subject Matter Experts – lo staff responsabile del supporto e della manutenzione del sistema informativo che ricade nella competenza del risk assessment.

• comprensione dell’intero profilo di sicurezza del sistema:– Architettura Logica – una vista a livello di componente e di sistema

dell’architettura logica del sistema informativo. Deve includere i domini di sicurezza dove i componenti del sistema sono localizzati, le interfacce di sistema e i flussi informativi

– System components – i componenti hardware e software che compongono il sistema informativo. Dovrebbe includere tutti i componenti diretti ed indiretti inclusi server, switch, sistemi operativi, applicazioni e basi di dati.

Risk Identification• La Risk Identification cerca di creare una lista completa di eventi che

possono prevenire degradare o ritardare il conseguimento degli obiettivi di business.

• le minacce potenziali ai sistemi informativi è necessario che siano identificate-> scenari di rischio.

<Evento incerto> avviene, conduce a <effetto sull’obiettivo>, come risultato di <definisce la causa>Per esempio: la perdita di un laptop conduce alla potenziale perdita di informazioni ufficiali a beneficio di una terza parte non autorizzata, ad una perdita di reputazione.• Catturare i risk driver è utile quando si identificano e si selezionano i

controlli per gestire il rischio.• Esempio: un rischio può esistere solo perché il sistema informativo si

interfaccia con Internet

Analisi del Rischio

• Dopo che i rischi cono stati identificati, insieme alla probabilità e al loro impatto essi devono essere verificati e avvalorati. Tipicamente la probabilità e l’impatto di un rischio sono valutati attraverso una scala qualitativa. – Risk Scale– Risk Matrix

• L’esatta valutazione del rischio dovrebbe essere realizzata sulla base delle indicazioni del business owner e dei subject matter expert.

Impact Assessment

• L’impatto di un rischio si verifica senza l’installazione di controlli sul campo

• solo un rating può essere assegnato al rischio.

Likelihood assessment

• La probabilità del rischio è verificata senza l’installazione di controlli

• Laddove informazioni sulla storia della frequenza di un incidente dovesse essere disponibile sarà usata per determinare la probablità del rischio

• l’assenza di una simile informazione non necessariamente significa che la probabilità del rischio è bassa

Risk Rating

• valutato utilizzando la risk matrix• Il rischio difficilmente è statico, di

conseguenza questi devono essere aggiunti al registro del rischio e monitorati e ri-verificati

Controls identification e assessment

• Un controllo può ridurre il rischio riducendo la probabilità che l’evento scaturente il rischio si verifichi, l’impatto o entrambi.

• Verificare l’effetto che il controllo ha sull’intero rischio per determinare il residual risk rating

• deterrent e preventive controls riducono la probabilità di un rischio, mentre detective e corrective controls riducono l’impatto

I controlli

I controlli• Deterrent Controls – sono intesi scoraggiare potenziali attacker. Per esempio,

stabilire una politica di sicurezza dell’informazione, un messaggio di allerta sulla schermata di logon, un Kensington lock o videocamere di sicurezza.

• Preventive Controls – sono intesi minimizzare la probabilità di un incidente. Per esempio, un processo di gestione di uno user account, restringere l’accesso alla sala dei server solo a personale autorizzato, configurare appropriate regole su un firewall o implementare una access control list su un file share.

• Detective Controls – sono intesi identificare quando un incidente si è verificato. Per esempio, revisione dei log di un server o di un firewall o gli alert di un Intrusion detection System.

• Corrective Controls – sono intesi riparare i componenti di un sistema informativo dopo che un incidente si è verificato. Per sempio, data backup, Sq transaction log shipping, piani di business continuity e disaster recovery.

• Il residual risk rating è derivato dalla verifica dell’effetto che gli attuali controlli hanno sul gross risk e usando la risk matrix .

• Per esempio:Uno scenario di rischio con la likelihood rating di possibile ma improbabile e impact rating di severo risulterà avere un risk rating di 19. Un controllo attualmente installato è altamente efficace a ridurre l’impatto del rischio. L’impact rating è rivisitato a Moderato con il controllo installato, quindi il residual risk rating è 9

Risk Evaluation

• Dopo aver realizzato la risk analysis i residual risks possono essere confrontati con i livelli di tolleranza

• Residual risks che sono stati verificati essere tra 1 e 3 sono considerati accettabili livello di rischio per il business e non necessitano una ulteriore valutazione

• Tutti i residual risks che sono valutati essere tra 4 e 25 su un rating scale hanno necessità di essere valutati e prioritizzati

Risk Treatment• Evitare – fermare l’attività che causa il rischio, eleminando quindi il

rischio. L’evitare il rischio non è la scelta preferenziale, dal momento che impedisce di cogliere l’opportunità associata al rischio stesso.

• Trattare – implementare controlli per ridurre la probabilità e/o l’impatto del rischio. Il trattamento del rischio è il risk treatment più comune

• Trasferimento – traferire o condividere tutto o parte dell’impatto del rischio con una terza parte. Le tecniche più comuni di trasferimento del rischio sono l’assicurazione e l’outsourcing.

• Accettazione – il business owner può anche scegliere di accettare il rischio. I rischi sono di solito accettati quando essi sono verificati essere all’interno del livello di tolleranza. Comunque possono anche essere accettati quando non è pratico evitarli, trattarli o trasferirli.

Tecniche di assessment• Review: tecniche di analisi usate per valutare sistemi, applicazioni, network,

politiche e procedure per scoprire vulnerabilità e sono condotte generalmente manualmente, con l’ausilio di opportune checklist o con l’ausilio di software predisposti ad identificare e localizzare i punti che possono contenere una vulnerabilità Le review sono rivolte a:– Documentazione– Log– Ruleset– Configurazioni di sistema

• Target identification and analysis: queste tecniche identificano i sistemi, le porte, i servizi e le potenziali vulnerabilità e possono essere realizzate manualmente o con software che automatizzano il processo. Includono:– Network discovery– Network port and service identification,– Vulnerability scanning– Wireless scanning– Application security examination

Tecniche di assessment

• Target Vulnerability Validation: che corroborano l’esistenza delle vulnerabilità e possono essere realizzate sia manulamente che con l’ausilio di tool automatici. Includono:– Password cracking– Penetration testing– Social engineering– Application security testing.

Threat SourcesThreat Group Threat AgentIndividui Impiegati/fornitori

ClientiHackersHacktivistCriminaliTerroristi

Organizzazioni Esterne Service ProviderHactivistGoverni EsteriGruppi di Azioni SponsorizzatiGruppi TerroristiGruppi Criminali Organizzati

Evento Tecnico Codice malevoloCodice difettosoMalfunzionamento delle attrezzaturePerdita di corrente

Eventi Accidentali FuocoDanneggiamento da acquadistruzione

Eventi Naturali MeteoTerremotiEruzioni VulcanicheInondazione

Impact Scale

Likelihood Scale

Risk Matrix

Tecniche di revisione• Document review: questa tecnica determina se vi sono mancanze o debolezze nelle

politiche, nelle procedure o nei controlli. Questa tecnica analizza: politiche, requisiti, architetture, procedure, piani di sicurezza, piani di risposta, la compliance con gli standard adottati.

• Log review: determina se i controlli registrano completamente e correttamente le informazioni e se l’organizzazione implementa le corrette politiche di gestione dei log. Si analizzeranno: system log, server log, autentication server, intrusion detection e prevention system log, firewall e router log, application log, antivirus log, security log.

• Ruleset review: un ruleset è una collezione di regole o di firme che definiscono un attacco. I ruleset possono riguardare: router access control list, firewall ruleset, IDS/IPS

• System configuration review: identifica le vulnerabilità nei controlli di configurazione, come sistemi che non sono stati hardened o configurati secondo le politiche di security.

• Network sniffing: è una tecnica passiva che monitora le comunicazioni di rete, i protocolli, gli header ed i payload dei pacchetti. Gli sniffer verranno installati nelle locazioni che saranno identificate dal piano e che di solito riguardano: il perimetro, in prossimità di firewall e IDS/IPS, su uno specifico segmento di rete, presso un sistema ritenuto critico.

• File integrity checking: queste revisioni garantiscono che un file non sia stato alterato o corrotto, attraverso un confronto con un database di ckecksum.

Security Testing• External viewpoint è realizzato dall’esterno del perimetro di sicurezza

dell’organizzazione.• Le tecniche utilizzate saranno:

– Ricerca di dati pubblici– Raccolta Informazioni DNS– Newsgroup– Enumerazione di dati quali: nomi di sistemi, indirizzi IP, sistemi operativi, punti di

contatto tecnici.– Network discovery e tecniche di scanning per

• Trovare host• Elencare servizi e porte accessibili

– Esercizio di attacchi da FTP, http, SMTP, POP– Server che sono accessibili dall’esterno– Scoprire vulnerabilità nei metodi di accesso, quali wireless access point e portali a

server interni

Internal Viewpoint

• L’ Internal security testing si realizza all’interno del perimetro di sicurezza dell’organizzazione ed assume che l’adversary o l’attacker sia all’interno dell’organizzazione. Si concentra su vulnerabilità legate alla configurazione, o a livello di sistema (vizi di autenticazione, controllo degli accessi, system hardening).

Overt/Covert

• L’ overt security testing, noto anche come white hat testing, coinvolge sia l’internal che l’external testing ed è caratterizzato dal fatto che il tester ha la conoscenza degli assessment object nella loro struttura ed architettura.

• Il covert security testing, noto anche come black hat testing, assume le forme del vero e proprio attacco e si realizza senza usufruire della conoscenza dei sistemi nè del reale supporto dello staff IT. Il risultato di questo test è una vista strategica dei potenziali metodi che possono essere usati per sfruttare le vulnerabilità e dunque una migliore identificazione dei rischi, del loro impatto e della loro probabilità.

Identificazione del target– Network discovery– Network Port e Service identification– Vulnerability Scanner– Wireless Scanning– Bluetooth Scanning

• Validazione delle vulnerabilità– Penetration testing– Password cracking

Penetration Testing