Habilidades de natação sincronizada ou alinhamento de tarefas de monitoramento e resposta
Como você sabe, o animal mais rápido do mundo deve ser uma centopéia: é ela que tem mais pernas. Mas o pobre animal é realmente prejudicado pela necessidade de sincronizar seus passos e atividades. Uma história semelhante freqüentemente assombra a vida do SOC (Security Operation Center). Os analistas desenvolvem cenários, franzem as sobrancelhas, inventam novas maneiras de detectar ataques, e a equipe de resposta geralmente não entende o que fazer com esses incidentes (e a distância aumenta se um SOC comercial externo estiver na primeira linha de barricadas). Esse estado de coisas geralmente leva a duas situações extremas:
- SLA « , », , SOC, . , , - .
- – «» . , , . , , . - - , SOC , . , , .
Lembre-se do sábio Yin Fu Wo, que perguntou a seu aluno que estava comprando um scanner de segurança, o que ele faria com as vulnerabilidades encontradas? Seguindo o exemplo dele, realmente quero fazer uma pergunta à equipe de resposta: o que exatamente e, o mais importante, com que rapidez você fará com os incidentes encontrados?
Os recursos do processo de resposta permitem "alinhar" a lista de incidentes com base em sua criticidade interna. Por exemplo, as comunicações sobre mudanças críticas em processos ou ataques na web podem ser alteradas logicamente para o modo de uma chamada telefônica com a coleta imediata de uma equipe de investigação. Para lidar com o lançamento do TeamViewer em máquinas de filiais não críticas, a análise por algumas horas é uma opção adequada. E é bastante aceitável enviar um relatório sobre as estatísticas de infecções virais uma vez por dia - para o café da manhã e o fechamento do "tapete" de problemas, quando apenas a cura massiva de vírus, remoção de software proibido, atualização do sistema operacional, fechamento de vulnerabilidades, etc. está ocorrendo. Isso ajudará a nivelar substancialmente o ritmo do trabalho de monitoramento e resposta e a criar regras de jogo contínuas e confortáveis em todo o processo de gerenciamento de incidentes.
Dica 1. Defina suas prioridades. Como você definitivamente não conseguirá lidar com tudo de uma vez, determine quais tipos de incidentes são realmente críticos para os negócios de sua empresa e estabeleça o prazo necessário para sua resolução.
Analytics, analytics, ainda mais analítica de incidentes
Muitos SOCs comerciais, bem como equipes de script, muitas vezes e seriamente falam sobre a incrível porcentagem de filtragem de falsos positivos, devido à qual os clientes são supostamente notificados não de suspeitas de incidentes, mas apenas de ataques (como eles dizem, “Em tudo que eu quero chegar a própria essência ").
Periodicamente, isso gera processos incríveis para analisar e investigar incidentes, por exemplo, o seguinte:
- Com base na análise do tráfego de rede, o SOC registrou o lançamento de Remote Admin Tools (RAT) no host.
- , . – , RAT ( ) , .
- « ». SIEM .
Vamos deixar de lado o fato de que, no caso de um ataque de hacker, conectar a máquina após o fato no nível de log não é, para dizer o mínimo, uma ação muito deliberada. Um invasor poderia simplesmente ter apagado todos os logs necessários e conectar-se a uma máquina recentemente comprometida em uma conta com privilégios consideráveis pode levar a consequências muito mais sérias do que seu próprio comprometimento (especialmente para aqueles clientes destemidos que, cansados de entender as caixas de seleção para fornecer direitos, forneça a conta para direitos de administrador de domínio SIEM).
O principal é que, do ponto de vista do resultado, todo esse complexo processo de verificação pelo SOC e pelo serviço de segurança equivale simplesmente a pegar o telefone e ligar para um determinado usuário perguntando se ele iniciou a sessão RAT e por que motivo. Como resultado, a resposta em si pode ser recebida muitas vezes mais rápido e o tempo total gasto na investigação do incidente será reduzido significativamente. Dado que a execução do RAT em uma máquina local 98% do tempo é feita pelo usuário (o que apenas torna os 2% restantes mais significativos), essa abordagem de resposta é muito mais eficiente.
2. , . , , « », , , .
, –
É impossível não tocar em um tópico aqui que é frequentemente abordado no desenvolvimento de processos de monitoramento e resposta - a questão do estoque e contabilidade de ativos. Na maioria das vezes, eles falam sobre ativos na chave da informação enriquecedora: para entender a importância de um incidente, é importante saber que tipo de nó de rede é, quem é seu proprietário, que software está instalado nele. Mas em termos de desenvolvimento de manuais, essa tarefa assume um significado adicional: o processo de resposta a um incidente dependerá diretamente de que tipo de nó é e em que parte da rede está localizado.
Considere um incidente bastante básico - infecção por vírus de host. Tem peso e criticidade completamente diferentes, dependendo de onde este host está localizado:
- – , ;
- VIP-, , – ;
- .
Os processos de resposta em empresas industriais requerem ainda mais atenção. O mesmo incidente com o lançamento de RAT em uma máquina adquire acentos e criticidade completamente diferentes se tal utilitário for iniciado onde logicamente não pode ser - por exemplo, na estação de trabalho de um operador de processo. Nesse caso, a medida de resposta padrão é desligar e isolar o host, seguido por descobrir os motivos para iniciar o utilitário e uma possível análise detalhada do host em busca de sinais de comprometimento potencial por um invasor externo.
Dica 3. Faça um inventário dos ativos. "Sobrepor" diferentes classes de incidentes em segmentos de rede. Assim, você não terá mais um modelo linear, onde o nível de criticidade de um incidente é determinado unicamente pelo seu tipo, mas uma matriz básica customizada para sua organização, que pode ser aprimorada e refinada ao longo do tempo.
Resposta real vs. resposta perfeita
A situação descrita acima destaca a questão-chave: até que ponto a equipe interna está pronta para responder para garantir a eliminação das consequências e causas do incidente? Vamos voltar ao exemplo de infecção de uma máquina de malware - o processo de resposta pode ser assim:
- Análise do canal de penetração do malware (mail / web / flash drive)
- Obter informações sobre o próprio malware - qual família, consequências potenciais, a presença de utilitários relacionados
- Identificar indicadores de comprometimento típico de um determinado malware, procurar indicadores em máquinas vizinhas (isso é especialmente importante quando não há cobertura total de estações de trabalho e servidores com proteção antivírus e o malware pode penetrar com sucesso em um dos hosts descobertos)
- Pesquise todos os utilitários relacionados na infraestrutura e remediação
Mas se essa abordagem for aplicada para cada um dos corpos virais na infraestrutura e para cada infecção, isso resultará em custos de mão de obra muito altos. Portanto, uma abordagem equilibrada para a resposta é necessária aqui, dependendo de vários parâmetros externos:
- O já mencionado modelo de ativos e sua criticidade
- O comportamento da família maliciosa - worms, especialmente aqueles que carregam uma carga potencialmente destrutiva, requerem mais atenção
- "Velhice" do vírus e sua consciência dos laboratórios antivírus
- Pertence ao conjunto de ferramentas de agrupamento relevante para a empresa ou indústria
Dependendo de todos esses parâmetros, uma decisão pode ser tomada - desde a remoção básica de malware de um carro comum ou a recarga de um host crítico até um procedimento de resposta mais complexo envolvendo especialistas especializados.
Conselho 4. Não seja preguiçoso para "afiar o machado". As condições adicionais permitem que você esclareça a prioridade e o algoritmo de ação no curso da resposta ao incidente. Eles permitem não só realizar de forma mais completa todo o trabalho necessário para localizar o incidente e conter o ataque, mas também evitar movimentos desnecessários em casos mais simples.
Diga-me quem é seu amigo e eu direi como ser
Bem, a profundidade de conhecimento por parte da equipe de resposta é certamente importante no desenvolvimento de manuais. No início do nosso trabalho como SOC comercial, toda a nossa comunicação era construída através de uma pessoa dedicada ao serviço de segurança da informação do cliente. Nesse caso, falamos de um funcionário, mesmo um jovem estudante, com formação especializada, que, respondendo a incidentes diversos de vez em quando, acumula conhecimentos próprios e faz seu trabalho com cada vez mais eficiência.
Podemos dividir condicionalmente os manuais em dois tipos - técnicos e comerciais. O primeiro descreve o fluxo do processo ao lidar com um incidente e é criado para uma equipe de resposta de um cliente confiável. E o segundo é uma descrição da cadeia de departamentos envolvidos no incidente, e seu consumidor é antes a gestão de linha. Assim, é muito importante “conhecer o seu público”, caso contrário haverá “dificuldades de tradução” associadas à compreensão e interpretação.
Recentemente, os clientes têm incluído cada vez mais departamentos de TI, unidades de negócios, tecnólogos ou até mesmo helpdesk diretamente no processo de resposta. E isso geralmente leva a incidentes. No início da pandemia, vários clientes foram inesperadamente forçados (como todo o país) a transferir massivamente seus usuários para acesso remoto. Uma vez que não foi possível implementar rapidamente o segundo fator de autenticação, o seguinte foi acordado como um esquema temporário: cada conexão remota privilegiada foi verificada pelo helpdesk por meio de uma chamada telefônica. Na ausência de feedback, a questão era encaminhada ao proprietário da empresa do sistema, que poderia decidir continuar o trabalho ou bloquear a conta até que as circunstâncias fossem esclarecidas - em caso de suspeita de atividade inconsistente.No manual do helpdesk, detalhamos os procedimentos para fazer ligações e buscar contatos do proprietário da empresa, tanto quanto possível. Mas eles não escreveram o que o funcionário do helpdesk deveria fazer quando recebesse um comando para bloquear a conta (e o serviço tinha esses direitos). E o primeiro teste executado do incidente mostrou que, ao receber uma carta com a mensagem "ilegítimo, bloqueando", o especialista do helpdesk simplesmente fechou o aplicativo sem realizar nenhum bloqueio.
Dica 5. Mantenha a simplicidade. É extremamente importante levar em consideração as especificidades das qualificações e "fluidez" dos recursos na equipe de resposta e decompor o manual de instruções básicas com graus de liberdade para um especialista em um "alfabeto" passo a passo para serviços externos.Desenvolver um processo de resposta é algo muito criativo para todas as empresas. No entanto, é muito útil levar em consideração a sua própria experiência e a experiência dos outros. E que o NIST esteja com você.