Este é o segundo artigo da série, que é dedicado à metodologia para criar regras de correlação prontas para uso em sistemas SIEM. No artigo anterior , nos propusemos a essa tarefa, descrevemos as vantagens que serão obtidas em sua implementação e também listamos os principais problemas que estão em nosso caminho. Neste artigo, começaremos a buscar soluções e começar com o problema de transformar o modelo do “mundo” , bem como sua manifestação no estágio de normalização dos eventos.



O problema de transformar o modelo do “mundo” foi descrito no primeiro artigo. Vamos relembrar brevemente sua essência: quando um fenômeno ocorre na fonte de eventos (por exemplo, iniciando um processo no sistema operacional), ele é corrigido em diferentes formatos, primeiro na memória, depois no log de eventos do sistema operacional e depois no sistema SIEM. Cada estágio do processamento é acompanhado pela perda de dados, pois no nível do sistema operacional existe um modelo "mundial" e, no log do sistema operacional, outro, limitado por um conjunto de campos, pelo esquema de log. Assim, há uma reflexão (transformação) de um modelo com um grande número de parâmetros para outro, com um número menor deles. Normalizar e salvar um evento no SIEM é outra transformação que também ocorre com a perda de dados, uma vez que o SIEM também possui seu próprio modelo de "mundo".

É difícil encontrar uma maneira que permita a transformação de um modelo em outro sem perda. Conhecendo essa limitação, é necessário formular tal abordagem para normalização e a formação de uma lista de campos do esquema de eventos, nos quais as informações não seriam perdidas, importantes na correlação e na investigação adicional de incidentes de segurança da informação.

Dentro da estrutura do SIEM, um modelo é representado por um esquema - um conjunto de campos nos quais os dados do evento inicial se encaixam no processo de normalização. No futuro, será utilizado por especialistas na criação de regras de correlação. Para que os investigadores de incidentes e os responsáveis ​​pelo desenvolvimento de regras de correlação interpretem sem ambiguidade os eventos normalizados, o esquema deve satisfazer as propriedades básicas:

• ser unificado para eventos de qualquer tipo e fonte;
• descreva claramente quem interagiu com quem e como;
• mantenha a essência e o contexto da interação.

No processo de desenvolvimento de regras de normalização, as informações sobre a interação devem ser encontradas no evento inicial e decompostas em campos especialmente designados. O mesmo precisa ser feito com o contexto e a essência da interação (mais sobre isso no próximo artigo).

Surge a pergunta: é possível identificar esquemas típicos para interações que satisfizessem qualquer evento criado por todas as fontes possíveis de segurança de TI e informações? Em caso afirmativo, como são esses esquemas?

Para encontrar a resposta para essas perguntas, você precisa recorrer à análise e tentar analisar o maior número possível de regras de normalização já desenvolvidas e operando em soluções SIEM para identificar padrões comuns. Como parte desse trabalho, foi possível analisar mais de 3.000 regras de normalização de mais de 100 fontes diferentes de soluções como Positive Technologies MaxPatrol SIEM e Micro Focus ArcSight. A análise resultou nas seguintes conclusões:

1. Existem esquemas de interação típicos.
2. Em cada evento individual, como regra, há informações sobre a interação no nível da rede e no nível do aplicativo .
3. Os padrões de interação típicos podem variar em diferentes níveis, e isso deve ser levado em consideração.

Esquemas de comunicação da rede e da camada de aplicativos

Descrevemos esquemas típicos para cada nível. Antes disso, você precisa destacar as entidades que estão sempre presentes nos eventos. Além disso, com base neles, serão criados esquemas de interação. Estes incluem:

