L’obiettivo principale di qualsiasi tecnica di individuazione delle minacce è sviluppare un formale processo identificativo, documentando e mitigando le minacce alla sicurezza.
Questo ha un enorme impatto su qualsiasi organizzazione perché è fondamentalmente un metodologia utilizzata per capire come possono avvenire gli attacchi e come si verificheranno gli impatti sulla rete, sui sistemi e sugli utenti. Le organizzazioni ne hanno adottati diversi tecniche di modellazione delle minacce.
Ad esempio, Microsoft utilizza il modello DREAD.
(Riferimento Microsoft)
L’acronimo DREAD definisce cinque aree chiave:
Damage – how bad would an attack be? (quanto grave sarebbe l’attacco)
Reproducibility – how easy is it to reproduce the attack? (quanto è facile riprodurre l’attacco)
Exploitability – how much work is it to launch the attack? (quanto lavoro richiede l’attacco)
Affected users – how many people will be impacted? (quante persone saranno interessate )
Discoverability – how easy is it to discover the threat? (quanto è facile scoprire la minaccia)
Un’altra tecnica di modellazione delle minacce molto popolare è STRIDE, che sta per,
Spoofing:
Identificare lo spoofing. Gli aggressori possono (travestirsi) da qualcun altro.
Possono anche mascherare i loro sistemi come altri sistemi. Ad esempio, in molti denial-of-service distribuiti (DDoS) gli aggressori possono falsificare l’origine degli attacchi (ovvero l’IP gli indirizzi delle macchine o dei bot attaccanti) per effettuare l’attacco e mantenere l’anonimato.
Questo è il motivo per cui i sistemi dovrebbero avere una protezione contro gli attacchi di spoofing e non solo per DDoS. In generale, gli utenti non dovrebbe essere in grado di diventare altri utenti o assumere gli attributi di altri utenti.
Tempering:
Gli utenti non devono essere in grado di manomettere dati, applicazioni o sistemi. Nella prevenzione delle minacce, è necessario comprendere quali minacce potrebbero consentire un utente malintenzionato per manomettere dati, applicazioni o sistemi nell’organizzazione.
Repudiation:
è necessario considerare se il sistema o le applicazioni richiedono controlli, come log di sistema, log di accesso web e audit dei percorsi. Un’altra considerazione è che un’applicazione dovrebbe essere eseguita con i privilegi utente, non di più.
Information disclosure:
è necessario assicurarsi che un sistema o un’applicazione non divulghi informazioni non intenzionali. Ad esempio, un file web non deve memorizzare nomi utente e password nella sua origine. Anche, le credenziali dell’utente non devono essere archiviate nei log o in qualsiasi altra configurazione o funzionalità in formato non criptato.
Denial of service:
è necessario valutare quali minacce possono causare una condizione di denialof-service. Questo va oltre il semplice test delle prestazioni e dovrebbe impiegare metodologie come il fuzzing (invio di dati casuali a un file applicazione o protocollo).
Elevation of privilege:
è molto importante garantire a qualsiasi applicazione o sistema che gli utenti non possono elevare i propri privilegi. Molte le organizzazioni sviluppano una matrice di autorizzazione per garantire che utenti e ruoli autorizzati possono accedere a una funzionalità privilegiate.
Definizione e analisi dei vettori di attacco.
Secondo il NIST, un vettore di attacco è “un segmento dell’intero percorso che un l’attacco utilizza per accedere a una vulnerabilità. Ogni vettore di attacco può essere pensato come fonte di contenuto dannoso, un processore potenzialmente vulnerabile ad esempio. Di seguito sono riportati alcuni esempi di vettori di attacco:
Un allegato e-mail dannoso o un collegamento dannoso in un’e-mail.
Contenuto dannoso di una pagina web, un servizio di rete vulnerabile o compromesso utilizzato in modo dannoso.
L’ ingegneria sociale effettuata di persona o da telefono, e-mail, testo o messaggistica istantanea per ottenere informazioni sensibili, dati utente, credenziali, data di nasciata, informazioni sull’account, numeri di previdenza sociale e cosi via. Le informazioni raccolte possono inseguito servire per sferrare un attacco. Una porta aperta su un sistema che potrebbe portare all’esposizione dei servizi da parte di un aggressore. Un database con credenziali predefinite o senza. Un dispositivo dell’infrastruttura con credenziali predefinite o facilmente individuabili. Molti altri termini vengono utilizzati quando si descrivono i vettori di attacco. Inoltre studiare e comprendere i vettori di attacco significa analizzare tutti i vettori di attacco direttamente contro un particolare sistema. Questa metodologia è spesso indicata come la “attack surface” del sistema.
Per misurare e comprendere la superficie di attacco, puoi leggere il file codice sorgente di un’applicazione e identificare diversi punti di ingresso e di uscita, compreso quanto segue:
•Interfacce di programmazione dell’applicazione (API)
•Database
•E-mail o altri tipi di messaggi
•File
•Altri dischi locali
•Argomenti di runtime Moduli e campi dell’interfaccia utente (UI)
È importante capire che il numero totale di voci di attacco diverse o i punti di uscita possono essere numerati in dozzine, centinaia o anche migliaia, a seconda della complessità del sistema o dell’applicazione. A volte questo si sentirà come un compito ingestibile. Per rendere questo compito più gestibile, tu può suddividere il modello in diverse categorie, a seconda della funzione, design e tecnologia. Ecco alcuni esempi:
- Admin interfaces
- Business workflows
- Data entry (CRUD) forms
- Inquiries and search functions
- Interfaces with other applications/systems
- Login/authentication entry points
- Operational command and monitoring interfaces/APIs
- Transactional interfaces/APIs
Diversi strumenti possono accelerare l’analisi della superficie di attacco complessiva di un file sistema o applicazione. Questi includono scanner di rete e di vulnerabilità come comei
seguenti:
•Nmap
•Nessus
•Nexpose
•Qualys
Possono essere usati anche I seguiti per le applicazioni web:
•OWASP_Zed_Attack_Proxy_Project
•Arachni
•Skipfish
•w3af Several commercial dynamic testing and vulnerability scanning tools such as IBM AppScan
Comprendere la complessità di un attacco.
La complessità di un attacco descrive le condizioni al di fuori del controllo dell’aggressore che deve esistere per sfruttare una determinata vulnerabilità.
Ad esempio, l’autore dell’attacco potrebbe dover raccogliere ulteriori informazioni sul bersaglio, tra cui topologie di rete, configurazioni di sistema specifiche e calcolo delle eccezioni. Le metriche di base del Common Vulnerability Scoring System (CVSS) analizzare la complessità dell’attacco. CVSS è uno standard del settore gestito dal Forum of Incident Response and Security Teams (FIRST) che viene utilizzato da molti team di risposta agli incidenti di sicurezza (PSIRT) per trasmettere informazioni su la gravità delle vulnerabilità che rivelano ai propri clienti.
La complessità dell’attacco è classificata come bassa quando non esistono condizioni o circostanze attenuanti per uno specifico accesso.
Quando la complessità è bassa, l’attaccante o l‘autore della minaccia può eseguire l’attacco in un file in modo coerente e ripetibile.
Quando viene considerata la complessità dell’attacco alto, l’attacco dipende da condizioni al di fuori del controllo dell’attaccante. Per istanza, un attacco riuscito probabilmente non può essere eseguito con successo senza che l’aggressore debba investire tempo e sforzo nella preparazione e orchestrazione dell’attacco. Ecco alcuni esempi:
•La necessità per l’aggressore di ottenere informazioni di configurazione aggiuntive, numeri di sequenze e credenziali.
•La necessità per un attaccante di “vincere” con tecniche avanzate di mitigazione degli exploit.
La necessità per l‘autore della minaccia di mettersi nel percorso di rete tra la vittima e la destinazione (M-in-M) o la risorsa alla quale la vittima sta tentando di accedere.
Privilegi e interazione con l’utente.
Il rischio di una minaccia o vulnerabilità specifica può aumentare a seconda di requisiti relativi ai privilegi e all’interazione dell’utente, in altre parole, a seconda se l’aggressore deve disporre delle credenziali utente prima di lanciare con successo l’attacco o se l’aggressore può lanciare l’attacco senza autenticazione. Il rischio è considerato basso se l’attaccante deve averlo privilegi o credenziali di sistema sul sistema per lanciare l’attacco. Al contrario, il rischio è alto se l’attacco non richiede che l’attaccante sia autenticato o avere un controllo significativo (ad esempio, amministrativo) sul sistema vulnerabile. CVSS versione 3 include anche i requisiti dei privilegi nella sua base metrica.
La portata dell’attacco.
È anche importante comprendere l’ambito dell’attacco e come un attacco o la vulnerabilità può avere un impatto sulle risorse al di là dei mezzi o dei privilegi dell’aggressore. L’ambito dell’attacco è rappresentato anche in CVSS dalla metrica di base Autorizzazione Scope, o semplicemente Scope. CVSS definisce l’ambito come “quando la vulnerabilità di un componente software regolato da un ambito di autorizzazione è in grado di influenzare risorse governate da un altro ambito di autorizzazione.” Un buon esempio di modifica dell’ambito è quando un utente malintenzionato è in grado “partire” un file in una sandbox.
Un altro esempio è quando un utente malintenzionato può eseguire una macchina virtuale (VM) In altre parole, quando l’attaccante compromette una VM e quindi è in grado di accedere, modificare o eliminare file sull’host operativo sistema (hypervisor), ottenendo così l’accesso a tutte le VM sulla macchina host.