Imagine a situação: você passou muito tempo escrevendo e depurando regras de correlação e, um dia depois, descobriu que elas não funcionavam. Como se costuma dizer, isso nunca aconteceu e aqui de novo! Acontece que à noite a rede foi atualizada novamente e alguns servidores foram substituídos, mas as regras de correlação não levam isso em consideração. Neste artigo, mostraremos como ensinar o SIEM a se adaptar ao cenário em constante mudança da infraestrutura.



Estamos chegando cada vez mais perto do final da série de artigos dedicados à criação de regras de correlação adaptativas que funcionam imediatamente. O artigo acabou sendo longo, quem quiser pode imediatamente tirar conclusões precipitadas .

No artigo “Metodologia para normalização de eventos” , resumimos técnicas que ajudarão a minimizar o problema de perda de dados e normalização incorreta dos eventos iniciais. No entanto, pode-se argumentar que, se o papel dos erros de normalização for reduzido, é possível criar regras de correlação que funcionem imediatamente. Teoricamente, sim, se o objeto de monitoramento monitorado pelo SIEM fosse estático e funcionasse exclusivamente conforme escrito nos termos de referência. Mas, na prática, verifica-se que no mundo real não há nada estático.

Portanto, consideraremos com mais detalhes o objeto de monitoramento. O SIEM coleta logs de fontes, extrai endereços IP, contas de usuário, acesso a arquivos e chaves do registro, interações de rede. Se tudo estiver resumido, isso não passa de informações sobre os estágios do ciclo de vida de um sistema automatizado (daqui em diante - AS). Assim, o objeto de monitoramento SIEM é um sistema automatizado como um todo ou parte dele.

Um sistema de alto-falantes não é um objeto estático, tende a mudar constantemente: novos trabalhos e servidores são introduzidos, equipamentos antigos são descomissionados e substituídos por novos, sistemas “travam” devido a erros e são restaurados a partir de backups. A dinâmica no nível da rede, como endereçamento ou roteamento dinâmico, muda a aparência dos alto-falantes todos os dias. Como verificá-lo? Tente encontrar em sua empresa um esquema L3 completo e atual da rede e verifique com os administradores de rede quanto isso reflete o estado atual das coisas.

Ao desenvolver regras de correlação, você tenta prosseguir com a aparência dos palestrantes aqui e agora. Ao testar as regras de correlação, você as refina para um estado em que elas possam trabalhar com o menor número de falsos positivos na configuração atual do alto-falante. Como os oradores estão mudando constantemente, as regras de correlação, mais cedo ou mais tarde, terão que ser atualizadas.

Agora vamos complicar a tarefa e considerar as regras fornecidas por especialistas externos, como SOCs comerciais, integradores que implementam o SIEM ou desenvolvedores de soluções SIEM. Essas regras não incluem os recursos dos seus alto-falantes - o contexto de execução - eles não são otimizados para eles. Esse problema é outro obstáculo no conceito de regras de correlação que funcionam imediatamente. Sua solução pode ser o SIEM dentro de si:

1. Constrói um modelo dos alto-falantes observados.
2. Sempre mantém esse modelo atualizado.
3. Permite usar esse modelo como o contexto de execução nas regras de correlação.

Contexto - Modelo de Sistema Automatizado

Primeiro, descrevemos a composição do modelo do alto-falante. Se nos voltarmos para a definição clássica de termo de GOST 34.003-90 , um AS é "um sistema que consiste em pessoal e um conjunto de ferramentas de automação para suas atividades que implementa a tecnologia da informação para executar funções estabelecidas". É importante que, ao implementar a tecnologia da informação, o pessoal (usuários) e as ferramentas de automação operem com dados.

Como o SIEM coleta informações de muitas fontes diferentes, incluindo TI, segurança da informação e aplicativos de negócios, todas as partes dessa definição serão “visíveis” diretamente para nós nos eventos.

A seguir, descreveremos como é o modelo criado para essas entidades como um usuário, um conjunto de ferramentas de automação (doravante denominadas rede e sistemas de computador) e dados.

Infelizmente, é bastante difícil modelar processos tecnológicos dentro da estrutura do SIEM, porque essa classe de soluções não se destina a isso. No entanto, parte dos processos é visível através dos modelos de comportamento dessas entidades.


Modelo de alto-falante geral