• Assunto . Uma entidade que afeta um objeto. Por exemplo, um usuário alterando uma chave do Registro ou um host com IP 10.0.0.1, enviando um pacote para um host com IP 20.0.0.1.
• Objeto . A entidade afetada pelo Assunto.
• Fonte Como regra, um host que registra a interação do Assunto com o Objeto e gera o próprio evento. Por exemplo, a Origem será um firewall que registrou a transmissão de pacotes do host - o Assunto com IP 10.0.0.1, para o host - o Objeto com IP 20.0.0.1.
• Transmissor Há casos em que o SIEM recebe eventos não diretamente da fonte, mas de um servidor intermediário pelo qual esses eventos passam. O exemplo mais simples é um servidor syslog intermediário. Um exemplo é mais complicado - quando o Transmissor pode ser um servidor de gerenciamento, por exemplo, o Kaspersky Security Center. Nesse caso, a Origem é um agente específico do Kaspersky Endpoint Security.

No entanto, nem todas as entidades podem ser representadas simultaneamente no evento (mais sobre isso mais adiante), portanto, é importante entrar inicialmente em contratos, pois nesse caso os campos correspondentes do esquema são preenchidos. No futuro, isso ajudará a distinguir claramente os casos em que esses campos não foram preenchidos devido a um erro de um especialista que está desenvolvendo regras de normalização dos casos em que o evento original realmente não continha dados sobre nenhuma entidade.

Vamos seguir para padrões de interação e exemplos de eventos. Para maior clareza, todos os exemplos serão dados com base em logs de arquivos, mensagens syslog ou registros em um banco de dados relacional, mas eles podem ser usados ​​para outros formatos de log, por exemplo, binários.

Nível de rede

O identificador principal para entidades no nível da rede são os endereços IP. É importante entender que pode haver outros identificadores relacionados - endereços MAC no nível do canal, FQDN - no nível do aplicativo. Surge a pergunta: eles estão falando sobre a mesma entidade ou diferente? Esses identificadores podem mudar ao longo do tempo com a mesma entidade? Um artigo separado será dedicado a isso. Agora, vamos nos concentrar no fato de que o identificador principal dos modelos de interação no nível da rede é o endereço IP.

Portanto, os esquemas de interação típicos desse nível podem ser divididos em duas classes - básica e degenerada.

Esquemas básicos de interação

Esquema 1. Esquema completo de interação

Dentro da estrutura deste modelo, no evento recebido na entrada SIEM, todas as principais entidades podem ser distinguidas: Assunto, Objeto, Origem, Transmissor. No esquema de interação, o Sujeito atua no Objeto. Esse efeito registra (observa) a Fonte e gera um evento. O evento da Fonte entra no Transmissor e a partir dele entra no SIEM.

O evento abaixo captura a resolução da interação de rede entre hosts pelo firewall da Stonesoft (agora Forcepoint), enquanto o evento em si não entra no SIEM diretamente, mas em um servidor syslog intermediário.



Aqui:
40.0.0.1 - Transmissor (servidor syslog intermediário),
30.0.0.1 - Origem (nó do firewall),
10.0.0.1 - Assunto (enviando pacotes UDP),
20.0.0.1 - Um objeto (recebendo pacotes UDP).


Diagrama 2: Diagrama de coleta direta sem transmissor

Nem sempre no esquema de interação é um transmissor. Como regra, ele está presente quando um servidor intermediário (por exemplo, um servidor syslog) é usado para transmitir eventos ou quando a solução da qual os eventos são coletados possui um sistema de gerenciamento centralizado - por exemplo, Kaspersky Security Center, Check Point Smart Console ou Cisco Prime. Sob esse esquema, os eventos caem no SIEM diretamente da Fonte. A maioria dos eventos é descrita por esse esquema específico. A propósito, um exemplo de um evento desse tipo pode ser visto na Figura 1 , se não houvesse um servidor syslog intermediário nele e recebemos eventos diretamente do firewall.



Aqui:
30.0.0.1 - Origem (nó do firewall),
10.0.0.1 - Assunto (enviando pacotes UDP),
20.0.0.1 - Um objeto (recebendo pacotes UDP).


