Come preparare / costruire funzionalità per il rilevamento di anomalie (dati di sicurezza della rete)

Il mio obiettivo è analizzare i log di rete (ad es. Apache, syslog, audit di sicurezza di Active Directory e così via) utilizzando il rilevamento di clustering / anomalie ai fini del rilevamento delle intrusioni.

Dai registri ho molti campi di testo come indirizzo IP, nome utente, nome host, porta di destinazione, porta di origine e così via (in totale 15-20 campi). Non so se ci siano alcuni attacchi nei log e voglio evidenziare gli eventi più sospetti (valori anomali).

Di solito, il rilevamento di anomalie contrassegna i punti con bassa probabilità / frequenza come anomalie. Tuttavia, la metà dei record del registro contiene una combinazione univoca di campi. Quindi, metà dei record nel set di dati avrà la frequenza più bassa possibile.

Se utilizzo il rilevamento delle anomalie in base al clustering (ad esempio, trova i cluster e quindi seleziono i punti che sono lontani da tutti i centri del cluster), devo trovare la distanza tra punti diversi. Dato che ho 15-20 campi, sarà uno spazio multidimensionale, in cui le dimensioni sono nome utente, porta, indirizzo IP e così via. Tuttavia, la distanza di Mahalanobis poteva essere applicata solo a funzioni normalmente distribuite. Ciò significa che non c'è modo di trovare la distanza tra i punti dati e costruire cluster ...

Ad esempio, immaginiamo di avere utenti Alice, Bob, Carol, Dave, Eve e Frank nel set di dati di 20 record. Potrebbero avere il seguente numero di occorrenze nel database: 2,5,2,5,1,5. Se associo semplicemente nomi utente a numeri, ad es

Alice --> 1
Bob --> 2
Carol --> 3
Dave --> 4
Eve --> 5
Frank --> 6

Quindi, la mia distribuzione di probabilità per i nomi utente apparirà come segue:

p (1) = 0.1, p (2) = 0.25, p (3) = 0.1, p (4) = 0.25, p (5) = 0.05, p (6) = 0.25

Naturalmente, questa non è una distribuzione normale, e anche questo non ha molto senso, dal momento che potrei mappare i nomi utente in modo diverso ...

Pertanto, la semplice mappatura di campi come nome utente, azione, numero di porta, indirizzo IP e così via ai numeri non porta nulla.

Pertanto, vorrei chiedere, come vengono elaborati i campi di testo / le funzionalità costruite di solito per rendere possibile il rilevamento anomalo / anomalo senza supervisione?

EDIT: struttura dei dati.

Ho circa 100 colonne nella tabella del database, contenente informazioni dagli eventi di Active Directory. Da queste 100 colonne seleziono il più importante (dal mio punto di vista): SubjectUser, TargetUser, SourceIPaddress, SourceHostName, SourcePort, Computer, DestinationIPaddress, DestinationHostName, DestinationPort, Action, Status, FilePath, EventID, WeekDay, DayTime.

Gli eventi sono eventi di Active Directory, in cui EventID definisce ciò che è stato registrato (ad esempio, creazione del ticket Kerberos, accesso utente, disconnessione utente, ecc.).

L'esempio di dati è simile al seguente:

+ ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- - +
| ID | SubjectUser | TargetUser | SourceIPaddress | SourceHostName | SourcePort | Computer | DestinationIPaddress | DestinationHostName | DestinationPort | Azione | Stato | FilePath | EventID | WeekDay | DayTime |
+ ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- - +
| 171390673 |? |? |? |? |? | domaincontroller1.domain.com | 1.1.1.1 | domaincontroller1.domain.com |? | / Autenticazione / Verifica | / Successo |? | 4624 | 1 | 61293 |
+ ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- - +
| 173348232 |? |? |? |? |? | domaincontroller2.domain.com | 2.2.2.2 | domaincontroller2.domain.com |? | / Autenticazione / Verifica | / Successo |? | 4624 | 1 | 61293 |
+ ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- - +
| 180176916 |? |? |? |? |? | domaincontroller2.domain.com | 2.2.2.2 | domaincontroller2.domain.com |? | / Autenticazione / Verifica | / Successo |? | 4624 | 1 | 61293 |
+ ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- - +
| 144144725 |? | John.Doe | 3.3.3.3 | domaincontroller3.domain.com | 2407 | domaincontroller3.domain.com | 3.3.3.4 | domaincontroller3.domain.com |? | / Autenticazione / Verifica | / Successo |? | 4624 | 3 | 12345 |
+ ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- - +

