(un ringraziamento per l'idea del titolo a Sergey G. Brester )
Colleghi, l'obiettivo di questo articolo è condividere l'esperienza di un anno di test sul nuovo approccio alle soluzioni IDS basato sulle tecnologie di Deception.
Per mantenere la coerenza logica del materiale, ritengo necessario partire dalle premesse. Quindi, il problema:
- Gli attacchi mirati sono la tipologia di attacco più pericolosa, nonostante la loro incidenza sia relativamente bassa rispetto al numero complessivo delle minacce.
- Attualmente, non esiste un mezzo di protezione garantito ed efficace per il perimetro (o una combinazione di tali mezzi).
- In generale, gli attacchi mirati si svolgono in più fasi. Superare il perimetro è solo una delle fasi iniziali, che (potete lanciarmi pietre) non provoca danni significativi per la 'vittima', a meno che non si tratti di attacchi DEoS (Destruction of service), come i ransomware, ecc. Il vero danno inizia dopo, quando le risorse compromesse vengono utilizzate per il pivoting e lo sviluppo dell'attacco 'in profondità', e noi non ce ne accorgiamo.
- Poiché iniziamo a subire perdite reali solo quando i malintenzionati riescono a colpire gli obiettivi dell'attacco (server applicativi, database, archivi di dati, repository, elementi di infrastruttura critica), è logico che uno degli obiettivi del servizio di sicurezza informatica sia fermare gli attacchi prima che si verifichino eventi disastrosi. Ma per fermare qualcosa, dobbiamo prima saperlo. E prima si interviene, meglio è.
- Di conseguenza, per una gestione efficace dei rischi (cioè, per ridurre i danni causati da attacchi mirati) è fondamentale disporre di strumenti che garantiscano un TTD minimo (time to detect – tempo dall'intrusione alla rilevazione dell'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 che è lontano dall'ideale. Ci sono molte tecniche efficaci per rilevare e aggirare le sandbox o le soluzioni di whitelisting. Gli attaccanti qui sono ancora un passo avanti.
- UEBA (sistemi di profilazione comportamentale e rilevamento delle anomalie) può teoricamente essere molto efficace. Tuttavia, a mio avviso, ciò è qualcosa che potrebbe avvenire solo in un futuro lontano. Nella pratica, al momento è molto costoso, inaffidabile e richiede un'infrastruttura IT e di sicurezza molto matura e stabile, in cui sono già presenti tutti gli strumenti necessari per generare dati per l'analisi comportamentale.
- SIEM è uno strumento utile per le indagini, ma non è in grado di rilevare e mostrare qualcosa di nuovo e originale in tempo, poiché le regole di correlazione sono essenzialmente le stesse firme.
- Di conseguenza, è emersa la necessità di uno strumento che:
- funzioni efficacemente in condizioni di perimetro già compromesso,
- rilevi attacchi riusciti in tempo quasi reale, indipendentemente dagli strumenti e dalle vulnerabilità utilizzate,
- non dipenda da firme / regole / scenari / politiche / profili e altre cose statiche,
- non richieda grandi moli di dati e le loro fonti per l'analisi,
- permetterebbe di definire gli attacchi non come una sorta di scoring del rischio come risultato di una "matematica chiusa e brevettata, considerata la migliore al mondo", che richiede ulteriori indagini, ma praticamente come un evento binario: "Sì, siamo sotto attacco" oppure "No, va tutto bene".
- era universale, scalabile ed effettivamente implementabile in qualsiasi ambiente eterogeneo, indipendentemente dalla topologia di rete fisica e logica utilizzata.
Le soluzioni di deception stanno attualmente emergendo come potenziali strumenti. Si tratta di soluzioni basate su un'antica e consolidata concettualizzazione dei honeypot, ma con un livello di implementazione completamente diverso. Questo tema è senza dubbio in crescita.
In base ai risultati Le soluzioni di deception occupano il posto tra le prime tre strategie e strumenti raccomandati da applicare.
Secondo il rapporto La deception è una delle direzioni principali nello sviluppo delle soluzioni di IDS (Intrusion Detection Systems).
Un'intera sezione dell'ultimo , dedicata a SCADA, è basata sui dati di uno dei leader del mercato, TrapX Security (Israele), le cui soluzioni sono già operative da un anno nella nostra area di test.
TrapX Deception Grid consente di costruire e gestire massicci IDS distribuiti in modo centralizzato, senza aumentare il carico delle licenze e i requisiti delle risorse hardware. In pratica, TrapX è un costruttore che permette di creare da elementi dell'infrastruttura IT esistente un grande meccanismo di rilevamento degli attacchi su scala aziendale, una sorta di 'allerta' di rete distribuita.
Struttura della Soluzione
Nel nostro laboratorio stiamo costantemente esplorando e testando le ultime novità nel campo della sicurezza IT. Attualmente sono attivi 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 configurati, distribuiti e gestiti tutti i lavori quotidiani della soluzione. Poiché si tratta di un servizio web, può essere distribuito ovunque – nel perimetro, nel cloud o presso il fornitore di MSSP.
- TrapX Appliance (TSA) – un server virtuale a cui colleghiamo, tramite una porta trunk, le sottoreti che desideriamo monitorare. Qui risiedono effettivamente tutti i nostri sensori di rete.
Nella nostra laboratorio è stato implementato un TSA (mwsapp1), ma in realtà possono esserci molti. Questo può essere utile in reti di grandi dimensioni, dove non c'è connettività L2 tra i segmenti (un esempio tipico è "Gruppo e sussidiarie" o "Sede principale di una banca e filiali") oppure se nella rete ci sono segmenti isolati, come l'ASUTP. In ogni filiale/sezione è possibile implementare il proprio TSA e collegarlo a un unico TSOC, dove tutte le informazioni saranno elaborate centralmente. Questa architettura consente di costruire sistemi di monitoraggio distribuiti senza dover riprogettare radicalmente la rete o violare la segmentazione esistente.
Inoltre, su TSA possiamo inviare una copia del traffico in uscita tramite TAP/SPAN. In caso di rilevamento di connessioni a noti botnet, server di comando o sessioni TOR, riceveremo anche i risultati nella console. Questo è responsabilità del Network Intelligence Sensor (NIS). Nella nostra ambientazione, questa funzionalità è implementata sul firewall, quindi qui non è stata utilizzata.
- Application Traps (Full OS) – tradizionali honeypots basati su server Windows. Non ne servono molti, poiché l'obiettivo principale di questi server è fornire servizi IT al livello successivo di sensori o rilevare attacchi su applicazioni business che possono essere distribuite in un ambiente Windows. Nel nostro laboratorio è installato un server di questo tipo (FOS01).
- Emulated traps – il componente principale della soluzione, che ci consente attraverso una sola macchina virtuale di creare un denso 'campo minato' per gli attaccanti e saturare la rete aziendale, tutti i suoi VLAN, con i nostri sensori. L'attaccante vede tale sensore, o host fantasma, come un vero PC o server Windows, server Linux o altro dispositivo che decidiamo di mostrargli.
Per utilità e curiosità, abbiamo implementato "due di ogni specie" — PC Windows e server di varie versioni, server Linux, un bancomat con Windows embedded, SWIFT Web Access, una stampante di rete, uno switch Cisco, una telecamera IP Axis, un MacBook, un dispositivo PLC e anche una lampadina smart. In totale, ci sono 13 host. In generale, il fornitore raccomanda di implementare tali sensori in un numero minimo del 10% rispetto al numero reale di host. Il limite superiore è lo spazio indirizzabile disponibile.Un aspetto molto importante è che ogni host di questo tipo non è una macchina virtuale completa, che richiede risorse e licenze. È un "inganno", un'emulazione, un processo su TSA, che ha un insieme di parametri e un indirizzo IP. Pertanto, anche con un solo TSA possiamo saturare la rete con centinaia di tali host fantasma, che funzioneranno come sensori nel sistema di allerta. Questa tecnologia consente di scalare in modo economicamente efficace il concetto di "honeypots" su scala di qualsiasi grande impresa distribuita.
Questi host sono attraenti per un attaccante, poiché presentano vulnerabilità e sembrano obiettivi relativamente facili. L'attaccante vede i servizi su questi host e può interagire con essi, attaccarli utilizzando strumenti e protocolli standard (smb/wmi/ssh/telnet/web/dnp/bonjour/Modbus, ecc.). Tuttavia, non è possibile utilizzare questi host per sviluppare un attacco o eseguire il proprio codice.
- La combinazione di queste due tecnologie (FullOS e trappole emulate) consente di raggiungere un'alta probabilità statistica che l'attaccante, prima o poi, si imbatta in un elemento della nostra rete di segnali. Ma come possiamo fare in modo che questa probabilità si avvicini al 100%?
Entrano in gioco i cosiddetti token (Deception tokens). Grazie a loro, possiamo includere nel nostro IDS distribuito tutti i PC e server disponibili nell'azienda. I token sono collocati su 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 gli aggressori, che li conducono in una trappola. Ad esempio, unità di rete collegate, segnalibri a false web interfacce nel browser e password salvate per accedervi, sessioni ssh/rdp/winscp memorizzate, le nostre trappole con commenti nei file hosts, password memorizzate in memoria, credenziali di utenti inesistenti, file di ufficio il cui accesso attiverebbe il sistema e molto altro. Così facendo, mettiamo l'aggressore in un ambiente distorto, saturato da vettori di attacco che in realtà non rappresentano una minaccia per noi, anzi, il contrario. E non ha alcuna possibilità di determinare dove si trova l'informazione vera e dove quella falsa. In questo modo, non solo garantiamo un rapido riconoscimento degli attacchi, ma ne rallentiamo notevolmente l'andamento.
Esempio di creazione di un network trap e configurazione dei token. Interfaccia user-friendly senza necessità di modifiche manuali ai file di configurazione, script, ecc.
Nel nostro ambiente, abbiamo configurato e distribuito una serie di tali token su FOS01 con Windows Server 2012R2 e su un PC di prova con Windows 7. Su queste macchine sono attivi RDP e periodicamente "pubblichiamo" i token nella DMZ, dove sono presenti anche vari nostri sensori (emulated traps). In questo modo, otteniamo un flusso costante di incidenti, così da avere un andamento naturale.
Ecco alcune statistiche riassuntive per l'anno:
56 208 – incidenti registrati,
2 912 – fonti di attacco rilevate.
Mappa interattiva e cliccabile degli attacchi
Il sistema non genera un mega-log o un lungo feed di eventi, che richiederebbe tempo per essere analizzato. Invece, il sistema classifica automaticamente gli eventi per tipologia e consente al team di sicurezza informatica di concentrarsi prima di tutto sui più pericolosi – quando l'aggressore sta tentando di stabilire sessioni di controllo (interaction) o quando nel nostro traffico appaiono payload binari (infection).
Tutte le informazioni sugli eventi sono leggibili e, secondo me, presentate in modo comprensibile anche per un utente con conoscenze di base in materia di sicurezza informatica.
La maggior parte degli incidenti registrati consiste in tentativi di scansione dei nostri host o connessioni singole.
O tentativi di brute forcing per RDP.
Tuttavia, ci sono stati casi più interessanti, specialmente quando gli attaccanti riuscivano a indovinare una password per RDP e ottenere accesso alla rete locale.
L'attaccante cerca di eseguire codice tramite psexec.
L'attaccante ha trovato una sessione salvata che lo ha portato in una trappola sotto forma di server Linux. Subito dopo la connessione, con un insieme di comandi preimpostati, ha tentato di distruggere tutti i file di log e le relative variabili di sistema.
L'attaccante sta tentando di eseguire un'iniezione SQL su una trappola che imita l'accesso web SWIFT.
Oltre a tali attacchi 'naturali', abbiamo condotto anche una serie di test interni. Uno dei più indicativi è stato il test del tempo di rilevamento di un worm di rete. Per questo, abbiamo utilizzato uno strumento di GuardiCore chiamato . Si tratta di un worm di rete capace di colpire sia Windows che Linux, ma senza alcun tipo di 'payload' utile.
Abbiamo avviato un centro operativo locale, su una delle macchine abbiamo lanciato il primo esemplare del worm e ricevuto la prima notifica nella console di TrapX in meno di un minuto e mezzo. TTD 90 secondi contro una media di 106 giorni...
Grazie alla possibilità di integrazione con altre classi di soluzioni, possiamo passare da un rilevamento rapido delle minacce a una risposta automatica.
Ad esempio, l'integrazione con sistemi NAC (Network Access Control) o con CarbonBlack consentirà di disconnettere automaticamente i PC compromessi dalla rete.
L'integrazione con le sandbox consente di inviare automaticamente per l'analisi i file coinvolti nell'attacco.
Integrazione con McAfee
Inoltre, la soluzione include un proprio sistema integrato di correlazione degli eventi.
Ma le sue funzionalità non ci hanno soddisfatto, quindi l'abbiamo integrata con HP ArcSight.
Affrontare le minacce rilevate 'tutti insieme' è agevolato da un sistema di ticketing integrato.
Poiché la soluzione "fin dall'inizio" è stata sviluppata per le esigenze delle amministrazioni pubbliche e del grande segmento aziendale, è stata naturalmente implementata un modello di accesso basato sui ruoli, integrazione con AD, un sistema di reportistica avanzato e trigger (notifiche degli eventi), orchestrazione per grandi strutture holding o fornitori MSSP.
Invece del riassunto
Se esiste un sistema di monitoraggio simile, che, in senso figurato, ci protegge le spalle, allora la compromissione del perimetro è solo l'inizio. La cosa più importante è che si crea una reale possibilità di combattere gli incidenti di sicurezza informatica, invece di occuparsi di eliminare le loro conseguenze.
Fonte: habr.com
