Hoje falaremos sobre o Security Operations Center (SOC) de pessoas que não o criam e o configuram, mas que verificam como os outros o fizeram. A eficácia do SOC criado para sua empresa independentemente ou por alguém externo é verificada. A verificação responde à pergunta “O SOC cumpre as tarefas que lhe foram atribuídas ou não, e qual a sua eficácia?”. Afinal, a presença do SOC não significa que ele funcione como deveria e você está ciente de quaisquer possíveis incidentes e outros problemas de segurança. Contaremos sobre nossa experiência na verificação do SOC em diferentes empresas de nossos projetos.



Para quem já sabe o que é o SOC e com o que ele está bêbado, sugerimos que vá imediatamente para a segunda parte do artigo. Sugerimos que você leia o restante do artigo na íntegra.

Parte 1. Um pouco sobre o SOC para iniciantes

A proteção dos sistemas de informação vem em primeiro lugar em quase todos os setores. Qualquer acesso não autorizado a informações pode levar a sérios problemas para a empresa.

O sistema de informações de qualquer empresa, mesmo a menor, é complexo e todas as suas partes devem ser protegidas de acordo com o mesmo princípio - primeiro medidas organizacionais, depois preventivas, depois ferramentas de vigilância que detectam anomalias e ferramentas de resposta. As pessoas estão no último, mas não menos importante, estágio de combate às ameaças, embora aconteça que um problema de segurança possa ser resolvido sem envolver as pessoas, por exemplo, bloqueando automaticamente as portas ou desconectando uma máquina de uma rede compartilhada. As ferramentas usadas para proteger cada um dos componentes do sistema podem variar de empresa para empresa, mas há uma tendência geral - gradualmente as empresas, independentemente do seu tamanho, chegam à idéia de introduzir o SOC - Security Operation Center.

Existem várias razões para isso:

• O uso do SOC reduz o custo do rastreamento manual de incidentes de segurança
• eventos do sistema se reúnem em um só lugar, menos provável que algum deles seja perdido;
• O SOC permite configurar regras para classificar eventos como incidentes de segurança de acordo com as necessidades e características de uma empresa específica;
• O SOC permite minimizar o tempo de detecção e resposta a incidentes de segurança, reduzindo assim os possíveis danos à empresa;
• os logs que se enquadram no SOC são apresentados de uma só vez, o que permite investigar efetivamente incidentes de segurança, mesmo que um invasor tente observar os rastros de sua presença no sistema.

O SOC é uma infraestrutura com muitos componentes interconectados, com base no SIEM (Gerenciamento de informações e eventos de segurança). O SIEM é um sistema de coleta, normalização e correlação de dados que coleta logs de servidores Web, máquinas host e outros componentes de infraestrutura, além de ferramentas de segurança da informação instaladas em dispositivos da rede da organização, correlaciona e processa-os para trazê-los de volta ao normal. Essa é a principal tarefa do SIEM - trazer um grande número de logs de diferentes fontes para um único formato para a conveniência de detectar os relacionamentos entre eles. Isso é necessário para outro componente dos analistas do SOC - SOC que, observando as enormes listas de logs do SIEM, precisam responder a alguns dos eventos por conta própria ou transferi-los para o trabalho de especialistas em segurança.

Não há dois SOCs idênticos porque sua configuração é individual para cada organização. Os principais estágios da criação do SOC são os seguintes:

• definir uma infraestrutura protegida, organizacional e tecnicamente;
• instalação de todos os meios possíveis / necessários de proteção e monitoramento, bem como sua configuração;
• seleção de um SIEM adequado e seu ajuste, dependendo das características da empresa;
• criando regras de correlação de eventos;
• seleção da equipe do SOC - pessoas cujo trabalho monitorará eventos e fará correções nas regras de correlação, além de responder a eventos de segurança.

Mesmo depois de tudo ter sido definido, instalado e configurado, ninguém pode garantir que agora o SOC funcione como você gostaria ou como mostrado nas belas apresentações dos desenvolvedores do SIEM. O problema fundamental do uso de qualquer meio de proteção é que praticamente ninguém sabe com que eficácia eles funcionam. É importante não apenas instalá-los e executá-los, mas também garantir que as medidas tomadas sejam eficazes. O nível de maturidade da empresa em questões de segurança também é extremamente importante.

