A Análise de Comportamento de Usuários e Entidades (UEBA), um mecanismo de detecção de anomalias de uma solução SIEM, é alimentada por algoritmos de machine learning para identificar desvios do comportamento esperado de usuários e entidades. O UEBA identifica anomalias de tempo, contagem e padrão. Com base na análise comportamental, esses usuários e entidades recebem uma pontuação de risco dinâmica (por exemplo, entre zero e 100) com base no grau de desvio. No entanto, é possível aumentar a precisão dessa pontuação se você levar em consideração a análise de grupos de pares e a sazonalidade.
O que é sazonalidade em segurança cibernética?
Uma atividade é considerada sazonal se ocorrer com um grau específico de regularidade, como horária, diária, semanal ou mensal. Para uma segurança cibernética eficaz, 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 ferramenta de detecção de anomalias deve ser capaz de detectá-la.
Se a sazonalidade não for considerada, você poderá perder pistas vitais que poderiam ter detectado e impedido um ataque, ou seus analistas de segurança poderão ser inundados com inúmeros alertas falsos, resultando em fadiga de alertas. Levar a sazonalidade em consideração em sua solução UEBA aumentará a precisão da pontuação de risco e reduzirá os falsos positivos. Isso dará aos seus analistas tempo para priorizar e responder a ameaças reais. Você pode aprender mais sobre a importância da sazonalidade na detecção de anomalias em segurança cibernética aqui.
Agora que você sabe por que a sazonalidade na detecção de anomalias é importante, vamos ver como ela funciona.
Como funciona a sazonalidade?
A sazonalidade é alimentada por algoritmos de machine learning que estudam o comportamento passado de usuários e entidades para determinar se uma atividade é anômala. A forma como o algoritmo de detecção de anomalias identifica desvios em atividades sazonais varia de fornecedor para fornecedor. No entanto, em uma solução SIEM integrada à UEBA, como o ManageEngine Log360, o modelo de detecção de anomalias analisa os quatro parâmetros temporais a seguir 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 chamada Anthem. Em 30 de setembro, o servidor de folha de pagamento da Anthem foi acessado várias vezes em intervalos de uma hora, entre 9h e 14h (ver Tabela 1).
| Período de tempo | Número de acessos no servidor de folha de pagamento |
|---|---|
| 09:00 - 10:00 | 100 |
| 10:00 - 11:00 | 125 |
| 11:00 - 12:00 | 150 |
| 12:00 - 13:00 | 250 |
| 13:00 - 14:00 | 750 |
Tabela 1: Dados de acesso ao servidor de folha de pagamento
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 (assumindo que o algoritmo indexa 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 tem sazonalidade, e 2) com uma solução UEBA que tem sazonalidade.
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 variar dependendo do algoritmo utilizado) e compara o número de acessos em cada período de uma hora com um valor de threshold calculado dinamicamente. Ele é calculado após considerar o número de acessos em todos os intervalos de uma hora anteriores. Isso significa que o algoritmo não analisa o histórico do número de acessos realizados entre um período específico, digamos, 9h e 10h. Ele o considera apenas mais um intervalo de uma hora, sem diferença 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 realizados entre 12h e 13h e 13h e 14h é considerada anômala (ver Tabela 2). O número de acessos durante esses períodos (250 e 750) deve ter excedido em muito o valor de threshold.
| Período de tempo | Número de acessos em um servidor | Contagens vs. intervalo de tempo | Resultado |
|---|---|---|---|
| 09:00 - 10:00 | 100 |  | Normal |
| 10:00 - 11:00 | 125 | | Normal |
| 11:00 - 12:00 | 150 | | Normal |
| 12:00 - 13:00 | 250 |  | Anomalia |
| 13:00 - 14:00 | 750 | | Anomalia |
Tabela 2: UEBA sem sazonalidade
Solução UEBA com sazonalidade
Nesse caso, o algoritmo 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, a primeira verificação que o algoritmo realizará será para verificar se 100 acessos entre 9h e 10h são normais ou não. O threshold será uma função do número de acessos entre 9h e 10h em todos os dias anteriores para os quais há dados disponíveis.
Se uma anomalia não for acionada, o algoritmo prossegue com a segunda verificação, onde determina se o número de acessos (100) é normal para uma determinada data do mês — neste caso, o dia 30 — para o mesmo período, ou seja, das 9h às 10h. Isso significa que o algoritmo verificará o número de acessos realizados entre 9h e 10h do dia 30 de cada mês, enquanto os dados existirem. Se essa verificação também produzir resultados normais, ele prossegue com a terceira verificação. Caso contrário, é identificado como uma anomalia.
Supondo que a contagem de acessos esteja normal até o momento, a terceira verificação é realizada, 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 o de todas as sextas-feiras anteriores para chegar a uma conclusão.
Se isso não resultar em nenhuma anomalia, a verificação final é realizada, considerando a contagem e a semana do mês. Assim, o algoritmo verifica se 100 acessos entre 9h e 10h das sextas-feiras da quinta semana do mês são normais ou anômalos. Os mesmos passos são seguidos para os outros períodos, conforme mostrado na Tabela 3.
| Período de tempo | Número de acessos em um servidor | ToD | DoM | DoW | WoM | Resultado |
|---|---|---|---|---|---|---|
| 09:00 - 10:00 | 100 | | | | | Normal |
| 10:00 - 11:00 | 125 | | | | | Normal |
| 11:00 - 12:00 | 150 | | | | | Normal |
| 12:00 - 13:00 | 250 | | | | | Normal |
| 13:00 - 14:00 | 750 | | | | | Normal |
Tabela 3: Sazonalidade em ação
Agora, você deve estar se perguntando: por que o algoritmo considera 750 como normal quando claramente parece 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 normalmente acessam o servidor de folha de pagamento para baixar seus holerites durante o horário de almoço — entre meio-dia e 14h — no último dia útil do mês (geralmente o dia 30). Assim, quando o algoritmo faz sua verificação habitual, ele consegue identificar os 750 acessos como normais.
Explorando mais profundamente a sazonalidade
A esta altura, você provavelmente já tem uma boa noção de como funciona a sazonalidade. No entanto, talvez ainda tenha algumas dúvidas, como:
- A sazonalidade também se aplica aos usuários?
- O threshold calculado pelo algoritmo será diferente para diferentes intervalos de tempo?
Vamos abordar essas questões uma de cada vez.
A sazonalidade é aplicável aos usuários?
Com certeza! Cada usuário poderia realizar uma tarefa sazonal e específica para ele. O algoritmo identificará esse padrão de comportamento e alertará você caso haja algum desvio. Por exemplo, 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. Portanto, 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 threshold diferente para intervalos de tempo diferentes?
Sim. O número de atividades realizadas em uma determinada hora, dia e até mês é diferente. Como vimos no exemplo do Anthem acima, é 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 qualquer horário, será diferente, e seu algoritmo deve ser capaz de calibrar isso dinamicamente. Somente se isso for possível, sua pontuação de risco será precisa.
Agora você conhece o funcionamento interno da sazonalidade e como ela reduz falsos positivos e melhora a precisão da pontuação de risco. Para saber mais sobre machine learning em SIEM, assista a esta série de webinars. Para avaliar pessoalmente como uma solução de SIEM unificada, como o ManageEngine Log360 com recursos UEBA, pode melhorar a pontuação de risco de usuários e entidades, inscreva-se para uma demonstração personalizada e converse com nossos especialistas em soluções.