Esquema 3. Interação com muitos objetos

Esse esquema de interação no nível da rede é bastante raro e, como regra, é típico para eventos de equipamentos de rede. No esquema, um Assunto interage com muitos Objetos, uma interação semelhante está presente em eventos que descrevem difusões de difusão seletiva, unicast ou difusão.

Observe que, às vezes, muitos objetos podem ser unidos por um identificador comum - um endereço de sub-rede ou um endereço de broadcast. Isso deve ser lembrado, pois ao analisar eventos, inclusive no nível das regras de correlação, você pode pular facilmente a interação potencialmente importante, pois nesse esquema o endereço do Objeto fica oculto atrás do endereço do grupo.

O exemplo a seguir demonstra um evento de um servidor de retransmissão IGMP através do qual uma solicitação de associação multicast é transmitida.



Aqui:
30.0.0.1 - Origem (servidor de IGMP Relay),
10.0.0.1 - Assunto (solicitando participação em um grupo),
224.0.0.252 - O objeto (endereço multicast).

Esquemas degenerados

Assunto, Objeto e Origem são as entidades básicas no grupo de esquemas básicos de interação. No entanto, há casos em que uma das entidades pode estar ausente no evento.


Esquema 4. Interação sem um Objeto

Frequentemente, esse padrão é típico em situações nas quais o Sujeito relata uma mudança em seu estado interno - ou seja, ele atua simultaneamente no papel do Sujeito e do Objeto. Por exemplo, essa interação pode ser observada em eventos de alteração de configuração ou detecção de malware na estação de trabalho. Mas essas informações não são registradas pelo próprio sujeito, mas por um sistema de gerenciamento centralizado e armazenadas em seu diário.

O exemplo mostra como o Symantec Management Server captura que o agente do Symantec Endpoint Protection que ele gerencia detectou um arquivo malicioso em seu host.



Aqui:
30.0.0.1 - Origem (Symantec Management Server),
10.0.0.1 - Assunto (Symantec Endpoint Protection Agent).


Esquema 5. Combinando o papel do Sujeito e do Objeto na Fonte

O último esquema de interação degenerada é típico para uma situação em que o SIEM recebe eventos de uma Origem relatando uma alteração em seu estado interno: por exemplo, reconfigurando um dispositivo ou software, habilitando ou desabilitando uma porta de rede. Nesse esquema, o papel da Fonte coincide com o papel do Sujeito e do Objeto. Ao contrário do esquema anterior, aqui os eventos no SIEM vêm diretamente.

Neste exemplo, um switch baseado no Cisco IOS informa que sua interface foi transferida para o status UP.



Aqui 30.0.0.1 é a fonte (switch).

Nível de aplicação

Nesse nível, há interações de entidades já conhecidas: Assunto, Objeto. No entanto, todas as informações sobre a fonte e o transmissor permanecem diretamente no nível da rede e não são refletidas no nível do aplicativo.

A maioria de todos os tipos de eventos incorpora interações simultaneamente no nível da rede e no nível do aplicativo. No entanto, observamos que os eventos gerados diretamente pelo software aplicativo, por exemplo, 1C: Enterprise, Microsoft SQL Server ou Oracle Database, podem conter exclusivamente interações no nível do aplicativo.

Além disso, uma entidade de Recurso adicional aparece no nível do aplicativo.

Um recurso é uma entidade intermediária através da qual o Assunto exerce influência sobre o Objeto sem interação direta. Por exemplo, concedendo a Alex os direitos de acessar o MyFile para Bob. Aqui Alex é o Assunto, Bob é o Objeto, MyFile é o Recurso. Observe que, neste exemplo, Alex não interage diretamente com Bob.

Importante : os eventos no nível do aplicativo podem conter parâmetros adicionais do Assunto e do Objeto, além do próprio Recurso. Por exemplo, parâmetros adicionais de um Recurso, como um "arquivo", podem ser o diretório em que ele está localizado ou seu tamanho.
Nesse caso, o Assunto, Objeto e Recurso são identificados por nome ou identificador exclusivo: endereço de email, nome do arquivo, nome do diretório, nome da tabela no banco de dados.

