Como implementamos o segundo SIEM no centro de monitoramento e resposta a ataques cibernéticos

Uma cabeça é boa e duas não são bonitas ... Então pensamos em uma época maravilhosa, quando havia apenas uma plataforma SIEM em nosso centro para monitorar e responder a ataques cibernéticos. Não é segredo que se tratava do HP ArcSight, que acabou por ser o único finalizador de uma longa maratona através de espinhos de demandas, desejos e planos ambiciosos para construir o coração do SOC.



E nada parecia ser um bom presságio, mas em algum momento, pensamentos sobre a necessidade de trabalhar com uma plataforma alternativa apareceram e se tornaram cada vez mais persistentes. E a locomotiva principal aqui foi o desenvolvimento ativo dos centros GosSOPKA. Para nos tornarmos um desses centros, tivemos que usar o software que é fornecido"Garantia e suporte técnico de organizações russas que não estão sob o controle direto ou indireto de pessoas físicas e (ou) pessoas jurídicas estrangeiras" (Despacho do FSB de 06.05.2019 No. 196, cláusula 3.4). Como sofremos tudo isso passou e o que aconteceu no final, contaremos a seguir.





Quadro da série animada "Catdog"



Ouvimos dizer que existem SOCs que professam poligamia, multi-fornecedores e dizem (e esse tipo de atividade, como lembramos, é muito diferente de operações de descarga de sacola) que estão prontos para trabalhar com qualquer solução SIEM amplamente difundida no mercado. Por que é impossível implementar tal abordagem qualitativamente, você entenderá na descrição abaixo. Ficamos tão apegados ao ArcSight e conseguimos construir todo um ecossistema de soluções e processos em torno dele que incorporar um SIEM alienígena nele se tornou um verdadeiro desafio e impôs uma série de questões difíceis para nós:

1. Qual solução escolher?
2. Como integrar o novo sistema SIEM na operação TIER1?
3. Como todas as muitas integrações internas que o ArcSight possui atualmente podem ser transferidas para a nova plataforma?
4. Como sincronizar a ideologia de desenvolvimento de conteúdo SIEM e fornecer conjuntos simétricos de regras de detecção?

Escolher uma solução não foi tarefa fácil. Em todos os lugares tivemos que mergulhar em um redemoinho, cuja profundidade não tínhamos nada para estimar. Como resultado, decidimos fazer uma escolha de uma forma diferente - usar SIEM do fornecedor, que nos prometeu uma alta prioridade de melhorias de acordo com nossas necessidades e em cujas promessas acreditamos. Assim, nasceu uma parceria tecnológica com a Positive Technologies e o MaxPatrol SIEM apareceu no funil dos nossos SIEMs.

Ok, temos uma nova plataforma. Mas quem vai trabalhar com ela?

Para ser honesto, a princípio tivemos a sensação de que não poderíamos passar sem uma segunda equipe trabalhando em paralelo com o novo kit de ferramentas. Esse sentimento foi reforçado pelo fato de que mesmo as linhas dos analistas seniores que participaram do teste do segundo SIEM acharam difícil de aceitar. Portanto, a princípio, o conceito foi traçado da seguinte forma: duas linhas TIER1, cada uma afiada com seu próprio instrumento, e a multi-plataforma TIER2. Com o fator de prontidão multiplataforma como fator de crescimento para um especialista de T1 a T2.



Foi nessa época que acumulamos motivos suficientes para dividir nossa 1ª faixa em TIER1 e TIER2 (mais sobre isso em outra série de artigos). E como no conceito inicial o T2 deveria funcionar com ambas as plataformas, passamos todos os incidentes do MP SIEM para a 2ª faixa, formada a partir dos mais experientes 1ª lutadores que estavam imersos no novo SIEM. Olhando para o futuro, direi que os engenheiros da 2ª linha perceberam o MP SIEM de forma mais positiva do que seus colegas analistas seniores - isso nos deu esperança de que a plataforma pudesse ser totalmente aterrada na 1ª linha, e não cercar várias especializadas.



A questão da integração em um único ecossistema também não foi tão dolorosa quanto esperávamos - talvez tenha sido ajudada pelo fato de que flexibilidade e redundância de configuração foram inicialmente incluídas nos mecanismos de integração desenvolvidos. Não houve vitórias particularmente grandes das quais eu gostaria de me gabar. Rapidamente incorporamos o novo sistema ao ecossistema e aos processos de investigação, e agora o processamento de incidentes de vários SIEMs difere para os caras apenas na interface do próprio SIEM. Todos os mecanismos de roteamento e priorização, todas as informações enriquecedoras de tomada de decisão, todos os modelos de notificação são idênticos e estão nos mesmos lugares familiares.