Além disso, consideraremos cada entidade e insistiremos em:

• identificação única;
• a composição do modelo;
• encontrar dados necessários para o modelo;
• a natureza da mudança nos dados da entidade;
• atualizando dados no modelo quando eles mudam.

Modelo de usuário

Identificação

Um usuário de um AS deve ser entendido como uma pessoa específica: um funcionário de uma empresa, empreiteiro ou freelancer. É importante que ele tenha autorizado o acesso aos alto-falantes.

Informações sobre usuários de AS geralmente são fragmentadas em muitos sistemas. Para montá-lo, você precisa fazer um esforço. Vejamos um exemplo de onde e quais informações podem ser coletadas para um usuário específico.

1. Microsoft Active Directory e Microsoft Exchange. A partir deles, podemos descobrir seu login de domínio principal e endereço de e-mail.
2. O Cisco Identity Services Engine (ISE) armazena seu segundo login para acesso remoto via VPN.
3. O banco de dados do portal interno armazena seu terceiro logon.
4. Se o usuário for um administrador de banco de dados, o quarto logon será armazenado no DBMS e talvez não um.
5. Banco de dados de RH, no qual seu nome completo é armazenado (caso o Active Directory tenha preguiça de obter o usuário de acordo com todas as regras).

Portanto, se a empresa não tiver soluções de gerenciamento de identidade ou de direitos de usuário que de alguma forma ajudem a reunir essas informações de identificação díspares, você deverá fazer isso manualmente no SIEM.

Para resumir:

1. O SIEM requer um único ID de usuário.
2. Quando as contas de usuário aparecem em qualquer log, qualquer sistema, devemos identificá-lo exclusivamente e afixar nosso próprio identificador de usuário exclusivo.

Composição do modelo

Ao compor um modelo de qualquer entidade, o dividimos em dois blocos. O primeiro bloco é usado para armazenar informações gerais sobre a entidade, o segundo é responsável por compilar um modelo do comportamento da entidade. Esse perfil pode ser usado por regras de correlação para identificar desvios anormais no comportamento de uma entidade.

No mínimo, o seguinte deve ser incluído no modelo geral do usuário:

• ID de usuário único no SIEM
• todos os seus identificadores de vários sistemas, incluindo:
  
  • endereços de email externos e internos;
  • Nome completo;
  • Conta do SO local
  • conta de domínio;
  • Conta VPN
  • Conta proxy
  • Contas DBMS
  • Contas em outros sistemas de aplicativos.
• Unidade organizacional no Microsoft Active Directory da qual o usuário é membro;
• Grupos do Microsoft Active Directory aos quais o usuário é membro.

No mínimo, o modelo comportamental de um usuário deve incluir:

• tipo de conexão usada (local, remota) e tipo de canal de comunicação (com fio, sem fio);
• dispositivos usados ​​para acessar a rede corporativa;
• aplicações usadas;
• ligação geográfica, especialmente para usuários remotos;
• recursos da empresa aos quais o usuário se conecta;
• para quem e quais dados são transferidos (fluxos de informação).

Modelo de usuário

A criação de perfil de fluxos de informações é uma tarefa difícil para a qual o SIEM geralmente não possui mecanismos convenientes e simples. Mas a criação desse perfil pode começar com o email e os recursos de rede compartilhados usados.

Fontes de dados para o modelo

Onde obter os dados necessários para construir o modelo? Considere os dois princípios principais para obter informações disponíveis na maioria dos SIEMs - métodos de coleta ativos e passivos.

Com o método ativo, o próprio SIEM se volta para fontes que contêm os dados necessários para a construção do modelo.
Com o método passivo, o modelo é preenchido com base em dados de eventos recebidos no SIEM de fontes.

Como regra, para obter o modelo mais completo, é melhor combinar dois métodos.

É importante entender que os dados coletados na estrutura do modelo devem ser constantemente atualizados e feitos no modo automático, e não no manual. Exatamente os mesmos métodos usados ​​para sua coleta inicial serão adequados para atualizar os dados.

Considere quais fontes podem fornecer dados para a construção do modelo e de que maneiras você pode obter as informações necessárias.

Modelo de Sistemas de Rede e Computação

Identificação