Tutti insieme, ho circa 150 milioni di eventi. Eventi diversi hanno campi diversi compilati e non tutti gli eventi sono correlati all'accesso / disconnessione dell'utente.

Non sono assolutamente un esperto nel rilevamento di anomalie . Tuttavia, è un'area interessante ed ecco i miei due centesimi. Innanzitutto, considerando la nota che "la distanza di Mahalanobis poteva essere applicata solo a funzioni normalmente distribuite". Mi sono imbattuto in alcune ricerche che sostengono che è ancora possibile utilizzare quella metrica in caso di dati non normali . Dai un'occhiata a questo documento e a questo rapporto tecnico .

Spero anche che troverai utili le seguenti risorse sul rilevamento di anomalie senza supervisione (AD) nel contesto di sicurezza della rete IT , usando vari approcci e metodi: questo documento , che presenta una struttura geometrica per la pubblicità senza supervisione; questo documento , che utilizza un approccio di clustering basato sulla densità e sulla griglia ; diapositive di questa presentazione , che menzionano l'uso di mappe auto-organizzate per l'AD.

Infine, ti suggerisco di dare un'occhiata alle mie seguenti risposte, che ritengo siano rilevanti per l'argomento e, quindi, potrebbero essere utili: risposta su approcci di clustering , risposta su clustering non basato sulla distanza e risposta su opzioni software per dC .

Prima di tutto, penso che ci siano alcune cose a cui potresti doverti rassegnare.

Un forte vincolo che vedo su questo problema è che probabilmente dovresti essere preparato ad avere un tasso di falsi positivi abbastanza alto. Per quanto ne so, la frequenza di base dei record che fanno parte di un'anomalia della rete è piuttosto bassa (citazione necessaria). Chiamiamolo quota 1000: 1, per ragioni di discussione. Quindi, anche se osservi un modello 100 volte più probabile che si verifichi se il record è un'intrusione, allora se è legittimo, la regola di Bayes dice che le probabilità posteriori sono 10: 1 che il traffico è ancora legittimo.

L'altro problema è che alcune intrusioni sono difficili da rilevare anche in linea di principio . Ad esempio, se qualcuno mi ha socialmente ingegnerizzato nel dare loro il mio computer, e quindi hanno effettuato l'accesso a questo servizio e scaricato un file top-secret su cui stavo lavorando, sarebbe piuttosto difficile da trovare. Fondamentalmente, un attaccante sufficientemente determinato può rendere il suo comportamento invadente quasi arbitrariamente vicino al normale comportamento del sistema.

Inoltre, i tuoi avversari sono processi intelligenti, non statistici, quindi se inizi a rilevare un modello e a chiuderlo, potrebbero semplicemente rispondere non seguendo più quel modello. Ecco perché, ad esempio, vedrai molti messaggi di spam con spazi tra tutte le lettere (che ti offrono " V I A G R A" o qualsiasi altra cosa). I filtri antispam hanno scoperto che la stringa "viagra" era spam, quindi gli aggressori hanno appena iniziato a fare qualcos'altro.

Per questo motivo, penso che valga la pena di riflettere su quali tipi di intrusioni pensi che valga la pena di essere in grado di rilevare. Qui ci sono sicuramente frutti a bassa pendenza, quindi non lasciare che il perfetto sia nemico del bene e cerca di trovare un algoritmo in grado di rilevare tutte le intrusioni.

A parte questo, parliamo del frutto basso. Qui, penso che potrebbe essere produttivo per te spostare la tua unità di analisi da singoli record a un gruppo di record.

Ad esempio, hai detto che la metà di tutti i record ha combinazioni uniche di campi. Ma presumibilmente, per esempio, la maggior parte degli IP di origine appare in più di un record: sono gli altri campi della richiesta che stanno cambiando e rendendo unica la combinazione. Se si raggruppano le richieste per IP, è possibile quindi porre domande come:

• Alcuni IP sembrano autenticarsi come insolitamente molti utenti (o insolitamente pochi)?
• Alcuni IP hanno un numero insolitamente elevato di errori di autenticazione?
• Alcuni IP hanno un modello insolito di tempistiche di accesso (ad esempio, molte attività intorno alle 3 del mattino nel loro fuso orario o richieste ogni 1 secondo durante il giorno)?

