Como preparar / construir recursos para detecção de anomalias (dados de segurança da rede)

Meu objetivo é analisar os logs de rede (por exemplo, Apache, syslog, auditoria de segurança do Active Directory e assim por diante) usando a detecção de cluster / anomalia para fins de detecção de intrusão.

Nos logs, tenho muitos campos de texto como endereço IP, nome de usuário, nome do host, porta de destino, porta de origem etc. (no total de 15 a 20 campos). Não sei se existem alguns ataques nos logs e quero destacar os eventos mais suspeitos (outliers).

Normalmente, a detecção de anomalias marca os pontos com baixa probabilidade / frequência como anomalias. No entanto, metade dos registros de log contém uma combinação exclusiva de campos. Portanto, metade dos registros no conjunto de dados terá a menor frequência possível.

Se eu usar a detecção de anomalias com base em cluster (por exemplo, encontrar clusters e depois selecionar pontos que estão longe de todos os centros de cluster), preciso encontrar a distância entre pontos diferentes. Como eu tenho de 15 a 20 campos, será um espaço multidimensional, onde as dimensões são nome de usuário, porta, endereço IP e assim por diante. No entanto, a distância de Mahalanobis só poderia ser aplicada a recursos distribuídos normalmente. Isso significa que não há como encontrar distância entre pontos de dados e construir clusters ...

Por exemplo, vamos imaginar que eu tenho usuários Alice, Bob, Carol, Dave, Eve e Frank no conjunto de dados de 20 registros. Eles poderiam ter o seguinte número de ocorrências no banco de dados: 2,5,2,5,1,5. Se eu simplesmente mapear nomes de usuários para números, por exemplo,

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

Então, minha distribuição de probabilidade para nomes de usuário terá a seguinte aparência:

p (1) = 0,1, p (2) = 0,25, p (3) = 0,1, p (4) = 0,25, p (5) = 0,05, p (6) = 0,25

Obviamente, essa não é uma distribuição normal, e isso também não faz muito sentido, pois eu poderia mapear nomes de usuários de qualquer maneira diferente ...

Assim, o mapeamento simples de campos como nome de usuário, ação, número da porta, endereço IP e assim por diante para números não traz nada.

Portanto, eu gostaria de perguntar como os campos de texto são processados ​​/ os recursos são construídos geralmente para possibilitar a detecção de anomalias / outlier não supervisionadas?

EDIT: estrutura de dados.

Eu tenho cerca de 100 colunas na tabela do banco de dados, contendo informações dos Eventos do Active Directory. Dessas 100 colunas, seleciono as mais importantes (do meu ponto de vista): SubjectUser, TargetUser, SourceIPaddress, SourceHostName, SourcePort, Computador, DestinationIPaddress, DestinationHostName, DestinationPort, DestinationPort, Ação, Status, FilePath, EventID, EventDay, WeekDay, DayTime.

Eventos são eventos do Active Directory, onde EventID define o que foi registrado (por exemplo, criação de tíquete Kerberos, logon do usuário, logoff do usuário, etc.).

A amostra de dados tem a seguinte aparência:

+ ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- - +
| ID | SubjectUser | TargetUser | SourceIPaddress | SourceHostName | SourcePort | Computador | DestinationIPaddress | DestinationHostName | DestinationPort | Ação | Status | FilePath | EventID | WeekDay | DayTime |
+ ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- - +
| 171390673 |? |? |? |? |? | domaincontroller1.domínio.com | 1.1.1.1 | domaincontroller1.domínio.com |? | / Autenticação / Verificar | / Sucesso |? 4624 | 1 | 61293 |
+ ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- - +
| 173348232 |? |? |? |? |? | domaincontroller2.domínio.com | 2.2.2.2 | domaincontroller2.domínio.com |? | / Autenticação / Verificar | / Sucesso |? 4624 | 1 | 61293 |
+ ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- - +
| 180176916 |? |? |? |? |? | domaincontroller2.domínio.com | 2.2.2.2 | domaincontroller2.domínio.com |? | / Autenticação / Verificar | / Sucesso |? 4624 | 1 | 61293 |
+ ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- - +
| 144144725 |? | John.Doe | 3.3.3.3 | domaincontroller3.domínio.com | 2407 | domaincontroller3.domínio.com | 3.3.3.4 | domaincontroller3.domínio.com |? | / Autenticação / Verificar | / Sucesso |? 4624 3 3 12345
+ ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- - +