E quanto ao conteúdo?

Você não pode ir longe em um SIEM "vazio" sem conteúdo (regras para correlacionar eventos de segurança da informação e identificar incidentes) e não encontrará muitas ameaças (não usamos conteúdo em caixa), então surgiu a tarefa de desenvolver prontamente regras de correlação em uma nova plataforma para cenários JSOC existentes. No início, decidimos sobreviver com um pouco de sangue e transferir as regras do ArcSight com a cópia da lógica de implementação, mas isso acabou sendo um erro, no qual nos queimamos seriamente: uma arquitetura de produto completamente diferente exigia uma abordagem "sua" para o desenvolvimento. Tive que formar essa abordagem, e em um ritmo acelerado. A interação próxima com o fornecedor ajudou muito, que aconselhou sobre questões emergentes, levou em consideração a implementação de nossas solicitações para refinar os existentes e criar novos chips na funcionalidade.O outro lado da moeda é que regularmente tínhamos que reescrever o conteúdo para que funcionasse corretamente nesta nova funcionalidade. Mas, como se costuma dizer, mude ou morra, por isso não reclamamos (bem, exceto talvez dentro da equipe com um copo de chá).



No estágio inicial, apenas analistas experientes de 4ª linha, que comiam o cachorro enquanto trabalhavam com a ArcSight, estavam engajados no desenvolvimento de conteúdo para o novo SIEM. Curiosamente, alguns caras já haviam passado por uma deformação profissional nessa época e formaram uma "dependência" de um SIEM específico com seu alto nível de maturidade. Mudar para uma nova plataforma foi difícil para eles psicológica e tecnicamente. Mais tarde, a equipe de desenvolvimento foi significativamente expandida com novos membros, incl. caras da 3ª linha, e só para eles esse tópico decolou muito mais fácil e muitas vezes ainda mais produtivo.



Apesar da lista cruzada de cenários para ambos os SIEMs, sua implementação pode diferir significativamente, principalmente devido às limitações na arquitetura e funcionalidade de plataformas diferentes. Por exemplo, no ArcSight, na regra de correlação, você não pode especificar uma verificação da existência de um registro na planilha ativa por uma correspondência solta, e no MP SIEM, você pode. Por outro lado, o MP SIEM não gera eventos internos para adicionar ou remover um registro da lista da tabela, e o ArcSight pode fazer isso, e em vários cenários este recurso é usado. Eu tive que viver com uma personalidade dividida para introduzir "linha dupla" em nossa base de conhecimento sobre scripts JSOC e descrever as nuances da implementação, bem como suas próprias ferramentas de investigação para cada uma das plataformas.



Ao mesmo tempo, foi muito importante transmitir à 1ª linha que a lógica da investigação de incidentes não depende do SIEM em que são gerados, e que o novo SIEM é uma nova ferramenta para resolver todas as tarefas iguais. Possui características próprias que devem ser estudadas, mas nada muda radicalmente.

E o trabalho na 1ª linha começou a ferver

A imersão da TIER1 no trabalho com a MP SIEM foi gradativa e de acordo com o processo, depurada com a introdução de novos funcionários. Foram determinados os critérios de incidentes, que não são muito assustadores de dar na análise da 1ª linha, que ainda não tem muita experiência com o MP SIEM:

• poucos detalhes de incidentes críticos (hosts / redes e contas não categorizados);
• longos tempos de SLA;
• baixa intensidade de trabalho do incidente (acumulamos estatísticas durante o processamento de incidentes no TIER2);
• regras de correlação não muito furiosas (sim, você precisa olhar lá para a primeira linha).

Os cenários de acordo com estes critérios foram divididos em várias etapas e foram entregues aos engenheiros do TIER1 um a um - após passar os “créditos” e obter acesso à solução do pool de incidentes.



Como resultado, temos em nosso portfólio de ferramentas dois SIEMs, nos quais cenários absolutamente idênticos em essência e lógica de processamento são iniciados.



Alexey Krivonogov, Diretor Adjunto da Solar JSOC para Desenvolvimento de Rede Regional