Get best of the week

Segurança automatizada da plataforma de resposta a incidentes

Imagine um centro de situação típico para segurança da informação em uma grande empresa. Em um mundo ideal, o software detecta atividades suspeitas e a equipe de "hackers brancos" começa a bater as mãos no teclado. E isso acontece uma vez por mês.

No mundo real, são centenas de falsos positivos e equipe de suporte cansada. Eles são forçados a lidar com cada incidente quando o usuário esqueceu a senha, não pode baixar o jogo de um torrent, outro filme pornô no formato * .exe, assistir a falhas de rede e geralmente investigar muitas situações.

Os sistemas SIEM ajudam a organizar e correlacionar eventos de fontes. E eles geram pontos positivos, cada um dos quais precisa ser tratado. Destes "todos", a maioria é falsa. Por outro lado, você pode abordar o problema, tendo scripts para processamento de alarmes. Cada vez que algo funciona, seria bom não ter apenas a causa do alarme e, em seguida, subir em quatro a cinco sistemas para dados diferentes e coletar automaticamente automaticamente todo o diagnóstico.



Criamos esse complemento e ajudou muito a reduzir a carga nos operadores. Como os scripts para coletar informações são iniciados imediatamente e, se houver ações típicas, eles são executados imediatamente. Ou seja, se você iniciar o sistema "em tal situação, fazemos isso e aquilo", o cartão será aberto para o operador com a situação já resolvida.

O que há de errado com os sistemas SIEM?


A lista de compensações está sobrecarregada com dados brutos. Um cartão de incidente específico para preenchimento é transferido para nossa plataforma.

Casos típicos têm fluxogramas de reação de amostra.

Aqui, por exemplo, relatórios de análise de dados sobre erros de autenticação do usuário:



Existem critérios para falsos positivos: por exemplo, tentei duas vezes - entrei na terceira. O usuário apenas recebe uma carta dizendo que a senha deve ser digitada com cuidado, o ticket é fechado. Se ele tentou cinco ou seis vezes, informações detalhadas já estão começando a se reunir: o que aconteceu a seguir, o que aconteceu antes e assim por diante. Se ele se conectou pela décima vez e depois foi para a base de conhecimento e começou a baixar 10 arquivos, pode haver uma configuração para "bloquear o acesso à base de conhecimento até o final do processo e notificar o operador". Provavelmente, se o usuário não for malicioso, nesse caso, o departamento de TI receberá automaticamente um email com os detalhes. Talvez eles ensinem o usuário a digitar a senha corretamente ou ajudem a alterá-la.

Se a atividade for mais perigosa, o nível "abriu o arquivo executável pelo correio e, em seguida, algo começou a aparecer na Web", um segmento ou sub-rede inteira pode ser bloqueado automaticamente. Sim, o SIEM pode fazer isso por conta própria, mas sem o ajuste fino, talvez, essas medidas sejam o limite da automação.

Novamente, em um mundo ideal, o operador tem acesso a todos os sistemas e imediatamente sabe o que fazer. No mundo real, ele muitas vezes precisa encontrar alguém responsável para esclarecer alguma coisa. E ele também está de férias ou em uma reunião. Portanto, outra parte importante - no fluxograma da reação deve ser imediatamente responsável por seções específicas de sistemas e departamentos. Ou seja, você não precisa procurar o telefone celular do funcionário, o nome do chefe e o telefone dele, mas vê-los imediatamente em um cartão aberto.

O que nos fizemos


  1. , (), - .
  2. , ( ), , .
  3. , -. : , , .
  4. , .
  5. .
  6. ( , , ).
  7. .
  8. GUI -.

Um de nossos principais clientes é o SIEM QRadar. Um bom sistema de detecção de ameaças, existem ações e etapas para cada incidente, mas você não pode fornecer uma lista de trabalhos para um operador humano. Quando se trata de uma superclasse profissional, isso não é necessário. Quando se trata do operador da primeira linha, é muito importante fornecer instruções sobre o que e como fazer, e ele poderá cobrir a maioria dos incidentes típicos no nível de um especialista legal.

Ou seja, retiramos todos os eventos obviamente chatos na primeira linha e adicionamos critérios aos scripts que separam os chatos dos chatos. Tudo atípico, como antes, recai sobre os profissionais.

Casos para empresas com dezenas de milhares de empregos e com capacidade de servidor em vários datacenters foram elaborados e prescritos como resultado por cerca de um ano (existem relações difíceis entre departamentos, o que dificultou a integração em diferentes sistemas). Mas agora qualquer subtarefa do cartão tem uma pessoa específica no comando, e é sempre relevante.

A simplicidade dos operadores pode ser julgada pelo fato de que, durante a implementação, o sistema foi implementado primeiro em regiões e, depois de algumas semanas, a documentação oficial começou a ser enviada. Portanto, durante esse período, as pessoas já começaram a fechar incidentes com confiança.

Como isso começou?


Existe o SIEM, mas não está claro o que está acontecendo constantemente. Mais precisamente, o QRadar gera muitos eventos, eles se enquadram no departamento de segurança da informação e simplesmente não há mãos para desmontar tudo corretamente e em detalhes. Como resultado, os relatórios são simplesmente visualizados superficialmente. O benefício do SIEM com essa abordagem não é muito alto.

Existe um sistema de gerenciamento de ativos.

Existem servidores para escanear a rede, muito bem configurados.

O relatório seria excelente, mas eles o olharam cansados ​​e se afastaram.

O cliente queria o que comprou para começar a produzir resultados.