Puoi fare cose simili per altri raggruppamenti, come nome utente:

• Questo utente esegue l'autenticazione da un computer diverso quando in precedenza ha utilizzato lo stesso computer per tutte le richieste?
• Questo utente sta improvvisamente toccando una parte del filesystem che non ha mai toccato prima?

Non conosco classificatori standardizzati che sembrano particolarmente adatti a questo, perché il potenziale comportamento dei tuoi utenti è così vario e probabilmente sei principalmente interessato a cambiamenti nel comportamento nel tempo. Ciò significa che probabilmente vorrai costruire un qualche tipo di modello di ciò che ogni utente / IP / qualunque cosa possa fare in futuro e contrassegnare eventuali deviazioni da questo modello. Ma è un processo piuttosto intenso se i tuoi utenti hanno modelli di comportamento diversi!

A causa di questa difficoltà, penso che per ora potrebbe essere più produttivo eseguire il tipo di analisi in modalità esplorativa che ho descritto sopra. È probabile che ti informi su quali tipi di pattern sono i più interessanti e quindi puoi iniziare a utilizzare algoritmi statistici fantasiosi per rilevare tali pattern.

Penso che in primo luogo sia necessario disporre di un set di dati che registri i dati per un periodo di nessun attacco. Questo set di dati dovrebbe acquisire le variazioni inerenti a un sistema che si comporta normalmente. Vorrei sottolineare il fatto che non si tratta di avere un set di dati annotato.

Quindi, proverei a combinare tutte (o sottoinsiemi) di metriche in una. Questa nuova metrica dovrebbe riflettere la quantità di "sorpresa". Ad esempio, un valore basso indica che il sistema funziona normalmente, un picco / plateau di valore elevato significa che c'è un rapido cambiamento. Qui sto pensando a CUSUM o ai grafici in stile grafico di Shewhart.

Potete fornire alcuni esempi dei dati disponibili? Sono principalmente stringhe, numeri, indicatori 1/0?

Una possibilità è quella di apprendere una rete bayesiana tra le funzionalità dati alcuni dati di background senza attacchi. L'apprendimento di una rete bayesiana è utile perché evidenzia l'indipendenza condizionale tra le funzionalità. Quindi, non hai a che fare con tutte le possibili combinazioni di funzionalità. Ad esempio, se la funzione A influenza B e C e le funzioni B e C insieme influenzano D, allora impari solo un modello su come A influenza B, come influenza C e come B e C influenzano congiuntamente D. Questo modello richiederà molto meno parametri rispetto all'intera distribuzione di probabilità ed è il motivo principale per cui vengono utilizzate le reti bayesiane invece di memorizzare l'intera distribuzione di probabilità congiunta. Per verificare l'anomalia data una rete bayesiana, calcolare la probabilità del punto di accesso dati utilizzando il modello di rete bayesiana appreso. Se la probabilità è molto bassa,

Ho pensato che la risposta di Ben Kuhn fosse pragmatica e perspicace.

Ora il mio background personale include classificazione del testo, sistemi esperti, clustering e sicurezza. Dato questo contesto, vorrei piace pensare che io possa avere qualcosa da aggiungere alla conversazione. Ma le precedenti dichiarazioni di Ben Kuhn sottolineano che approcci semplici potrebbero produrre molti falsi positivi. Il personale IT, di fronte a molti falsi positivi, in genere "si sintonizza" perché semplicemente non ha il tempo di inseguire falsi positivi in ​​ogni momento.

Quindi che si fa?

Certamente i log con gli attacchi potrebbero essere utili, ma poi abbiamo un catch-22 a meno che le aziende non condividano in qualche modo i dati di attacco. Mentre alcune start-up della Silicon Valley potrebbero perseguire tale condivisione delle minacce, cos'altro potremmo fare?

Un possibile approccio è quello di creare una simulazione della rete e quindi trovare un modo per generare attacchi contro la simulazione. Cioè, supponiamo di creare una simulazione in cui i cappelli neri (anche simulati) non sono noti in anticipo ai cappelli bianchi. Dati questi attacchi, possiamo quindi tentare di creare algoritmi che dovrebbero scoprire questi attacchi. Se i cappelli neri operano indipendentemente dai cappelli bianchi, allora avremo una vera battaglia che si svolgerà. Se gli attaccanti irrompono nel sistema o non vengono rilevati, i cappelli bianchi hanno, in una certa misura, fallito.