No total, tenho cerca de 150 milhões de eventos. Eventos diferentes têm campos diferentes preenchidos e nem todos os eventos estão relacionados ao logon / logoff do usuário.

Definitivamente, não sou especialista em detecção de anomalias . No entanto, é uma área interessante e aqui estão meus dois centavos. Primeiro, considerando sua nota de que "a distância Mahalanobis só poderia ser aplicada a recursos distribuídos normalmente". Encontrei algumas pesquisas que argumentam que ainda é possível usar essa métrica em casos de dados não normais . Dê uma olhada neste documento e neste relatório técnico .

Espero também que você ache úteis os seguintes recursos na detecção de anomalia não supervisionada (AD) no contexto de segurança de rede de TI , usando várias abordagens e métodos: este artigo , apresentando uma estrutura geométrica para AD não supervisionado; este documento , que utiliza a abordagem de cluster baseado em densidade e em grade ; os slides desta apresentação , que mencionam o uso de mapas auto-organizados para o AD.

Por fim, sugiro que você dê uma olhada nas seguintes respostas, que acredito serem relevantes para o tópico e, portanto, podem ser úteis: responder sobre abordagens de clustering , responder sobre clustering não baseado em distância e responder sobre opções de software para AD .

Primeiro de tudo, acho que há algumas coisas às quais você pode se resignar.

Uma restrição difícil que vejo sobre esse problema é que você provavelmente deve estar preparado para ter uma taxa de falsos positivos bastante alta. Até onde eu sei, a taxa básica de registros que faz parte de uma anomalia de rede é bastante baixa (citação necessária). Vamos chamá-lo de probabilidades de 1000: 1, por uma questão de argumento. Então, mesmo se você observar um padrão 100 vezes mais provável de ocorrer se o registro for uma intrusão e se for legítimo, a Regra de Bayes diz que as chances posteriores são 10: 1 de que o tráfego ainda é legítimo.

O outro problema é que algumas intrusões são difíceis de detectar, mesmo em princípio . Por exemplo, se alguém me ajudou socialmente a fornecer o meu computador e, em seguida, fez login neste serviço e baixou um arquivo ultrassecreto no qual eu estava trabalhando, seria muito difícil de encontrar. Basicamente, um invasor suficientemente determinado pode tornar seu comportamento intrusivo quase arbitrariamente próximo ao comportamento normal do sistema.

Além disso, seus adversários são inteligentes, não processos estatísticos; portanto, se você começar a detectar algum padrão e excluí-lo, eles podem simplesmente responder, não seguindo mais esse padrão. É por isso que, por exemplo, você verá muitas mensagens de spam com espaços entre todas as letras (oferecendo " V I A G R A" ou qualquer outra coisa). Os filtros de spam descobriram que a string "viagra" era spam, então os atacantes começaram a fazer outra coisa.

Por causa disso, acho que vale a pena pensar bastante sobre que tipos de intrusões você acha que vale a pena o esforço para poder detectar. Certamente, existem poucas frutas aqui, então não deixe o perfeito ser o inimigo do bem e tente criar um algoritmo que possa detectar todas as intrusões.

Além disso, vamos falar sobre as frutas mais baixas. Aqui, acho que pode ser produtivo mudar sua unidade de análise de registros individuais para um grupo de registros.

Por exemplo, você disse que metade de todos os registros possui combinações únicas de campos. Mas, presumivelmente, por exemplo, a maioria dos IPs de origem aparece em mais de um registro - são os outros campos da solicitação que estão mudando e tornando a combinação única. Se você agrupar as solicitações por IP, poderá fazer perguntas como:

• Alguns IPs parecem se autenticar como muitos usuários (ou poucos)?
• Alguns IPs têm um número incomumente grande de falhas de autenticação?
• Alguns IPs têm um padrão incomum de tempos de acesso (por exemplo, muita atividade por volta das 3h no fuso horário ou solicitações a cada 1 segundo ao longo do dia)?