Considere padrões de interação adicionais específicos para a camada do aplicativo.


Figura 6. Interação de recursos

Neste diagrama, o Assunto atua indiretamente no Objeto através de um Recurso intermediário. Como regra, os eventos com esse esquema são claramente visíveis nos logs de auditoria do banco de dados ou ao trabalhar com direitos de acesso a arquivos e diretórios no nível do SO.

O exemplo mostra uma entrada do banco de dados de auditoria do banco de dados Oracle. Ele corrige o processo de revogar uma função de um usuário.



Aqui:
"ALEX" - Assunto (nome de usuário que retira a função),
"BOB" - Objeto (nome do usuário que está sendo revogado),
"ROLE" - Recurso (nome da função revogada).


Diagrama 7. Interação com muitos recursos

No nível do aplicativo, bem como no nível da rede, existem tipos de eventos nos quais o Assunto interage com o Objeto imediatamente por meio de muitos Recursos. É muito raro, mas há momentos em que o número de objetos também é mais do que um. Esses tipos de eventos aparecem ao corrigir operações em massa. Por exemplo, concedendo acesso a vários arquivos a um usuário ou alterando o conjunto de regras incluídas na política.

No exemplo, a solução para proteger ambientes virtuais o vGate Security Code captura a adição de novas políticas ao conjunto.



Aqui:
"Admin @ VGATE" - Assunto (nome do usuário que altera o conjunto de políticas)
"Base" - Objeto (conjunto de políticas)
“Instalando e mantendo a integridade do sistema de arquivos”, “Verificando as configurações do agente SNMP”, “Desativando a instalação automática do VMware Tools” - Recursos (nomes de políticas adicionadas)

O modelo do canal de interação entre o Sujeito e o Objeto

Em todos os esquemas, distinguimos diferentes entidades (sujeitos, objetos, recursos, fontes, transmissores) e observamos o chamado canal de interação entre eles. Vamos nos aprofundar mais no penúltimo componente do grande modelo do “mundo” com o qual o SIEM deve operar - nos modelos do canal de interação entre o Sujeito e o Objeto. Lembre-se de que o último componente é o contexto da interação (o próximo artigo será dedicado a isso).

Portanto, existem duas entidades interagindo entre si. Como parte dessa interação, os dados são transferidos de uma entidade para outra. Podem ser pacotes de rede com dados, arquivos ou comandos de gerenciamento. Nesse caso, o canal formado pode ser representado na forma de um "tubo" ao longo do qual existe um fluxo direcionado de dados e comandos. Esse modelo é claramente visível no nível da rede, mas menos pronunciado no nível do aplicativo (veja o exemplo ).


Modelo de canal de dados

Com base nesse modelo, cada evento que o SIEM recebe pode conter informações que descrevem:

• Os parâmetros do canal em si são o "pipe",
• Os dados transmitidos através deste "tubo".

Normalmente, um canal é descrito por parâmetros como identificador de sessão, protocolo de transferência de dados, tempo de estabelecimento do canal, tempo de conclusão, duração. Os dados nos eventos são caracterizados pelo formato usado pelos algoritmos de criptografia, pelo número de pacotes transmitidos, pelo número de bytes transmitidos.

Considere um exemplo de um evento que contém dados sobre o canal de interação. Aqui está um evento do Cisco Identity Services Engine (ISE), um sistema de gerenciamento de processos para identificar e controlar o acesso, que registra a sessão de rede de um usuário como parte do procedimento de contabilidade (contabilidade).




