La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Risk Assessment and Security Test

Presentazioni simili


Presentazione sul tema: "Risk Assessment and Security Test"— Transcript della presentazione:

1 Risk Assessment and Security Test

2 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.

3 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.

4 Processo di Security Testing

5 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.

6 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.

7 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

8 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.

9 Impact Assessment L’impatto di un rischio si verifica senza l’installazione di controlli sul campo solo un rating può essere assegnato al rischio.

10 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

11 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

12 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

13 I controlli

14 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.

15 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

16 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

17 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.

18 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

19 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.

20 Threat Sources Threat Group Threat Agent Individui Impiegati/fornitori
Clienti Hackers Hacktivist Criminali Terroristi Organizzazioni Esterne Service Provider Hactivist Governi Esteri Gruppi di Azioni Sponsorizzati Gruppi Terroristi Gruppi Criminali Organizzati Evento Tecnico Codice malevolo Codice difettoso Malfunzionamento delle attrezzature Perdita di corrente Eventi Accidentali Fuoco Danneggiamento da acqua distruzione Eventi Naturali Meteo Terremoti Eruzioni Vulcaniche Inondazione

21 Impact Scale

22 Likelihood Scale

23 Risk Matrix

24 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.

25 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

26 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).

27 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à.

28 Identificazione del target
Network discovery Network Port e Service identification Vulnerability Scanner Wireless Scanning Bluetooth Scanning Validazione delle vulnerabilità Penetration testing Password cracking

29 Penetration Testing


Scaricare ppt "Risk Assessment and Security Test"

Presentazioni simili


Annunci Google