Você pode fazer coisas semelhantes para outros agrupamentos, como nome de usuário:

• Esse usuário está se autenticando em um computador diferente quando usou o mesmo computador anteriormente para todas as solicitações?
• Esse usuário está tocando de repente em uma parte do sistema de arquivos em que nunca tocou antes?

Não conheço nenhum classificador de prateleira que pareça particularmente adequado para isso, porque o comportamento potencial de seus usuários é muito variado e você provavelmente está mais interessado em mudanças de comportamento ao longo do tempo. Isso significa que você provavelmente deseja criar algum tipo de modelo do que cada usuário / IP / o que provavelmente fará no futuro e sinalizar quaisquer desvios desse modelo. Mas esse é um processo bastante intenso se seus usuários tiverem padrões de comportamento diferentes!

Por causa dessa dificuldade, acho que, por enquanto, pode ser mais produtivo fazer o tipo de análise de modo exploratório que descrevi acima. É provável que o informe sobre quais tipos de padrões são os mais interessantes e, em seguida, você pode começar a usar algoritmos estatísticos sofisticados para detectar esses padrões.

Eu acho que, em primeiro lugar, você precisa ter um conjunto de dados que registre dados por um período sem ataques. Esse conjunto de dados deve capturar as variações inerentes a um sistema que se comporta normalmente. Gostaria de enfatizar que não se trata de ter um conjunto de dados anotado.

Em seguida, tentaria combinar todas (ou subconjunto) de métricas em uma. Essa nova métrica deve refletir a quantidade de "surpresa". Por exemplo, baixo valor significa que o sistema funciona normalmente, alto valor de pico / platô significa que há algumas mudanças rápidas. Aqui, estou pensando nos gráficos de estilo CUSUM ou Shewhart.

Você pode fornecer alguns exemplos dos dados disponíveis? São principalmente strings, números, indicadores 1/0?

Uma possibilidade é aprender uma rede bayesiana entre os recursos, dados alguns dados de segundo plano sem ataques. Aprender uma rede bayesiana é útil porque gera independência condicional entre os recursos. Portanto, você não está lidando com todas as combinações possíveis de recursos. Por exemplo, se o recurso A afeta B e C e os recursos B e C juntos afetam D, você apenas aprende um modelo de como A afeta B, como afeta C e como B e C afetam conjuntamente D. Esse modelo exigirá muito menos parâmetros do que toda a distribuição de probabilidade e é a principal razão pela qual redes bayesianas são usadas em vez de apenas armazenar toda a distribuição de probabilidade conjunta. Para testar uma anomalia em uma rede bayesiana, calcule a probabilidade de ponto de dados de entrada usando o modelo de rede bayesiano aprendido. Se a probabilidade for muito baixa,

Eu pensei que a resposta de Ben Kuhn foi pragmática e perspicaz.

Agora, meu próprio histórico inclui classificação de texto, sistemas especializados, clustering e segurança. Dado esse cenário, gostaria de pensar que talvez eu tenha algo a acrescentar à conversa. Mas as declarações anteriores de Ben Kuhn destacam que abordagens diretas podem produzir muitos falsos positivos. A equipe de TI, quando confrontada com muitos falsos positivos, geralmente "desativa" porque simplesmente não tem tempo para perseguir falsos positivos o tempo todo.

Então o que fazer?

Certamente registros com ataques podem ser úteis, mas temos um problema 22, a menos que as empresas compartilhem dados de ataques. Embora algumas startups do Vale do Silício possam estar buscando esse compartilhamento de ameaças, o que mais podemos fazer?

Uma abordagem possível é criar uma simulação da rede e, em seguida, encontrar uma maneira de gerar ataques contra a simulação. Ou seja, suponha que criamos uma simulação em que os chapéus pretos (também simulados) não sejam conhecidos antecipadamente pelos chapéus brancos. Diante desses ataques, podemos tentar criar algoritmos que devem descobrir esses ataques. Se os chapéus pretos operam independentemente dos chapéus brancos, então temos uma verdadeira batalha que se desenrolará. Se os atacantes invadem o sistema ou não são detectados, os chapéus brancos falham, até certo ponto.

