(grazie a Sergey G. Brester per l'idea del titolo )
Colleghi, lo scopo di questo articolo è condividere l'esperienza di un'operazione di test durata un anno di una nuova classe di soluzioni IDS basate su tecnologie Deception.
Per mantenere la coerenza logica della presentazione del materiale ritengo necessario partire dalle premesse. Quindi, il problema:
- Gli attacchi mirati sono il tipo di attacco più pericoloso, nonostante la loro quota sul numero totale di minacce sia piccola.
- Non è stato ancora inventato alcun mezzo efficace garantito per proteggere il perimetro (o un insieme di tali mezzi).
- Di norma gli attacchi mirati si svolgono in più fasi. Il superamento del perimetro è solo una delle fasi iniziali, che (potete lanciarmi delle pietre) non provoca molti danni alla “vittima”, a meno che, ovviamente, non si tratti di un attacco DEoS (Destruction of service) (crittografi, ecc.) .). Il vero “dolore” inizia più tardi, quando le risorse catturate iniziano a essere utilizzate per ruotare e sviluppare un attacco “in profondità”, e noi non ce ne siamo accorti.
- Poiché cominciamo a subire perdite reali quando gli aggressori raggiungono finalmente gli obiettivi dell'attacco (server applicativi, DBMS, data warehouse, repository, elementi critici dell'infrastruttura), è logico che uno dei compiti del servizio di sicurezza informatica sia quello di interrompere gli attacchi prima questo triste evento. Ma per interrompere qualcosa, devi prima scoprirlo. E prima è, meglio è.
- Di conseguenza, per una gestione efficace del rischio (ovvero, per ridurre i danni derivanti da attacchi mirati), è fondamentale disporre di strumenti che forniscano un TTD minimo (tempo di rilevamento - il tempo che intercorre dal momento dell'intrusione al momento in cui viene rilevato l'attacco). A seconda del settore e della regione, questo periodo è in media di 99 giorni negli Stati Uniti, 106 giorni nella regione EMEA, 172 giorni nella regione APAC (M-Trends 2017, A View From the Front Lines, Mandiant).
- Cosa offre il mercato?
- "Sandbox". Un altro controllo preventivo, tutt’altro che ideale. Esistono molte tecniche efficaci per rilevare e aggirare sandbox o soluzioni di whitelist. I ragazzi del “lato oscuro” sono ancora un passo avanti qui.
- UEBA (sistemi per la profilazione del comportamento e l'identificazione delle deviazioni) - in teoria, può essere molto efficace. Ma, secondo me, questo accadrà in un futuro lontano. In pratica, questo è ancora molto costoso, inaffidabile e richiede un’infrastruttura informatica e di sicurezza delle informazioni molto matura e stabile, che disponga già di tutti gli strumenti in grado di generare dati per l’analisi comportamentale.
- Il SIEM è un buon strumento per le indagini, ma non è in grado di vedere e mostrare tempestivamente qualcosa di nuovo e originale, perché le regole di correlazione sono le stesse delle firme.
- Di conseguenza, è necessario uno strumento che:
- ha operato con successo in condizioni di perimetro già compromesso,
- rilevato attacchi riusciti quasi in tempo reale, indipendentemente dagli strumenti e dalle vulnerabilità utilizzate,
- non dipendeva da firme/regole/script/politiche/profili e altri elementi statici,
- non richiedeva grandi quantità di dati e le relative fonti per l'analisi,
- consentirebbe di definire gli attacchi non come una sorta di punteggio di rischio come risultato del lavoro della "matematica migliore al mondo, brevettata e quindi chiusa", che richiede ulteriori indagini, ma praticamente come un evento binario - "Sì, ci stanno attaccando” oppure “No, va tutto bene”,
- era universale, efficientemente scalabile e realizzabile da implementare in qualsiasi ambiente eterogeneo, indipendentemente dalla topologia di rete fisica e logica utilizzata.
Le cosiddette soluzioni di inganno si contendono ora il ruolo di tale strumento. Cioè soluzioni basate sul buon vecchio concetto degli honeypot, ma con un livello di implementazione completamente diverso. Questo argomento è sicuramente in aumento ora.
Secondo i risultati Le soluzioni di inganno sono incluse nelle 3 strategie e strumenti TOP che si consiglia di utilizzare.
A proposito di questo L'inganno è una delle principali direzioni di sviluppo delle soluzioni IDS Intrusion Detection Systems).
Un'intera sezione di quest'ultimo , dedicato allo SCADA, si basa sui dati di uno dei leader di questo mercato, TrapX Security (Israele), la cui soluzione lavora nella nostra area di prova da un anno.
TrapX Deception Grid consente di quantificare i costi e gestire centralmente IDS distribuiti in modo massiccio, senza aumentare il carico di licenze e i requisiti per le risorse hardware. In effetti, TrapX è un costruttore che consente di creare da elementi dell'infrastruttura IT esistente un grande meccanismo per rilevare attacchi su scala aziendale, una sorta di "allarme" di rete distribuita.
Struttura della soluzione
Nel nostro laboratorio studiamo e testiamo costantemente diverse novità nel campo della sicurezza informatica. Attualmente qui vengono distribuiti circa 50 diversi server virtuali, inclusi i componenti di TrapX Deception Grid.
Quindi, dall'alto verso il basso:
- TSOC (TrapX Security Operation Console) è il cervello del sistema. Questa è la console di gestione centrale attraverso la quale vengono eseguite la configurazione, l'implementazione della soluzione e tutte le operazioni quotidiane. Poiché si tratta di un servizio Web, può essere distribuito ovunque: sul perimetro, nel cloud o presso un provider MSSP.
- TrapX Appliance (TSA) è un server virtuale al quale colleghiamo, utilizzando la porta trunk, le sottoreti che vogliamo coprire con il monitoraggio. Inoltre, tutti i nostri sensori di rete “vivono” effettivamente qui.
Nel nostro laboratorio è presente un TSA (mwsapp1), ma in realtà potrebbero essercene molti. Ciò può essere necessario in reti di grandi dimensioni dove non esiste connettività L2 tra segmenti (un esempio tipico è “Holding e controllate” o “Sede e filiali della banca”) o se la rete ha segmenti isolati, ad esempio sistemi automatizzati di controllo dei processi. In ciascuno di questi rami/segmenti è possibile distribuire la propria TSA e collegarla a un singolo TSOC, dove tutte le informazioni verranno elaborate centralmente. Questa architettura consente di realizzare sistemi di monitoraggio distribuiti senza la necessità di ristrutturare radicalmente la rete o interrompere la segmentazione esistente.
Inoltre, possiamo inviare una copia del traffico in uscita alla TSA tramite TAP/SPAN. Se rileviamo connessioni con botnet conosciute, server di comando e controllo o sessioni TOR, riceveremo anche il risultato nella console. Ne è responsabile il Network Intelligence Sensor (NIS). Nel nostro ambiente questa funzionalità è implementata sul firewall, quindi non l'abbiamo utilizzata qui.
- Trap delle applicazioni (sistema operativo completo): honeypot tradizionali basati su server Windows. Non ne servono molti, poiché lo scopo principale di questi server è fornire servizi IT al livello successivo di sensori o rilevare attacchi alle applicazioni aziendali che potrebbero essere implementate in un ambiente Windows. Abbiamo uno di questi server installato nel nostro laboratorio (FOS01)
- Le trappole emulate sono la componente principale della soluzione, che ci consente, utilizzando un'unica macchina virtuale, di creare un “campo minato” molto denso per gli aggressori e di saturare la rete aziendale, tutti i suoi vlan, con i nostri sensori. L'aggressore vede un tale sensore, o host fantasma, come un vero PC o server Windows, un server Linux o altro dispositivo che decidiamo di mostrargli.
Per il bene dell'azienda e per curiosità, abbiamo implementato "una coppia di ogni creatura": PC e server Windows di varie versioni, server Linux, un bancomat con Windows integrato, SWIFT Web Access, una stampante di rete, un Cisco interruttore, una telecamera IP Axis, un MacBook, un dispositivo PLC e persino una lampadina intelligente. Ci sono 13 host in totale. In generale, il venditore consiglia di utilizzare tali sensori in una quantità pari ad almeno il 10% del numero di host reali. La barra superiore è lo spazio degli indirizzi disponibile.Un punto molto importante è che ciascuno di questi host non è una macchina virtuale a tutti gli effetti che richiede risorse e licenze. Si tratta di un'esca, un'emulazione, un processo sulla TSA, che ha una serie di parametri e un indirizzo IP. Pertanto, con l’aiuto anche di una sola TSA, possiamo saturare la rete con centinaia di host fantasma, che funzioneranno come sensori nel sistema di allarme. È questa tecnologia che rende possibile la scalabilità economicamente vantaggiosa del concetto di honeypot in qualsiasi grande azienda distribuita.
Dal punto di vista di un aggressore, questi host sono attraenti perché contengono vulnerabilità e sembrano essere bersagli relativamente facili. L'aggressore vede i servizi su questi host e può interagire con essi e attaccarli utilizzando strumenti e protocolli standard (smb/wmi/ssh/telnet/web/dnp/bonjour/Modbus, ecc.). Ma è impossibile utilizzare questi host per sviluppare un attacco o eseguire il proprio codice.
- La combinazione di queste due tecnologie (FullOS e trap emulate) ci consente di ottenere un'elevata probabilità statistica che un utente malintenzionato prima o poi incontri qualche elemento della nostra rete di segnalazione. Ma come possiamo essere sicuri che questa probabilità sia vicina al 100%?
I cosiddetti gettoni Inganno entrano in battaglia. Grazie a loro possiamo includere tutti i PC e i server aziendali esistenti nei nostri IDS distribuiti. I token vengono posizionati sui PC reali degli utenti. È importante capire che i token non sono agenti che consumano risorse e possono causare conflitti. I token sono elementi informativi passivi, una sorta di “briciole di pane” per la parte attaccante che la trascinano in una trappola. Ad esempio, unità di rete mappate, segnalibri di falsi amministratori web nel browser e password salvate per loro, sessioni ssh/rdp/winscp salvate, le nostre trappole con commenti nei file host, password salvate in memoria, credenziali di utenti inesistenti, file, l'apertura che attiverà il sistema e molto altro ancora. Inseriamo quindi l’aggressore in un ambiente distorto, saturo di vettori di attacco che in realtà non rappresentano una minaccia per noi, ma piuttosto il contrario. E non ha modo di determinare dove l'informazione è vera e dove è falsa. Pertanto, non solo garantiamo il rilevamento rapido di un attacco, ma ne rallentiamo anche significativamente il progresso.
Un esempio di creazione di una trappola di rete e configurazione dei token. Interfaccia amichevole e nessuna modifica manuale di configurazioni, script, ecc.
Nel nostro ambiente, abbiamo configurato e posizionato un certo numero di token di questo tipo su FOS01 con Windows Server 2012R2 e su un PC di prova con Windows 7. RDP è in esecuzione su queste macchine e periodicamente li "appendiamo" nella DMZ, dove un certo numero dei nostri sensori Vengono visualizzati anche i trap emulati. Quindi riceviamo un flusso costante di incidenti, per così dire, naturalmente.
Quindi, ecco alcune rapide statistiche per l’anno:
56 – incidenti registrati,
2: rilevati host di origine dell'attacco.
Mappa di attacco interattiva e cliccabile
Allo stesso tempo, la soluzione non genera alcun tipo di mega-log o feed di eventi, la cui comprensione richiede molto tempo. Invece, la soluzione stessa classifica gli eventi in base al tipo e consente al team di sicurezza informatica di concentrarsi principalmente su quelli più pericolosi, quando l'aggressore tenta di aumentare le sessioni di controllo (interazione) o quando nel nostro traffico compaiono payload binari (infezione).
Tutte le informazioni sugli eventi sono leggibili e presentate, a mio avviso, in una forma di facile comprensione anche per un utente con conoscenze di base nel campo della sicurezza informatica.
La maggior parte degli incidenti registrati sono tentativi di scansione dei nostri host o di singole connessioni.
Oppure tenta di forzare le password per RDP
Ma ci sono stati anche casi più interessanti, soprattutto quando gli aggressori “sono riusciti” a indovinare la password per RDP e ad accedere alla rete locale.
Un utente malintenzionato tenta di eseguire codice utilizzando psexec.
L'aggressore ha trovato una sessione salvata che lo ha portato in una trappola sotto forma di un server Linux. Immediatamente dopo la connessione, con una serie di comandi pre-preparati, ha tentato di distruggere tutti i file di registro e le corrispondenti variabili di sistema.
Un utente malintenzionato tenta di eseguire l'SQL injection su un honeypot che imita SWIFT Web Access.
Oltre a questi attacchi “naturali”, abbiamo condotto anche una serie di nostri test. Uno dei più rivelatori è testare il tempo di rilevamento di un worm di rete su una rete. Per fare ciò abbiamo utilizzato uno strumento di GuardiCore chiamato . Si tratta di un worm di rete in grado di dirottare Windows e Linux, ma senza alcun “carico utile”.
Abbiamo implementato un centro di comando locale, lanciato la prima istanza del worm su una delle macchine e ricevuto il primo avviso nella console TrapX in meno di un minuto e mezzo. TTD 90 secondi contro 106 giorni in media...
Grazie alla capacità di integrazione con altre classi di soluzioni, possiamo passare dal semplice rilevamento rapido delle minacce alla risposta automatica ad esse.
Ad esempio, l'integrazione con sistemi NAC (Network Access Control) o con CarbonBlack consentirà di disconnettere automaticamente dalla rete i PC compromessi.
L'integrazione con sandbox consente di inviare automaticamente i file coinvolti in un attacco per l'analisi.
Integrazione McAfee
La soluzione dispone inoltre di un proprio sistema di correlazione degli eventi integrato.
Ma non eravamo soddisfatti delle sue capacità, quindi l'abbiamo integrato con HP ArcSight.
Il sistema di ticketing integrato aiuta il mondo intero a far fronte alle minacce rilevate.
Poiché la soluzione è stata sviluppata “dall'inizio” per le esigenze delle agenzie governative e di un grande segmento aziendale, implementa naturalmente un modello di accesso basato sui ruoli, l'integrazione con AD, un sistema sviluppato di report e trigger (avvisi di eventi), orchestrazione per grandi strutture holding o fornitori di MSSP.
Invece di un curriculum
Se esiste un tale sistema di monitoraggio che, in senso figurato, ci copre le spalle, allora con la compromissione del perimetro tutto è solo all'inizio. La cosa più importante è che esista una reale opportunità di affrontare gli incidenti legati alla sicurezza informatica e non di affrontarne le conseguenze.
Fonte: habr.com