Como o SOC é uma estrutura complexa e com vários componentes, é importante entender que, em cada um dos estágios listados de sua criação, algo pode dar errado. E isso provavelmente afetará a segurança geral do sistema e a eficiência do próprio SOC.

Parte 2. O que acontece se você não verificar a eficácia do SOC, mas deixar tudo como está?

Para começar, algo pode dar errado, mesmo com a menor mudança na infraestrutura da organização. E acontecem com bastante frequência - alguém sai, novas pessoas chegam, algo quebra, o hardware e o software são atualizados e muito mais. Nesse caso, as configurações do SPI e as regras de correlação devem ser prontamente alteradas, mas geralmente esquecem disso e, quando lembram, é tarde demais.



A próxima parte do SOC em que os erros podem ocorrer é o meio de proteção a partir do qual as informações entram no SIEM, podem ser configuradas incorretamente e pular as ações direcionadas ao sistema de fora. E se a ação do invasor não for detectada por nenhum SZI existente, ele não entrará nos logs e não estará no SIEM, e provavelmente o serviço de segurança não saberá sobre isso em breve.



O problema pode estar no SIEM . Pode não funcionar como você gostaria. Eventos que caem nele podem ser correlacionados incorretamente devido a erros nas regras de correlação, o que levará ao pulo das ações do atacante. Vale a pena esclarecer aqui que nem sempre há dados suficientes de uma fonte. Há casos em que, para determinar incidentes de segurança, é necessário combinar dados de várias fontes ao mesmo tempo para obter uma imagem completa do que está acontecendo no sistema. Mas pode ser que a regra esteja configurada para determinar o que aconteceu, o incidente pode não ser dados suficientes de uma fonte, o que indica o fato de sua conclusão. I.e. um quebra-cabeça composto de dados de várias fontes não funcionará. Além disso, as regras para alguns eventos de segurança podem não existir.

No estágio de correlação de eventos no SIEM, vários problemas podem surgir ao mesmo tempo. Um deles pode ser um atraso na transmissão de eventos de algumas fontes, o que pode interferir na correlação bem-sucedida.

As regras para classificar eventos como incidentes no SIEM podem não ser configuradas corretamente por conta própria ou podem não estar disponíveis para nenhum evento. Além disso, os incidentes geralmente têm um nível de gravidade que, se não for corretamente identificado, pode levar a grandes problemas.



As pessoas que trabalham com o SIEM, cuja função é responder a incidentes de segurança, também podem causar ataques perdidos e problemas subseqüentes de segurança da informação. Eles podem perder alguns sinais do SIEM ou reagir incorretamente às ações do atacante por vários motivos. Também existe o problema de as pessoas desistirem mais cedo ou mais tarde, e os novos funcionários precisam de tempo para treinar.

Diante do exposto, o teste do SOC para verificar o desempenho é extremamente importante, tanto no estágio de implementação do SOC quanto no decorrer do tempo. Como os especialistas de nossa empresa já possuem experiência nesse assunto, decidimos descrever os principais pontos e nuances.

Parte 3. Verificando a eficácia do SOC

O teste de SOC em uma empresa pode ser realizado em vários cenários. Vamos falar sobre aqueles que nos parecem mais eficazes.

As tarefas de teste do SOC incluem testes de segurança, reproduzindo cenários de comportamento típicos inerentes aos criminosos cibernéticos. Estes incluem:

• iterando pelas contas de outros usuários usando força bruta, bem como usando a técnica de pulverização de senha. É possível usar esta técnica se você tiver acesso à lista de contas existentes no sistema, por exemplo, através do catálogo de endereços do cliente de email. Em nossa experiência, as técnicas de pulverização de senha são frequentemente esquecidas e, portanto, as regras do SOC dificilmente podem detectar um ataque assim;
• bombeando dados de um recurso da Web, seja um wiki corporativo ou um gerenciador de tarefas. Esse ataque pode ser realizado incluindo o uso de vários mecanismos de rastreamento na Web e de diretório bruto. Separadamente, os auditores prestam atenção aos serviços de API e seus recursos;
• tentativas repetidas de acessar recursos ou projetos que estão fora da competência da função em nome da qual o atacante trabalha. Um exemplo simples é a tentativa de autorizar um usuário de um grupo de desenvolvedores sobre os recursos dos administradores de rede e serviços de segurança;
• Tentativas de baixar uma grande quantidade de informações da rede corporativa usando técnicas de filtragem de desvio. Isso se refere principalmente aos túneis DNS e ICMP, mas às vezes faz sentido começar com verificações mais simples, por exemplo, tente procurar uma porta TCP ou UDP aberta fora, além de um gateway adicional. Para procurar gateways, a propósito, há uma implementação revisada de uma ferramenta popular de um dos funcionários.