Por elementos dos sistemas de rede e computação, entendemos estações de trabalho, equipamentos de servidor e rede e ferramentas de segurança da informação. No momento, no SIEM e nas soluções de Gerenciamento de Vulnerabilidades, eles são chamados de ativos.

Parece óbvio que esses ativos podem ser facilmente identificados pelo endereço IP, endereço MAC, FQDN ou nome do host (a seguir denominadas chaves de identificação originais). Esse é sempre o caso? Como indicado acima, algumas mudanças estão ocorrendo constantemente na UA. Vamos ver algumas dessas mudanças e pensar em como nossas chaves de identificação originais se comportam.

1. Use em uma rede DHCP. Os endereços IP dos ativos estão mudando.
2. Nós de comutação em uma configuração de cluster. Dependendo do tipo de cluster, o MAC e o IP podem mudar.
3. Restaurando um sistema de um backup em outro servidor devido a uma falha crítica. Os endereços MAC são alterados, às vezes IP, FQDN e nome do host.
4. Substituição planejada, modernização de equipamentos ou partes de alto-falantes. Quase todas as teclas podem mudar.

Em uma empresa pequena, essas alterações podem ser extremamente raras e podem ser tratadas pelos especialistas responsáveis ​​pelo SIEM. Mas e se uma empresa com uma ampla rede de filiais? E longe de sempre, o serviço de SI possui comunicações bem estabelecidas com o serviço de TI, o que significa que o especialista em SIEM pode não obter as informações necessárias sobre alterações no AS.

Como você não pode confiar no IP, MAC, FQDN ou Nome do host separadamente para identificar um ativo, tente identificá-lo imediatamente pelos quatro parâmetros. Aqui estamos diante de um problema global: o SIEM opera em eventos, e eles quase nunca contêm todas as chaves de identificação originais ao mesmo tempo.

Como pode ser resolvido? Vejamos algumas opções:

1. Método ativo usando soluções do nível CMDB (Configuration Management Database) . Informações sobre as chaves de identificação originais podem ser obtidas a partir daí. Mas o CMDB contém todas as chaves de origem dos ativos necessários para identificação? E, mais importante, leva em conta as mudanças nos alto-falantes descritos acima? Também é importante considerar o tempo de atualização dos dados no CMDB, se os dados ficarem dezenas de minutos ou horas atrás do estado real do AS - provavelmente, essa solução não será adequada para uso na correlação de eventos de fluxo no SIEM.
2. Maneira ativa usando a solução de Gerenciamento de Vulnerabilidades . Você pode fazer upload de seus relatórios para o SIEM, como, por exemplo, o Micro foca o ArcSight. Mas existe uma garantia de que um scanner de terceiros trará todos os dados necessários para a identificação? Qual será a relevância se as verificações forem realizadas não mais do que uma vez por mês (média para grandes empresas) e longe de cobrir toda a infraestrutura.
3. Maneira passiva . Identifique ativos de eventos, apesar de seus dados incompletos e imprecisos. Os eventos não contêm todas as chaves; fontes diferentes enviam conjuntos de chaves diferentes. No entanto, esta é a maneira mais rápida de obter informações sobre alterações nos alto-falantes. As fontes, em regra, geram eventos em todas as situações descritas acima, com exceção da substituição planejada do equipamento.
4. Maneira híbrida . Aproveite todas as abordagens de uma só vez:
   
   • A coleta ativa com o CMDB permite o rápido preenchimento inicial de ativos SIEM.
   • A integração com o Vulnerability Management adicionará as informações ausentes.
   • Uma análise de eventos permitirá que você atualize rapidamente o modelo, levando em consideração as especificidades de cada fonte individualmente.
   
   O método híbrido permite nivelar os problemas dos outros, mas é difícil de implementar.

No momento, trabalhei apenas com duas soluções em que os fabricantes tinham o conhecimento necessário para implementar essa abordagem: IBM QRadar (descrição geral por referência , detalhes de algoritmo fechados) e Positive Technologies MaxPatrol SIEM (detalhes de algoritmo fechados). No momento, as duas empresas continuam a usar e melhorar precisamente a abordagem híbrida.

Então:

1. Estações de trabalho, equipamentos de rede e servidor devem ser identificados de maneira híbrida, agregando dados do CMDB, sistemas de gerenciamento de vulnerabilidades e eventos das próprias fontes.
2. Para a correta combinação e atualização das informações coletadas para identificação, é necessário ter mecanismos especializados que levem em consideração as características de cada fonte.

