(per l'idea del titolo grazie a Sergey G. Brester )
Colleghi, l'obiettivo di questo articolo è condividere l'esperienza di un anno di test operativo di una nuova classe di soluzioni IDS basate su tecnologie di Deception.
Per mantenere la coerenza logica nell'esposizione del materiale, ritengo sia opportuno iniziare dalle premesse. Dunque, il problema:
- Gli attacchi mirati sono il tipo di attacco più pericoloso, nonostante la loro quota sia relativamente bassa nel numero totale di minacce.
- Non è ancora stato inventato un mezzo garantito ed efficace per la protezione del perimetro (o un insieme di tali mezzi).
- In genere, gli attacchi mirati si sviluppano in diverse fasi. L'attraversamento del perimetro è solo una delle fasi iniziali, che (potete lanciarmi pietre) non comporta danni significativi per la 'vittima', a meno che non si tratti di attacchi DEoS (Destruction of Service) (ransomware e simili). Il 'dolore' vero e proprio inizia più tardi, quando le risorse catturate cominciano a essere utilizzate per il pivoting e lo sviluppo dell'attacco 'in profondità', e noi non ce ne accorgiamo.
- Poiché iniziamo a subire vere perdite quando i criminali informatici riescono effettivamente a raggiungere gli obiettivi dell'attacco (server di applicazioni, DBMS, archivi di dati, repository, elementi dell'infrastruttura critica), è logico che uno degli obiettivi del servizio di sicurezza informatica sia interrompere gli attacchi prima che si verifichi questo triste evento. Ma per interrompere qualcosa, bisogna prima scoprirlo. E prima lo si fa, meglio è.
- Di conseguenza, per gestire con successo i rischi (cioè, ridurre i danni da attacchi mirati) è cruciale disporre di strumenti che garantiscano un TTD minimo (time to detect – tempo dall'intrusione alla scoperta dell'attacco). A seconda del settore e della regione, questo periodo è di circa 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'essere ideale. Ci sono molte tecniche efficaci per rilevare e superare le sandbox o le soluzioni di whitelisting. I ragazzi del 'lato oscuro' sono qui ancora un passo avanti.
- UEBA (sistemi di profilazione del comportamento e rilevamento delle anomalie) – in teoria potrebbe essere molto efficace. Ma, a mio avviso, è qualcosa che appartiene a un lontano futuro. Nella pratica – è ancora molto costoso, inaffidabile e richiede un'infrastruttura IT e di sicurezza molto matura e stabile, dove sono già presenti tutti gli strumenti necessari per generare dati per l'analisi comportamentale.
- SIEM – è uno strumento valido per le indagini, ma non è in grado di vedere e segnalare per tempo qualcosa di nuovo e originale, perché le regole di correlazione sono le stesse delle firme.
- Di conseguenza, è emersa la necessità di uno strumento che possa:
- funzionare con successo in condizioni di perimetro già compromesso,
- rilevare attacchi riusciti in tempo quasi reale, indipendentemente dagli strumenti e dalle vulnerabilità utilizzate,
- non dipendere da firme/regole/scenari/politiche/profili e altre cose statiche,
- non richiedere grandi quantità di dati e le loro fonti per l'analisi,
- permettere di identificare gli attacchi non come un punteggio di rischio frutto di una "matematica chiusa, brevettata e quindi segreta" che richiede ulteriori indagini, ma praticamente come un evento binario – "Sì, siamo sotto attacco" oppure "No, va tutto bene",
- essere universale, facilmente scalabile e realmente implementabile in qualsiasi ambiente eterogeneo, indipendentemente dalla topologia fisica e logica utilizzata della rete.
Attualmente, si propongono come tale strumento le cosiddette soluzioni di deception. Cioè soluzioni basate sulla vecchia e buona concezione dei honeypot, ma con un livello di attuazione completamente diverso. Questo tema è attualmente sicuramente in crescita.
In base ai risultati Le soluzioni di deception rientrano tra le prime tre strategie e strumenti raccomandati.
Secondo il rapporto La deception è uno dei principali ambiti di sviluppo delle soluzioni IDS (Intrusion Detection Systems).
Una sezione intera dell'ultimo , dedicata a SCADA, è basata sui dati di uno dei leader di questo mercato, TrapX Security (Israele), la cui soluzione è già operativa da un anno nella nostra area di test.
TrapX Deception Grid consente di costruire e gestire in modo centralizzato IDS distribuiti massivi, senza aumentare il carico delle licenze e le esigenze in termini di risorse hardware. In effetti, TrapX è un costruttore che permette di creare da elementi dell'infrastruttura IT esistente un grande meccanismo di rilevamento degli attacchi a livello aziendale, una sorta di 'allerta' di rete distribuita.
Struttura della Soluzione
Nel nostro laboratorio studiamo e testiamo costantemente varie novità nel campo della sicurezza informatica. Attualmente qui sono attivi circa 50 diversi server virtuali, compresi i componenti del TrapX Deception Grid.
Quindi, dall'alto verso il basso:
- TSOC (TrapX Security Operation Console) – il cervello del sistema. Questa è la console centrale di gestione, tramite la quale viene effettuata la configurazione, il dispiegamento della soluzione e tutte le operazioni quotidiane. Essendo un servizio web, può essere dispiegato ovunque: nel perimetro, nel cloud o presso un fornitore MSSP.
- TrapX Appliance (TSA) – un server virtuale al quale colleghiamo tramite una porta trunk le sottoreti che vogliamo monitorare. Qui vivono sostanzialmente tutti i nostri sensori di rete.
Nel nostro laboratorio è stato dispiegato un TSA (mwsapp1), ma in realtà possono essercene molti. Questo può essere necessario in reti ampie, dove non c'è connettività L2 tra i segmenti (un tipico esempio è 'Holding e aziende controllate' o 'Sede centrale della banca e filiali') o se nella rete ci sono segmenti isolati, come i sistemi di automazione industriale. In ciascuna di queste filiali/segmenti possiamo dispiegare il proprio TSA e collegarlo a un'unica TSOC, sulla quale tutte le informazioni verranno elaborate in modo centralizzato. Questa architettura consente di costruire sistemi di monitoraggio distribuiti senza la necessità di una ristrutturazione radicale della rete o di compromettere la segmentazione esistente.
Inoltre, sul TSA possiamo inviare una copia del traffico in uscita tramite TAP/SPAN. In caso di rilevamento di connessioni con botnet conosciute, server di comando, sessioni TOR, otterremo anche i risultati nella console. Questo è gestito dal Network Intelligence Sensor (NIS). Nella nostra situazione, questa funzionalità è implementata nel firewall, quindi qui non l'abbiamo utilizzata.
- Trappole per Applicazioni (Full OS) – tradizionali honeypot basati su server Windows. Non sono necessari molti, poiché l'obiettivo principale di questi server è fornire servizi IT al livello successivo di sensori o rilevare attacchi ai business application che possono essere implementati in un ambiente Windows. Nella nostra laboratorio abbiamo installato uno di questi server (FOS01)
- Trappole emulate – il componente principale della soluzione che consente di creare un campo "minato" molto denso per gli attaccanti grazie a una sola macchina virtuale e saturare la rete dell'azienda, tutti i suoi vlan, con i nostri sensori. L'attaccante percepisce un tale sensore o un host fantasma come un vero PC o server Windows, server Linux o altro dispositivo che decidiamo di mostrargli.
Per scopi pratici e per curiosità, abbiamo distribuito "una coppia per ogni creatura" - PC e server Windows 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 persino una lampadina intelligente. In totale, 13 host. In generale, il fornitore raccomanda di distribuire tali sensori per un minimo del 10% rispetto al numero reale di host. Il limite superiore è lo spazio di indirizzamento disponibile.Un aspetto molto importante è che ogni host di questo tipo non è una macchina virtuale completa, che richiederebbe risorse e licenze. È un "inganno", un'emulazione, un processo su TSA, che ha un insieme di parametri e un indirizzo IP. Pertanto, anche utilizzando un solo TSA, possiamo saturare la rete con centinaia di questi host fantasma che funzioneranno come sensori nel sistema di allerta. È proprio questa tecnologia che consente di scalare in modo economicamente efficiente il concetto di "honeypot" su larga scala in qualsiasi grande azienda distribuita.
Questi host, dal punto di vista dell'attaccante, sono allettanti, poiché contengono 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 l'attacco o eseguire il proprio codice.
- La combinazione di queste due tecnologie (FullOS e trappole emulate) consente di raggiungere un'alta probabilità statistica che un attaccante, prima o poi, si imbatta in qualche elemento della nostra rete di segnalazione. Ma come fare per fare in modo che questa probabilità sia vicina al 100%?
Entrano in gioco i cosiddetti token (Deception tokens). Grazie a essi, possiamo includere nella nostra IDS distribuita tutti i PC e server esistenti dell'azienda. I token sono collocati su PC reali degli utenti. È importante comprendere 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 l'attaccante, che lo conducono in trappola. Ad esempio, dischi di rete connessi, segnalibri a falsi pannelli di amministrazione nel browser e password salvate, sessioni ssh/rdp/winscp salvate, le nostre trappole con note nei file hosts, password memorizzate, credenziali di utenti inesistenti, file di ufficio che, se aperti, attiverebbero il sistema, e molto altro. In questo modo, mettiamo l'attaccante in un ambiente distorto, saturo di vettori di attacco che non rappresentano realmente una minaccia per noi, anzi, viceversa. E non ha la possibilità di determinare dove si trova l'informazione vera e dove quella falsa. Così facendo, non solo garantiamo una rapida identificazione dell'attacco, ma ne rallentiamo considerevolmente il corso.
Esempio di creazione di una trappola di rete e configurazione dei token. Interfaccia amichevole e senza alcuna modifica manuale di configurazioni, script, ecc.
Nel nostro ambiente abbiamo configurato e posizionato una serie di token su FOS01 con Windows Server 2012R2 e su un PC di test con Windows 7. Su queste macchine è attivo RDP e periodicamente "li esponiamo" nella DMZ, dove abbiamo anche diversi nostri sensori (trappole emulate). In questo modo, otteniamo un flusso costante di incidenti, insomma, in modo naturale.
Quindi, una breve statistica annuale:
56.208 – incidenti registrati,
2.912 – host sorgente degli attacchi identificati.
Mappa degli attacchi interattiva e cliccabile
In questo caso, la soluzione non genera un mega-log o un feed di eventi, in cui bisogna districarsi a lungo. Invece, la soluzione classifica autonomamente gli eventi per tipo e consente al team di sicurezza informatica di concentrarsi prima di tutto sui più pericolosi: quando l'attaccante tenta di avviare sessioni di controllo (interaction) o quando compaiono payload binari nel nostro traffico (infection).
Tutte le informazioni sugli eventi sono leggibili e presentate, a mio avviso, in un formato facile da comprendere anche per utenti con conoscenze di base in materia di sicurezza informatica.
La maggior parte degli incidenti registrati riguarda tentativi di scansione dei nostri host o singole connessioni.
Oppure tentativi di brute-forcing delle password per RDP.
Tuttavia, ci sono stati casi più interessanti, specialmente quando gli aggressori sono 'riusciti' a indovinare una password per RDP e ottenere accesso alla rete locale.
L'aggressore 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. Subito dopo la connessione, inserendo un set di comandi preconfigurati, ha cercato di eliminare tutti i file di log e le relative variabili di sistema.
L'attaccante sta tentando di eseguire un'iniezione SQL nella trappola, che simula l'accesso web SWIFT.
Oltre a questi attacchi 'naturali', abbiamo condotto anche una serie di test. Uno dei più indicativi è il test del tempo di rilevamento di un worm di rete nella rete. A questo scopo abbiamo utilizzato uno strumento di GuardiCore chiamato . Si tratta di un worm di rete capace di compromettere Windows e Linux, ma senza un qualche tipo di carico 'utile'.
Abbiamo allestito un centro di comando locale, su una delle macchine abbiamo avviato il primo esemplare del worm e abbiamo ricevuto la prima notifica nella console 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 dalla rapida rilevazione delle minacce alla risposta automatica.
Ad esempio, l'integrazione con i sistemi NAC (Network Access Control) o con CarbonBlack permetterà di disconnettere automaticamente i PC compromessi dalla rete.
L'integrazione con i sandbox consente di inviare automaticamente per analisi i file coinvolti nell'attacco.
Integrazione con McAfee
Anche nella soluzione c'è un sistema di correlazione degli eventi incorporato.
Ma le sue funzionalità non ci hanno soddisfatto, quindi lo abbiamo integrato con HP ArcSight.
Gestire le minacce rilevate "insieme" è facilitato da un sistema di ticketing integrato.
Poiché la soluzione è stata sviluppata "fin dall'inizio" per le esigenze delle autorità pubbliche e del grande segmento aziendale, è ovvio che sia implementato un modello di accesso basato su ruoli, integrazione con AD, un sistema di report avanzato e trigger (notifiche di eventi), orchestrazione per grandi strutture holding o fornitori MSSP.
Invece del riepilogo
Se esiste un sistema di monitoraggio simile, che, per così dire, ci protegge, la compromissione del perimetro è solo l'inizio. La cosa più importante è che c'è una reale possibilità di combattere gli incidenti di sicurezza informatica, piuttosto che occuparsi di eliminare le loro conseguenze.
Fonte: habr.com