Si potrebbe persino avere una struttura di incentivazione quando gli analisti della sicurezza della squadra del cappello nero vengono premiati per i loro successi (calzoni o attacchi da scoprire). Allo stesso modo, il gruppo che comprende i cappelli bianchi viene premiato per aver fermato i calzoni e / o per aver rilevato attacchi.

Non c'è niente di perfetto in questo accordo. Ovviamente i veri cappelli neri potrebbero superare i talenti della squadra "amichevole" di cappello nero. Tuttavia, come persona che ha una buona quantità di analisi dei dati, mi sembra che sia molto difficile quantificare il successo dei cappelli bianchi senza una migliore comprensione dei cappelli neri. La linea di fondo è questa. Se non riusciamo a sapere cosa stanno facendo i veri cappelli neri, la prossima cosa migliore sono i cappelli neri amichevoli.

Ho anche un'idea piuttosto insolita. Supponiamo che, oltre ai simpatici cappelli neri e bianchi, ci sia una squadra di cappelli grigi. Cosa significa essere un cappello grigio? L'idea è semplice Ai cappelli grigi è permesso vedere cosa fanno i cappelli neri amichevoli e i cappelli bianchi. Ma perché?

Supponiamo che i cappelli neri amici lancino attacchi usando gli approcci A, B e C e che i cappelli bianchi non scoprano mai nessuno di questi tre approcci. Bene, i cappelli grigi hanno il potere di vedere cosa fanno sia i cappelli neri amichevoli che i cappelli bianchi, e provano a considerare quali principi potrebbero essere usati per scoprire questi attacchi inosservati. Se il cappello grigio trova tali principi, la squadra del cappello grigio può quindi condividere questi principi con la squadra del cappello bianco senza descrivere dettagliatamente gli attacchi esatti.

La speranza è che questi "suggerimenti" forniti dalla squadra di cappelli grigi diano alla squadra di cappelli bianchi una spinta nella giusta direzione senza rivelare troppo.

In retrospettiva, mi scuso se la mia risposta non riguarda davvero tecniche specifiche. Ovviamente la mia risposta non lo è riguarda tecniche specifiche. Ma nella mia esperienza, molti problemi nell'apprendimento automatico - compresi quelli relativi alla sicurezza - spesso falliscono perché i dati sono inadeguati. Questo approccio, che utilizza cappelli bianchi, cappelli grigi e cappelli neri, potrebbe aiutare a produrre i dati che consentirebbero a una società di sicurezza (o al personale IT) di non solo quantificare l'efficacia delle loro difese, ma fornire una struttura organizzativa che spinge il team dei cappelli bianchi migliorare progressivamente le proprie difese e il loro monitoraggio.

Non ho davvero idea se l'approccio che sto suggerendo sia originale. Non ho mai sentito parlare di cappelli grigi, ma in realtà penso che il ruolo dei cappelli grigi potrebbe essere fondamentale per spingere la squadra bianca in avanti, senza rivelare troppo.

Nota: il mio uso del termine "cappello grigio" qui non è standard. Vedi http://www.howtogeek.com/157460/hacker-hat-colors-explained-black-hats-white-hats-and-gray-hats/ . Quindi dovrebbe essere usato un altro termine, forse "cappello a strisce".

Ma l'idea rimane la stessa: un cappello a strisce può aiutare a mediare tra il lavoro di amichevoli cappelli neri e difensori (cappelli bianchi), in modo che alcune idee e suggerimenti possano essere condivise giudiziosamente con i cappelli bianchi.

Da quando ho pubblicato la domanda originale, ho svolto molte ricerche su questo argomento e ora posso fornire i miei risultati come risposta.

Innanzitutto, nel nostro laboratorio, sviluppiamo un sistema SIEM che utilizza algoritmi di rilevamento delle anomalie. La descrizione del sistema e degli algoritmi è disponibile nel mio documento Verso un sistema per l'analisi complessa di eventi di sicurezza in reti su larga scala

Oltre a ciò, ho scritto un breve riassunto su come gestire tali dati nella mia risposta a una domanda simile su Cross Validated