Casos de uso orientado a objetos

Já pensou em fazer casos de uso orientado a objetos? Que papo é esse? Como assim? Vamos explicar, veja o exemplo abaixo, qual você costuma fazer

Caso de uso

Você está acostumado a criar casos de uso através de EventID do Windows ou por parâmetros específicos no log? Errado não está, mas já pensou na gerência a logo prazo?

Caso de uso

Vamos supor que você crie uma regra de Brute Force, fazendo ela com EventID de Windows ela ficará “presa” ao Windows, mas se ao invés de fazer por EventID estruturar ela por comportamento, conseguirá abranger diversas outras soluções.

O que seria esse comportamento? Um ataque de Brute Force se origina de um sequencia de logins sem sucesso. Então o foco é a falha de login e não o Windows.

Mas vamos para um exemplo simples que pode trazer um bom trabalho futuro, você possui um caso de uso voltado a SQL Injection e para a regra gerar alerta são coletados logs do IPS X

Assinatura= SQL Injection
Action= Allow

Perfeito! Portanto sempre quando houver uma alerta no IPS o SIEM irá informar. No entanto a empresa resolveu trocar o IPS X e colocar o IPS Y e na nova solução não existe mais a assinatura de SQL Injection, o nome agora é Code Injection. Mas é só lá e trocar o nome da assinatura. Sim e Não.

Se o parâmetro Assinatura=SQL Injection está em somente uma regra sua mudança está fácil, mas e se ela está em 30 casos de uso, você terá que realizar sua ação 30 vezes. Chato não!

Então que tal você criar um Filtro, Query, Macro ou o que estiver mais fácil no seu siem e criar um objeto chamado Injection e nele um parâmetro parecido com:

Assinatura= SQL Injection OR Assinatura= Code Injection OR Assinatura= Command Injection OR Assinatura= XSS Injection OR Assinatura= LDAP Injection OR ………….

Certamente esse tipo de objeto ajudará em momentos como citado no exemplo acima, no qual a solução é trocada e também em casos de evolução da regra, se amanhã ou depois você precisar adicionar uma assinatura nova é só ir no objeto e adicionar, com isso todas as regras que ele está atrelado estarão contempladas.

Fica mais fácil desenhando.

EXEMPLOS

Sem orientação a objeto

  • Caso de uso 1 = Cross Site Script
  • Caso de uso 2 = Sql Injection
  • Caso de uso 3 = Code Injection
  • Caso de uso 4 = Command injection

Com orientação a objeto

  • Caso de uso 1 = Injection attack

___________________________________________________________________________

Mais um exemplo para facilitar

Sem orientação a objeto

  • Alerta 1 = Vírus não bloqueado (Device=Antivírus action=allow)
  • Alerta 2 = IP com má reputação (Device=Antivírus action=allow)
  • Alerta 3 = Hash suspeito (Device=Antivírus action=allow)
  • Alerta 4 = USB comprometido (Device=Antivírus action=allow)
  • Alerta 5 = Callback (Device=Antivírus action=allow)

Mas a empresa trocou o fabricante do antivírus e o campo action agora não é mais allow e sim Success. Entra em um por um e muda o action

Com orientação a objeto

  • Alerta 1 = Vírus não bloqueado (Device=Antivírus `filtro de ação com sucesso`)
  • Alerta 2 = IP com má reputação (Device=Antivírus `filtro de ação com sucesso`)
  • Alerta 3 = Hash suspeito (Device=Antivírus `filtro de ação com sucesso`)
  • Alerta 4 = USB comprometido (Device=Antivírus `filtro de ação com sucesso`)
  • Alerta 5 = Callback (Device=Antivírus `filtro de ação com sucesso`)

Mas a empresa trocou o fabricante, só ir no filtro de ação com sucesso e automaticamente atendeu todos os casos de uso.

E agora!? Acha que compensa troca a maneira de criar casos de uso para uma estrutura orientada a objeto?

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.