Colocamos a central de atendimento para guardas de segurança no topo (na verdade, um sistema de ticket, como no suporte normal), visualizamos a análise de dados e escrevemos a plataforma de automação descrita com base nas reações típicas adicionadas ao IBM Resilient +. Resiliente fica nu, é apenas uma estrutura. Tomamos as regras de correlação do QRadar como base e finalizamos os planos de resposta para casos de usuários.



Durante vários meses, eles fizeram a russificação de tudo e desligaram os pacotes corretos pela API. Assim que terminamos, o fornecedor emitiu a russificação e ficamos um pouco tristes.

Cerca de um mês, eles treinaram e familiarizaram-se com a documentação (em particular, como desenhar novos fluxogramas para cartões). Quanto mais eles aprendiam, mais casos simples se tornavam: a princípio, grandes scripts de ações foram escritos e, em seguida, eles se tornaram uma espécie de biblioteca de casos típicos. E pode-se referir a eles em quase qualquer reação.

Comparação da reação


Incidente "Infecção repetida por vírus com o mesmo malware em um curto período de tempo." Ou seja, o vírus é detectado nas estações de trabalho, mas é necessário pessoal para entender de onde vem. A fonte da infecção está ativa.

Clássico:

  1. Houve uma infecção repetida por vírus do host 192.168.10.5 com o mesmo malware por um curto período de tempo, os eventos foram enviados ao SIEM e a regra correspondente funcionou.
  2. .
  3. .
  4. .
  5. .
  6. /CMDB-.
  7. .
  8. - , .
  9. / .
  10. Service Desk .
  11. Preenche um aplicativo no sistema do Service Desk com base nos resultados de uma investigação para eliminar a vulnerabilidade devido à qual este host foi infectado.
  12. Ele espera que os aplicativos do Service Desk sejam fechados e depois verifica sua execução.
  13. Preenche um cartão de incidente e fecha o incidente.
  14. Relata à gerência os resultados de seu trabalho.
  15. O analista coleta estatísticas de incidentes para analisar a eficácia do processo de resposta.

Na nossa plataforma:

  1. Houve uma infecção repetida por vírus do host 192.168.10.5 com o mesmo malware em um curto período de tempo, os eventos foram enviados ao SIEM e a regra correspondente funcionou.
  2. O operador examina a placa de incidente, que já baixou informações sobre esse host, o status da ferramenta de proteção antivírus e seus logs, vulnerabilidades no host, incidentes relacionados e as pessoas responsáveis ​​por esse host.
  3. , : , , Service Desk , - .
  4. Service Desk , .
  5. .
  6. .




Tornou-se um pouco mais rápido. Mas o principal não é isso, mas é possível classificar as tarefas em "o operador de primeira linha lidará" e "necessidades especiais". Ou seja, em média, a solução para cada ticket se tornou significativamente mais barata e o sistema é mais escalável.



Além de muitos falsos positivos, havia muitas duplicatas que eram convenientes para serem detectadas pelo sistema.



Os cartões não parecem um conjunto de dados obscuros de um relatório, mas como “Vasya fez isso e aquilo em um host. Isto é mau. O anfitrião é responsável por Petya. Foi exatamente o que aconteceu. Precisamos ir a Petya e dizer que o computador de Vasya da área de trabalho não pode ser usado para mostrar apresentações em conferências. ”

Outra coisa importante é que, com base na coleta de dados primários, tornou-se possível priorizar tickets. Ou seja, as principais ameaças em potencial surgem e requerem atenção imediatamente, e não em uma fila ao vivo.

A automação na interface com os tickets de TI tornou possível não apenas coletar todas as informações sobre o incidente, mas também colocar os tickets imediatamente no departamento de TI. Se você precisar alterar algumas configurações no roteador, agora um ticket da TI é gerado automaticamente, por exemplo. Surpreendentemente, os casos começaram a surgir "esqueceram de alterar a conta no serviço e ele está tentando se conectar por um mês". A TI não vê essas situações ou ignora a infraestrutura. E aqui diz o IS - o serviço não pode efetuar login. E eles colocaram uma multa.

Graças à digitação dos cartões de reação, os incidentes começaram a ser resolvidos por métodos padrão. Anteriormente, cada um era decidido de forma criativa: pessoas diferentes realizavam ações diferentes.

O resultado é um fluxo de trabalho tão bom como no CRM moderno. O incidente passa por um funil. Outro problema foi resolvido na última etapa: às vezes as pessoas fechavam a passagem simplesmente porque estava cansada. Ou seja, o resultado foi mal prescrito. E agora você precisa provar ao sistema que este é um falso positivo. Ou seja, você pode fechá-lo, como antes, mas é claro que, quem e sob quais condições o fez, e é muito mais fácil abrir as ombreiras. Não apenas “o usuário não conseguiu executar o arquivo”, mas “trouxe o jogo para a unidade flash USB, queria instalá-lo - eles explicaram as regras da vida mais uma vez”. E já está claro o que aconteceu.

Versatilidade


Agora, existem algumas integrações na produção (uma é muito grande com o QRadar e um sistema de gerenciamento de ativos, outra é menor). É possível vincular-se a qualquer SIEM usando APIs padrão, mas, é claro, a integração requer tempo para conectores, refinamento de arquivos e anotação de regras de reação para as pessoas. No entanto, ajuda muito a realmente responder a incidentes de segurança e fazê-lo de forma relativamente rápida e barata. É provável que em 10 anos os próprios sistemas SIEM sejam capazes de fazer isso, mas até agora nosso complemento mostrou-se bem.

Se você quiser sentir isso conosco ou discutir como isso pode parecer com você, aqui está meu e-mail AAMatveev@technoserv.com.

More articles:


All Articles