Composição do modelo

Os sistemas de computação, incluindo software de sistema e aplicativo instalado, carregam muitas informações necessárias para melhorar a precisão das regras de correlação.

Assim como o modelo de usuário, o modelo de rede e sistemas de computação consiste em uma parte comum e comportamental.

A composição do modelo geral de rede e sistemas de computação deve incluir pelo menos:

• hardware (incluindo dispositivos externos);
• usuários acabados;
• serviços instalados e seu pacote com portas abertas;
• software instalado e sua versão;
• atualizações instaladas;
• vulnerabilidades existentes;
• tarefas agendadas
• lista de software para inicialização;
• tabelas de roteamento;
• recursos de rede compartilhados.

A composição do modelo comportamental dos sistemas de rede e computação deve incluir pelo menos:

• Interações de rede de L3 e L4 (com o que interage e de acordo com quais protocolos);
• A quantidade média de dados transmitidos por semana;
• quais usuários estão usando;
• a partir da qual nós o controle remoto é implementado;
• estatísticas da operação dos recursos de segurança para este host (rede e local).

Modelo de Sistemas de Rede e Computação

Fontes de dados para o modelo

A coleta de informações para este modelo é possível de duas maneiras: ativa e passiva.

Considere o modelo geral:

Modelo de Dados Protegido

Identificação

Vamos para o último componente do contexto - o modelo de dados protegido.

Na maioria das vezes, o SIEM não é usado para monitorar dados protegidos, pois existem soluções para a classe Data Leak Prevention (DLP) para isso. No entanto, esse conhecimento ajuda a avaliar com mais precisão a importância do incidente. Por exemplo, ao escrever uma regra de correlação, seria útil saber que o incidente não ocorre apenas em alguma estação de trabalho, mas na estação que atualmente armazena o relatório financeiro do ano ou outras informações confidenciais.

A identificação de informações confidenciais é implementada por um mecanismo de pesquisa de impressões digitais na própria solução DLP. A especificidade do mecanismo não permite implementá-lo no SIEM. Assim, em termos de identificação de dados protegidos, é possível usar apenas uma forte integração com as soluções da classe DLP.

Composição do modelo

Devido ao fato de o DLP implementar a maior parte do monitoramento e proteção de informações confidenciais, a composição do modelo no SIEM é bastante compacta.

No mínimo, o seguinte deve ser incluído no modelo geral de dados protegidos:

• em quais ativos as informações confidenciais são armazenadas;
• quais usuários têm acesso a informações confidenciais.

Pelo menos o seguinte deve ser incluído no modelo comportamental de dados protegidos:

• entre os quais ativos são transmitidas informações confidenciais;
• entre os quais os usuários transmitem informações confidenciais.

Modelo de Dados Protegido

Fontes de dados para o modelo

Para construir um modelo de dados protegidos, dois métodos de obtenção de informações também estão disponíveis - ativos e passivos.

Considere o modelo geral:

Mecanismos de implementação de modelos no SIEM

Vamos ver como é possível implementar um modelo de alto-falante no SIEM. Para fazer isso, no nível SIEM, duas questões principais precisam ser abordadas:

1. Como implementar a coleta de dados ativa e passiva.
2. Onde e de que forma armazenar o modelo.

A coleta de dados ativa para o modelo, como regra, é realizada pelos mecanismos de integração SIEM com scanners de segurança. Além disso, a coleta ativa pode ser realizada baixando dados de fontes externas, por exemplo, bancos de dados.

A coleta passiva é realizada através da análise de eventos que passam pelo SIEM.

, SIEM , /Active List/Reference set of set . . , ( , , ..) .

SIEM- .

, , , , . , , . SIEM 6 ( 2018 Cost of a Data Breach Study by Ponemon ). : , , , «» . , , , .

: , SIEM, , .

Conclusões

:

1. , , .
2. .
3. SIEM .
4. :
   
   • ;
   • , ;
   • .
5. , , :
   
   • ;
   • .
6. , . .
7. .
8. , , , .
9. SIEM .

---

:

SIEM: « ». 1: ?

SIEM: « ». 2. «»

SIEM: « ». 3.1.

SIEM: « ». 3.2.

SIEM: « ». 4. ( )

SIEM: « ». 5.