Pode-se até ter uma estrutura de incentivos quando os analistas de segurança da equipe do black hat são recompensados ​​por seus sucessos (culotes ou ataques não descobertos). Da mesma forma, o grupo que compreende os chapéus brancos é recompensado por interromper as calças e / ou detectar ataques.

Não há nada perfeito nesse arranjo. Obviamente, os chapéus pretos verdadeiros podem exceder os talentos da equipe "amigável" de chapéus pretos. No entanto, como pessoa que tem uma quantidade razoável de análise de dados, parece-me que é muito difícil quantificar o sucesso dos chapéus brancos sem uma melhor compreensão dos chapéus pretos. Bottom line é isso. Se não podemos saber o que os verdadeiros chapéus pretos estão fazendo, a próxima melhor coisa são os chapéus pretos amigáveis.

Eu também tenho uma idéia bastante incomum. Suponha que, além dos simpáticos chapéus pretos e brancos, haja uma equipe de chapéus cinza. O que significa ser um chapéu cinza? A ideia é simples. Os chapéus cinzentos podem ver o que os simpáticos chapéus pretos estão fazendo e os chapéus brancos. Mas por que?

Suponha que os chapéus pretos amigáveis ​​lançem ataques usando as abordagens A, B e C, e os chapéus brancos nunca descobrem nenhuma dessas três abordagens. Bem, os chapéus cinzentos têm o poder de observar o que os bonés pretos amigáveis ​​estão fazendo e os brancos, e tentam considerar quais princípios podem ser usados ​​para descobrir esses ataques não detectados. Se o chapéu cinza encontrar tais princípios, a equipe do chapéu cinza poderá compartilhar esses princípios com a equipe do chapéu branco sem descrever detalhadamente os ataques exatos.

A esperança é que essas "dicas" fornecidas pela equipe de chapéu cinza dêem à equipe de chapéu branco um empurrão na direção certa, sem revelar muito.

Em retrospecto, peço desculpas se minha resposta realmente não é sobre técnicas específicas. Obviamente, minha resposta não é sobre técnicas específicas. Mas, na minha experiência, muitos problemas no aprendizado de máquina - incluindo aqueles em segurança - geralmente falham porque os dados são inadequados. Essa abordagem, usando chapéus brancos, cinzas e pretos, pode ajudar a produzir os dados que permitiriam a uma empresa de segurança (ou equipe de TI) não apenas quantificar a eficácia de suas defesas, mas fornecer uma estrutura organizacional que empurra a equipe de chapéus brancos melhorar progressivamente suas defesas e seu monitoramento.

Realmente não tenho ideia se a abordagem que estou sugerindo é original. Nunca ouvi falar de chapéus cinzas, mas acho que o papel dos chapéus cinzentos pode ser fundamental para levar a equipe branca adiante, sem revelar muito.

Nota: meu uso do termo "chapéu cinza" aqui não é padrão. Consulte http://www.howtogeek.com/157460/hacker-hat-colors-explained-black-hats-white-hats-and-gray-hats/ . Portanto, algum outro termo, talvez "chapéu listrado", deveria ser usado.

Mas ainda assim a idéia permanece a mesma: um chapéu listrado pode ajudar a mediar o trabalho de amigáveis ​​chapéus pretos e defensores (chapéus brancos), para que certas idéias e dicas possam ser criteriosamente compartilhadas com os chapéus brancos.

Desde que publiquei a pergunta original, realizei muitas pesquisas sobre esse tópico e agora posso fornecer meus resultados como resposta.

Primeiro de tudo, em nosso laboratório, desenvolvemos um sistema SIEM que utiliza algoritmos de detecção de anomalias. A descrição do sistema e algoritmos está disponível em meu artigo. Para um sistema para análise complexa de eventos de segurança em redes de grande escala

Além disso, escrevi um breve resumo sobre como lidar com esses dados na minha resposta a uma pergunta semelhante sobre Cross Validated