Você pode saber pouco sobre o SOC, mas ainda ficará intuitivamente claro que há apenas duas coisas que mais importam em seu trabalho: identificar incidentes e responder a eles. Ao mesmo tempo, se você não considerar a situação quando estamos lidando com fraudes internas complexas ou sinais da atividade de um grupo profissional, a resposta, em regra, consiste em várias medidas técnicas muito simples (remoção do corpo ou software viral, bloqueio de acesso ou conta) e medidas organizacionais (esclarecimento das informações dos usuários ou verificação e enriquecimento dos resultados da análise em fontes inacessíveis ao monitoramento). No entanto, por várias razões, o processo de resposta ao cliente começou a mudar significativamente nos últimos anos, e isso exigiu alterações por parte do SOC. Além disso, como estamos falando de uma resposta, onde "não apenas tudo" é importante - e precisão,integridade e velocidade da ação - é altamente provável que, se o seu SOC interno ou externo não levar em consideração os novos requisitos para esse processo, você não conseguirá lidar com o incidente normalmente.
Agora, muitos de nossos clientes estão mais à vontade em receber uma resposta como um serviço de "ciclo completo" - nesse caso, bloqueamos o ataque às defesas da empresa e acompanhamos o processo de resposta na área de responsabilidade do serviço de TI. Por exemplo, ajudamos na justificação do bloqueio, que teoricamente pode levar a problemas nos processos de negócios, ou aconselhamos sobre o trabalho que parcialmente precisa ser feito do lado deles - bloqueio de contas, isolamento de host etc.
Mas a maioria ainda prefere se engajar na resposta técnica por conta própria, e exige de nós a detecção oportuna de um incidente, a análise e a filtragem de falsos positivos, além de fornecer informações analíticas com recomendações sobre ações prioritárias em resposta a um incidente.
Quem esteve anteriormente envolvido nesse processo e foi responsável pelo resultado por parte do cliente? Como regra, um ou dois especialistas em segurança da informação que combinaram a resposta trabalham com outras tarefas do departamento e nem sempre possuem um profundo conhecimento de nicho na análise de ataques (como você pode ver no parágrafo anterior, isso não era necessário). No entanto, sempre foi sobre especialistas em segurança da informação que entendem os riscos, ameaças e o contexto do que está acontecendo.
Recentemente, a responsabilidade pela integridade e pontualidade da resposta do lado do cliente é cada vez mais distribuída entre segurança da informação e serviços de TI, e aqui está o porquê.
Primeiro, o número de incidentes e suspeitas de incidentes aumentou significativamente. Se anteriormente o número médio de notificações era medido em cem ou duzentos por mês, agora aumentava várias vezes. Parte do problema é o crescimento da entropia nas infra-estruturas corporativas, devido a constantes (e nem sempre fixas) mudanças causadas pelo que hoje é chamado de termo na moda "digitalização" ou "transformação digital". Um efeito colateral é que as ações do usuário se tornam mais variadas e as soluções técnicas têm mais probabilidade de classificá-las como anomalias comportamentais, que, por sua vez, podem ser confundidas com um invasor por um agente de segurança. Estes são falsos positivos, digamos, do primeiro tipo.
Em segundo lugar, a atividade dos criminosos cibernéticos, é claro, também cresce constantemente (em outras palavras, há mais ataques), isso é observado por nós, outros participantes do setor e os próprios clientes. Como resultado, o SOC deve constantemente inventar cenários de detecção de ataques cada vez mais inteligentes e conectá-los ao cliente. Isso, é claro, também leva a um aumento no número de operações, no não determinismo das ações do cliente e na necessidade de informações sobre o incidente para conter um contexto externo (cuja estação de trabalho é essa, é costume na empresa usar ferramentas de acesso remoto e, em caso afirmativo, quais, quem? eles podem ser usados para o que e assim por diante).
Na verdade, isso leva ao fato de que, para acelerar o processo de resposta, mais e mais empresas estão tentando transferir o SOC externo para a interação direta, não com a segurança da informação, mas com os departamentos de TI. E isso é bastante lógico: os incidentes que exigem remoção de software ou bloqueio de conta são enviados diretamente para a TI, exigindo isolamento da rede do host - para os departamentos da rede + helpdesk e assim por diante. Se a empresa possui seu próprio centro de monitoramento, geralmente é obrigada a transferir gatilhos do sistema SIEM para a TI.
No entanto, qualquer alteração no processo é o risco de abrandá-lo, o risco de informações incompletas para as partes e, finalmente, uma diminuição na eficiência. Felizmente, a maioria das empresas entende isso; portanto (e às vezes devido a requisitos legislativos - em particular na criação de centros GosSOPKA), existe agora uma demanda crescente por verificar o nível real de resposta - completude, qualidade e tempo das recomendações dos departamentos de TI e segurança da informação empresas.
No entanto, antes de realizar auditorias, é necessário fornecer às pessoas uma ferramenta para alcançar o resultado, ou seja, o SOC deve adaptar os resultados da análise de cada incidente para um roteamento claro em TI. Por tentativa e erro, compilamos uma lista de requisitos para informações sobre incidentes enviadas ao cliente.
Nesses resultados da análise do incidente, o funcionário responsável pela resposta técnica deve ser claramente identificado.Quais
são as armadilhas: para identificar corretamente a pessoa responsável, é necessário identificar com precisão a localização do incidente - um departamento específico, a criticidade do host, sua afiliação comercial, o tipo de incidente. Isso requer uma imersão muito profunda na infraestrutura do cliente no estágio de inventário (e, muito importante, atualização constante desses dados).
As mesmas informações são necessárias para determinar a criticidade de um incidente. Por exemplo, o banco está pronto para reagir a uma infecção por vírus de um carro em uma agência em Magadan muito mais lentamente e com a ajuda de um especialista local em segurança da informação. Se estivermos falando sobre o AWP local do KBR, o incidente exigirá uma resposta e envolvimento imediatos, incluindo o CISO do cliente para coordenar o risco, bem como os especialistas do centro de comunicação no site para isolar imediatamente o host.
Responder a um ataque a um aplicativo Web no segmento de comércio eletrônico, geralmente requer o envolvimento não apenas da equipe de segurança, mas também de especialistas em aplicativos que podem determinar com mais precisão os riscos associados à sua implementação e descarregar informações sobre pedidos do banco de dados no mesmo host, pelo contrário, em nenhum caso ele deve envolver candidatos (eles são um dos possíveis invasores) ou mesmo especialistas em TI, mas, além da segurança da informação, geralmente exige a participação do serviço de segurança econômica.
Todos esses cenários - a quem envolvemos quando, em que estágio e com que finalidade - devem ser elaborados previamente e acordados com o cliente. O SOC conhece melhor a segurança das informações, mas o cliente conhece melhor seus negócios e quais riscos são mais críticos para ele, portanto os scripts são desenvolvidos juntos.
Isso também se aplica à descrição da ameaça e seus riscos e ao nível de detalhe na descrição das recomendações de resposta. Além disso, idealmente, a sequência de ações necessárias deve ser dividida em uma árvore de eventos obrigatórios e auxiliares. Por exemplo, se o SOC registrar o lançamento da Ferramenta de Administração Remota no host final, mas o nível de auditoria não for suficiente para distinguir a atividade do usuário de um possível lançamento de uma backdoor por um invasor, o primeiro e obrigatório ponto será a comunicação do especialista com o usuário para descobrir se ele iniciou essa atividade. Se a resposta for afirmativa, essa é uma atividade regular ou, no máximo, uma violação da política de segurança da informação. Se negativo, pode fazer parte de um ataque de hackers e requer um trabalho de resposta completamente diferente.
A verificação dos resultados da resposta deve conter a possibilidade de controle técnico do fato da implementação das recomendações (usando logs no SIEM ou de outras ferramentas) e do fato de que o incidente não se repetirá no futuro.Vamos
continuar o exemplo executando o RAT no host. Por exemplo, fomos à primeira filial - atividade do usuário que violava as políticas de segurança da informação. Nesse caso, o serviço de TI será aconselhado a remover o RAT no host. Além do lançamento controlado do script de exclusão ou da verificação da ausência / presença do utilitário no host, os meios de inventário devem estar vinculados ao incidente antigo quando ele é repetido. Isso sinaliza não apenas uma violação repetida, mas também sobre uma possível implementação de baixa qualidade da recomendação pela resposta.
Finalmente, o contexto ou vizinhança delta do incidente é importante. É muito importante o que exatamente aconteceu com essa máquina / conta durante o último intervalo de tempo, se houve algum incidente semelhante ou potencialmente relacionado que pudesse ser coletado na cadeia de extermínio. Essas informações permitem determinar rapidamente se você precisa envolver imediatamente a segurança ou a Equipe de resposta a incidentes do provedor no incidente.
Cada SOC está procurando suas próprias respostas para esses desafios e pode executar essas tarefas usando ferramentas diferentes. O principal é controlar se o faz em princípio. Como em incidentes menores, atrasos e hesitações na resposta podem ser imperceptíveis, e em incidentes críticos, um processo não regulamentado simplesmente não funcionará. E é como se não houvesse culpados.