Aqui:
“Acct-Session-Id = 1A346216”, “Acct-Session-Time = 50”, “Service-Type = Framed”, “Framed-Protocol = PPP” - parâmetros do canal de comunicação,
“Acct-Input-Octets = 43525”, “Acct-Output-Octets = 122215”, “Acct-Input-Packets = 234”, “Acct-Output-Packets = 466” - parâmetros dos dados transmitidos pelo canal.

Um exemplo de modelos de interação de entidades e o canal em um evento

Assim, examinamos os esquemas de interação dos níveis e aplicativos da rede, bem como o modelo do canal de interação. A seguir, mostramos um exemplo de como, em um evento, os esquemas de interação de diferentes níveis são combinados e as informações sobre o modelo de canal são usadas.

Aqui vemos um evento do firewall - o Cisco Adaptive Security Appliance (ASA), no qual uma conexão TCP de saída é corrigida.



O exemplo mostra claramente que, em um evento, existem entidades do nível da rede e do nível do aplicativo. No nível da rede, um esquema de interação entre o Assunto e o Objeto, que é fixado pela Fonte. Não há transmissor.

Aqui:
30.0.0.1 - Fonte (Cisco ASA),
10.0.0.1 - Assunto (o endereço de quem se conecta),
20.0.0.1 - Um objeto (o endereço daquele a quem eles se conectam).

No nível da aplicação, um esquema simples no qual apenas o Assunto e o Objeto estão presentes:
"ALEX" - Assunto (nome de usuário que se conecta),
"BOB" - O objeto (o nome do usuário ao qual eles se conectam).

Também neste evento, há uma descrição do canal de dados, mas não há descrição dos próprios dados:
"TCP" é o protocolo com base no qual o canal foi criado,
"136247" é o identificador da sessão do canal.

Conclusões

Como os esquemas típicos de interação destacados por nós podem ajudar?

• Primeiro , ao escrever regras de correlação e analisar eventos, um especialista deve entender quais entidades estão presentes em cada evento que chega ao SIEM. Para isso, é necessário, no estágio de normalização dos eventos, distinguir claramente as entidades: Assunto, Objeto, Recurso, Fonte e Transmissor.
• Em segundo lugar , durante a normalização, é importante levar em consideração que o evento contém informações sobre a interação do nível da rede e do nível do aplicativo. Ambas as interações podem estar presentes simultaneamente em um evento.
• Em terceiro lugar , a interação em si é uma estrutura composta na qual há informações sobre o canal formado e sobre os dados transmitidos por esse canal.

Assim, o modelo do “mundo”, construído no SIEM e representado por um conjunto de campos (um esquema), deve conter seções para descrever:

1. No nível da rede :
   
   • Assunto;
   • O objeto;
   • Fonte;
   • Transmissor
   • Canal de interação;
   • Dados transmitidos pelo canal.
   
   
2. No nível do aplicativo :
   
   • Assunto;
   • Um objeto ou uma pluralidade de objetos;
   • Um recurso ou vários recursos.
   
   

Para cada entidade, é necessário definir um conjunto de propriedades que a identifiquem exclusivamente. No nível da rede, as entidades são identificadas por IP, MAC ou FQDN. No nível do aplicativo, por nome ou ID. O esquema deve ter campos dedicados para armazenar esses identificadores.

Existem esquemas de interação degenerados nos quais uma entidade pode combinar várias funções ao mesmo tempo. Ao normalizar esses eventos, é necessário definir explicitamente a regra para preencher todos os campos do esquema que são responsáveis ​​por todo o conjunto de entidades. No futuro, isso ajudará as regras de correlação a não perder parte das interações.

Vamos explicar: tomemos o caso de combinar o papel do Sujeito e o Objeto na Fonte. , , , , .

, . , .

, , :


,

— «» SIEM , . , , Alex , — , , , . , . , - , , SIEM .

, , . , , .

---

:

SIEM: « ». 1: ?

SIEM: « ». 2. «» ( )

SIEM: « ». 3.1.

SIEM: « ». 3.2.

SIEM: « ». 4.

SIEM: « ». 5.