Uma lista semelhante de verificações pode ser continuada por um longo tempo. É muito importante ser guiado pelas reais necessidades do cliente e pelas verificações implementadas por ele.

O teste SOC pode ser realizado de duas maneiras:

• cegamente - caixa preta;
• com conhecimento de infraestrutura - whitebox.

Mais detalhes sobre cada um deles.

Primeiro de tudo, você deve verificar a operação do SOC no modo de teste de caixa preta. Sua essência é que os funcionários do departamento SOC não estão cientes do trabalho que está sendo realizado e reagem a todos os eventos no modo de combate. Os auditores / promotores de acesso têm acesso à rede corporativa e as contas também podem ser fornecidas pelos serviços mais usados ​​na empresa.

Esse modelo pressupõe que um invasor que não possui nenhuma informação adicional tenha acesso à rede da empresa e a nenhuma das contas existentes de maneira desconhecida. As ações de um invasor são caracterizadas por um alto grau de aleatoriedade e "ruído". Ele verifica ativamente a rede, itera diretórios, contas, envia todas as explorações que conhece a todas as portas, lança aplicativos da Web XSS, SQLi, RCE, SSTI, NoSQLi, etc. com vetores. Em geral, ele se comporta de forma extremamente agressiva na esperança de invadir pelo menos alguma coisa. Durante a auditoria, os auditores imitam as ações de um invasor, mantendo um certo grau de insanidade, mas estão prontos para parar a qualquer momento, a pedido do serviço SOC ou se surgirem problemas técnicos. A propósito, um resultado inesperado e agradável pode ser a descoberta de aplicativos e serviços vulneráveis ​​na infraestrutura da empresa.

Outro modelo de teste é o whitebox. Nesse caso, o cenário de um funcionário sem escrúpulos é elaborado. Normalmente, nesse ponto, os auditores são bem versados ​​na rede do cliente e podem desempenhar esse papel. O comportamento de um invasor em potencial nesse caso pode ser caracterizado pela alta seletividade dos meios e dos alvos do ataque. Aqui já é possível traçar alguns paralelos com ataques do APT . Os auditores atacam apenas os lugares mais fracos em sua opinião e usam vetores de ataque bem pensados ​​e direcionados de maneira restrita e também tentam acessar informações confidenciais fora da competência de sua função de conta com a tentativa subsequente de extraí-las do perímetro seguro. Eles tentam executar todas as ações de forma a passar despercebidos pelo serviço de segurança da empresa.

Após o teste, geralmente começa a análise e comparação dos resultados obtidos pelos auditores e os incidentes detectados pelos funcionários do SOC. Esta etapa fornecerá uma imagem geral da eficácia do trabalho atual do SOC e pode servir como ponto de partida para todos os planos adicionais para expandir as verificações e abordagens existentes.

Finalmente, quando uma idéia da segurança da infraestrutura testada é compilada, os auditores podem usar o teste da caixa branca para analisar o conjunto de regras existente, bem como os eventos com base nos quais essas regras são formadas. Essa interação entre auditores e analistas do SOC pode ser muito produtiva e, durante a consulta, ajudará a identificar erros e omissões lógicos na configuração dos componentes do SOC. A raiz deles geralmente é a falta de entendimento dos analistas do SOC sobre como um invasor real pode agir e quais truques ele pode executar nos sistemas.

Conclusão

Os serviços mais críticos que merecem mais atenção são testados separadamente, usando dois modelos de intrusos.

Um conjunto semelhante de medidas permite:

• aumentar significativamente a conscientização dos gerentes de segurança sobre o estado de sua infraestrutura;
• realizar exercícios militares para o departamento do SOC com a oportunidade de obter conselhos de especialistas na área de auditoria;
• detectar e corrigir erros existentes no trabalho do SOC, bem como geralmente aumentar a segurança da empresa.

Pela ajuda na redação deste artigo, agradeço a Denis _ttffdd_ Rybin e Ivan Chalykin .