O recurso de detecção de anomalias de uma solução SIEM, UEBA, é alimentado por algoritmos de aprendizado de máquina para identificar desvios do comportamento esperado de usuários e entidades. Esses usuários e entidades podem receber uma pontuação de risco dinâmica (por exemplo, entre 0 a 100) com base no grau de desvio. No entanto, você pode aumentar a precisão dessa pontuação se levar em consideração a análise de grupos de pares e a sazonalidade.
Análise de grupo de pares
A análise de grupo de pares é uma técnica em que modelos estatísticos são empregados para categorizar usuários e hosts que compartilham características semelhantes como um grupo. A ideia por trás do agrupamento de pares é que, ao comparar o comportamento de um usuário com o de um grupo de pares relevante, a precisão da pontuação de risco aumentará. Você pode aprender sobre o funcionamento interno da análise de grupo de pares aqui.
Sazonalidade
Uma atividade é considerada sazonal se ocorrer com um grau específico de regularidade, como por hora, diariamente, semanalmente ou mensalmente. Sua solução UEBA deve ser capaz de marcar atividades sazonais como não anômalas. Se uma atividade ocorrer fora de sua rotina sazonal, ela deve ser considerada uma anomalia e sua solução UEBA deve ser capaz de detectá-la.
Se a sazonalidade não for considerada, você pode perder pistas vitais que poderiam ter detectado e interrompido um ataque, ou seus analistas de segurança podem ser inundados com vários alertas falsos, resultando em fadiga de alerta. Levar em consideração a sazonalidade em sua solução UEBA aumentará a precisão da pontuação de risco e reduzirá os falsos positivos. Isso dará a seus analistas tempo para priorizar e responder a ameaças genuínas. Agora que você sabe por que a sazonalidade é importante, vamos dar uma olhada em como ela funciona.
Como funciona a sazonalidade?
A sazonalidade é alimentada por algoritmos de aprendizado de máquina que estudam o comportamento passado de usuários e entidades para determinar se uma atividade é anômala. Os quatro parâmetros baseados no tempo a seguir são analisados para determinar se as atividades seguem um padrão sazonal:
-
Hora do dia (ToD)
-
Data do mês (DoM)
-
Dia da semana (DoW)
-
Semana do mês (WoM)
Para entender completamente o que significa sazonalidade e como ela melhora a precisão da pontuação de risco, vamos dar uma olhada no exemplo a seguir e fazer uma comparação entre como seria se nossa solução UEBA oferecesse sazonalidade e se não oferecesse.
Considere uma organização de exemplo, chamada Anthem. Em 30 de setembro, o servidor de folha de pagamento da Anthem é acessado várias vezes em intervalos de uma hora entre 9h e 14h (consulte a Tabela 1).
Tabela 1: Dados de acesso ao servidor de folha de payroll
Neste exemplo, o ToD é o intervalo de tempo em que o servidor foi acessado (por exemplo, 09:00-10:00), o DoM é 30, o DoW é 6 (supondo que o algoritmo indexe o primeiro dia da semana , domingo, como “1”), e o WoM é 5 (já que 30 de setembro é a quinta sexta-feira do mês).
Vamos entender como esses acessos serão tratados em dois cenários: 1) com uma solução UEBA que não possui sazonalidade e 2) com uma solução UEBA que possui sazonalidade.
Cenário 1: Solução UEBA sem sazonalidade
Quando uma solução UEBA não possui sazonalidade, ela define o intervalo de tempo como uma hora (isso pode diferir dependendo do algoritmo que está sendo usado) e compara o número de acessos em cada período de uma hora com um valor limite calculado dinamicamente. Esse valor limite é calculado após considerar o número de acessos em todos os intervalos anteriores de uma hora. Isso significa que o algoritmo não olha para o histórico do número de acessos feitos entre um determinado período de tempo, digamos, 9h e 10h. Ele o considera apenas mais um intervalo de uma hora, não diferente do anterior ou posterior.
Simplificando, uma solução UEBA sem sazonalidade não considera o intervalo de tempo em que o acesso ocorre para desencadear uma anomalia. É por isso que a diferença no número de acessos efectuados entre as 12-13h e as 13-14h são consideradas anómalas (ver Tabela 2). O número de acessos durante esses períodos de tempo (250 e 750) deve ter excedido em muito o valor limite.
Tabela 2: UEBA sem sazonalidade
Cenário 2: Solução UEBA com sazonalidade
Neste caso, o algoritmo irá primeiro comparar o número de acessos no servidor de folha de pagamento com o horário do dia para decidir se é normal ou não. Por exemplo, se considerarmos os dados da Tabela 1, então a primeira verificação que o algoritmo fará é ver se 100 acessos entre 9h e 10h são normais ou não. O limite será função do número de acessos entre 9 e 10 horas em todos os dias anteriores para os quais há dados disponíveis.
Caso não seja acionada nenhuma anomalia, o algoritmo procede à segunda checagem, onde determina se o número de acessos (100) é normal para uma determinada data do mês – no caso, dia 30 – para o mesmo período de tempo, ou seja, , 9h às 10h. Isso significa que o algoritmo verificará o número de acessos feitos entre 9h e 10h do dia 30 de cada mês enquanto houver dados. Se esta verificação também produzir resultados normais, prossiga com a terceira verificação. Caso contrário, é identificado como uma anomalia.
Supondo que a contagem de acessos esteja normal até o momento, é realizada a terceira verificação, que envolve levar em consideração o dia da semana. Neste caso, é o sexto dia da semana, sexta-feira. Novamente, isso significa que o algoritmo compara o número de acessos entre 9h e 10h da sexta-feira de interesse com todas as sextas-feiras anteriores para chegar a uma conclusão.
Se novamente não houver anomalia, é feita a verificação final onde a contagem é considerada junto com a semana do mês. Assim, o algoritmo verifica se 100 acessos entre 9 e 10h das sextas-feiras da quinta semana de um mês são normais ou anômalos. Os mesmos passos são seguidos também para os outros períodos de tempo, conforme mostrado na Tabela 3.
Tabela 3: Sazonalidade em ação
Agora, você pode se perguntar: por que o algoritmo considera 750 como normal quando parece claramente um caso de atividade elevada no servidor de folha de pagamento?
A resposta para isso está nos dados históricos. Nesse caso, os dados históricos teriam mostrado que os funcionários geralmente acessam o servidor de folha de pagamento para baixar o contracheque durante o horário de almoço – entre 12 e 14 horas – no último dia útil do mês (geralmente 30). Assim, quando o algoritmo faz sua checagem usual, consegue identificar os 750 acessos como normais.
A sazonalidade é aplicável aos usuários?
Com certeza! Cada usuário pode executar uma tarefa de natureza sazonal e específica apenas para esse usuário. O algoritmo identificará esse padrão de comportamento e o alertará caso haja algum desvio dele. Por exemplo, digamos que Stacey, uma associada sênior de marketing, atualiza os novos leads gerados por sua equipe no banco de dados de marketing consolidado na última sexta-feira de cada mês. Então, o algoritmo espera esse comportamento dela. No entanto, se Stacey não apenas acessasse o banco de dados, mas o acessasse várias vezes em uma terça-feira, o algoritmo identificaria isso como uma anomalia. A pontuação de risco de Stacey aumenta e um alerta é acionado para notificar o analista de segurança.
O algoritmo calcula um limite diferente para diferentes intervalos de tempo?
Sim. O número de atividades realizadas em uma determinada hora, dia e até mês são diferentes. Como vimos no exemplo acima da empresa Anthem, é normal que o servidor de folha de pagamento seja acessado 100 vezes entre 9h e 10h e 750 vezes entre 13h e 14h no mesmo dia. O número de vezes que uma determinada atividade é realizada em um determinado período de tempo, ou em um determinado momento, será diferente, e seu algoritmo deve ser capaz de calibrar isso dinamicamente. Somente se isso acontecer, sua pontuação de risco será precisa.
Agora você conhece o funcionamento interno da sazonalidade e como ela reduz os falsos positivos e melhora a precisão da pontuação de risco. Se quiser avaliar pessoalmente como uma solução SIEM unificada, como o ManageEngine Log360 com recursos DLP e CASB, pode melhorar a pontuação de riscos de usuários e entidades, inscreva-se para uma demonstração personalizada e converse com nossos especialistas em soluções. Obrigado por ler, pessoal!
Esse post foi traduzido da nossa página em inglês SIEM Expert Talks, e sua autoria original é de Hiranmayi Krishnan.
