Comparação entre análise temporal e populacional no Elastic Machine Learning

By
Rich Collier

O Elastic Machine Learning permite que os usuários tomem conhecimento dos dois principais tipos de anomalias, os de natureza temporal (com relação ao tempo) e os baseados na população (com relação a outras pessoas). Mas quais são as diferenças entre esses dois tipos e quando usar um tipo em vez do outro? Este blog discute os detalhes das análises, seus méritos e as práticas recomendadas baseadas em regras básicas comuns.

Primeiramente, vamos definir o que queremos dizer com anomalias temporais e populacionais. Para isso, vamos abordar alguns fatos:

Detecção de anomalia temporal

– O comportamento padrão do Elastic Machine Learning, a menos que você defina especificamente que a análise será populacional –É uma comparação do comportamento de uma entidade em relação a si mesma ao longo do tempo – Pode aproveitar uma “divisão” (por meio de by_field_name ou partition_field_name) para criar linhas de base individuais para cada instância de algo (por exemplo, uma linha de base exclusiva por host ou usuário) – Não é exatamente adequada para elementos de dados com alta cardinalidade ou muito dispersos (por exemplo, endereços IP externos de visitantes de um site podem ser dispersos e ter alta cardinalidade – na casa de centenas de milhares ou mais). Isso causará problemas de performance se os limites de memória da tarefa não forem aumentados em relação ao valor limite padrão. No entanto, mesmo se fizermos isso, será provável que a análise populacional ainda seja a abordagem mais adequada.

Detecção de anomalia populacional

– Só é invocada quando over_field_name é usado (ou o assistente de Tarefa de população do Kibana for usado). O campo declarado como over_field_name é o que define a população. – É uma análise de pares de membros em uma população ou, mais precisamente, uma comparação de uma entidade individual com um modelo coletivo de todos os pares conforme percebido ao longo do tempo. – Também pode aproveitar uma “divisão” (por meio de over_field_name ou partition_field_name) para criar subpopulações – Geralmente muito adequado para elementos de dados com alta cardinalidade ou dispersos, pois membros individuais contribuem com um modelo coletivo de comportamento.

Exemplo de caso de uso

Agora que explicamos o básico, vamos discutir um caso de uso hipotético que pode nos ajudar a escolher a abordagem correta.

Vamos supor que queremos rastrear o número de documentos baixados de um servidor de documentos interno e que o servidor contém documentos amplamente aplicáveis a todos na empesa (uma empresa de grande porte, com mais de 50.000 funcionários). Além disso, qualquer pessoa pode acessar esse servidor de documentos a qualquer momento. Por fim, vamos supor também que o log de acesso do servidor de documentos rastreia todos os acessos a um documento e o usuário que faz o download.

Exemplo de anomalia temporal

Suponhamos que eu escolha a detecção de anomalia temporal e estruture uma análise semelhante a:

    "detectors": [
      {
        "function": "count",
        "partition_field_name": "user"
      }
    ]

Nesse caso, espero rastrear o volume de downloads, para cada usuário, por nome, individualmente ao longo do tempo. Portanto, se user=”Wilma” normalmente baixa cerca de 50 documentos por dia (ela é da engenharia e é usuária pesada dos documentos do servidor), só haveria uma anomalia se Wilma mudasse drasticamente seu comportamento e baixasse muito menos ou muito mais do que normalmente faz (por exemplo, 5.000 documentos por dia).

Considerando o que mencionei antes, eu também precisaria saber quantos usuários diferentes espero que o ML monitore. Com 50.000 usuários exclusivos, isso pode ser administrável se aumentarmos o limite de memória na tarefa de ML. No entanto, outra coisa para lembrar é que um usuário pode não baixar documentos todos os dias de forma consistente, portanto, sua atividade pode ser um tanto dispersa, podendo baixar alguns hoje e passar até meses sem baixar mais nada. Poderá ser difícil estabelecer uma linha de base precisa por usuário se não houver uma observação consistente disponível por usuário.

Mas, mais importante: e se uma nova pessoa (user=”Fred”) aparecer e baixar 5.000 documentos em um dia e nunca mais fizer isso novamente? Isso foi incomum? Fred é uma ameaça interna ou algum tipo de malware de extração de dados usou as credenciais de Fred para roubar documentos para tentar transmiti-los para fora da organização? Quando a análise é feita com a detecção de anomalia temporal, a resposta é indeterminada. Na verdade, não sabemos se isso é incomum para “Fred”, pois não temos seu histórico como base de comparação (só vimos uma amostra).

Exemplo de anomalia populacional

Como alternativa, se analisarmos o problema utilizando a detecção de anomalia populacional, como:

    "detectors": [
      {
        "function": "count",
        "over_field_name": "user"
      }
    ]

Poderemos chegar aos seguintes resultados:

– Podemos usar quaisquer usuários que estiverem presentes em cada bucket_span (nesse caso, um dia) para criar um modelo coletivo do que é um total de downloads típico para os usuários, coletivamente – Comparar cada usuário visto em cada dia com o modelo coletivo

Agora, se Wilma e a maioria dos seus colegas baixar de 10 a 75 documentos por dia, o modelo “coletivo” geral de uso típico estará nesse intervalo. Se Fred aparecer um dia e baixar 5.000 documentos, o volume será anômalo, pois Fred está sendo comparado com Wilma e seus colegas. Fred será apontado como um valor discrepante.

No entanto, há um ponto fundamental. Se Wilma também baixar 5.000 documentos, em vez de Fred, ela será apontada como valor discrepante anômalo, não especificamente porque baixou mais do que normalmente faz, mas porque baixou mais do que o modelo “típico” de uso que ela mesmo ajudou a estabelecer ao longo do tempo, juntamente com seus colegas.

O fato é que Wilma é apontada como valor discrepante nessa situação, não importa se a escolha da detecção é temporal ou populacional, mas a abordagem populacional é mais flexível nesse caso porque:

  1. Não é afetado por dados dispersos
  2. É mais eficiente no que diz respeito à memória quando o número de usuários distintos aumenta (pois não são necessários modelos individuais por usuário)
  3. Encontra valores discrepantes como Fred, que têm pouco ou nenhum histórico
  4. Ainda considera Wilma um valor discrepante caso seu comportamento mude drasticamente a ponto de ficar fora do comportamento coletivo

Uma dica adicional: se você estiver fazendo análise populacional, fará mais sentido construir suas populações para que sejam o mais homogêneas possível. Em outras palavras, se você tiver grandes conjuntos de tipos de usuários (por exemplo, engenheiros e pessoal de RH), poderá ser mais eficiente dividir esses usuários em grupos separados e fazer duas análises individuais do que esperar que todos sejam agrupados.

E uma observação final: se você tiver membros de uma população que já sabe que gostaria de excluir, considere eliminá-los usando filtros nos dados da entrada ou regras para filtrar resultados.

Espero que essa explicação seja útil para comparar as duas abordagens. Se você quiser experimentar o Machine Learning nos seus dados, baixe o Elastic Stack e habilite a licença de teste de 30 dias ou inicie um teste gratuito na Elastic Cloud.