KPIs do Security Operations Center: Como chegamos ao nosso sistema de métricas

Não vou escrever aqui textos longos e obscuros sobre “como construir um sistema KPI para SOC corretamente”. E vou apenas contar como lutamos e buscamos por nossa própria metodologia e como agora medimos, "quão ruim / bom / seguro / (sublinhe o necessário) tudo é".

Como tudo começou

Curiosamente, nossos primeiros passos para a formação de KPIs para Solar JSOC não foram de forma alguma conectados com os centros de monitoramento e resposta a ataques cibernéticos. “No início da nossa juventude,” ajudamos as empresas a construir sistemas para avaliar a eficácia da segurança da informação (ISMS 27001 e isso é tudo). O entendimento de sua necessidade surgiu então no mercado de forma natural: quase todo departamento de segurança da informação dia após dia é forçado a analisar grandes quantidades de dados de diversos sistemas diferentes. Claro, cada um deles tem algum tipo de relatório, mas com um grande número deles, é muito difícil formar uma imagem holística do estado da segurança da informação e, em seguida, fornecer um relatório para a gerência em um formato conveniente. O problema é agravado se a organização estiver geograficamente dispersa.



Acabamos de ajudar os clientes a construir não apenas um complexo de KPIs / métricas, mas uma solução analítica completa que agrega dados de sistemas de segurança da informação. Na verdade, é um sistema de visualização no qual você pode ver de forma rápida e fácil a essência do problema e sua localização para tomar rapidamente as decisões necessárias. Nestes projetos, ganhamos experiência e chegamos à conclusão de que o sistema é realmente prático e útil. E também que o trabalho do SOC também precisa ser avaliado.

Por que avaliar a eficácia de um SOC, especialmente externo?

É simples: por um lado, queremos entender o quão bem prestamos o serviço e, por outro, ter a visão mais completa da infraestrutura do cliente, ver todos os “pontos negros” que não foram incluídos em nossa auditoria e se tornaram fatores de risco para o serviço. Simplificando, queremos entender: veremos este ou aquele ataque ao cliente ou não.



Quando começamos a trabalhar como prestadora de serviço, aconteceu que o cliente se recusou a nos fornecer fontes específicas de conexão, que eram necessárias para 100% de identificação do ataque. Como resultado, tal ataque aconteceu, não o vimos e recebemos reprovações, apesar do nosso aviso inicial.



Outro exemplo: dissemos que para identificar de forma correta e precisa um incidente, é necessário configurar as fontes de uma determinada forma, demos uma lista dessas configurações, mas o cliente não realizou esse trabalho. O resultado é o mesmo - um incidente perdido.



Assim, chegamos ao entendimento de que é importante destacar explicitamente tanto o cliente quanto a nós mesmos, o que exatamente vemos em sua infraestrutura, onde existem “pontos cegos” para nós, quais vetores de ataque são implementados com mais frequência e em quais áreas, qual TI os ativos são mais suscetíveis a ataques e como isso pode afetar os negócios. Para isso, o sistema de visualização deve mostrar a situação real e ajudar na sua análise, e não apenas ser um “efeito uau” para a liderança (como costuma acontecer).

KPI para SOC - o que e como medir?

Em primeiro lugar, você precisa entender: por que, por que você precisa desse mesmo sistema de KPI / métricas? Você quer medir o desempenho do seu departamento de segurança da informação? Compreender o quão bem / com sucesso (ou vice-versa) seus processos estão executando? Ou talvez apenas mostre à gerência, "quem é ótimo?" Ou talvez os bônus do departamento dependam do desempenho do KPI? Sem compreender as metas de avaliação da eficácia, é impossível construir um sistema KPI da vida real.



Digamos que decidimos quais são os objetivos e agora surge a questão mais interessante: como medir algo? Você não pode ir para o SOC com uma régua, tudo é um pouco mais complicado aqui. Afinal, não se trata apenas do SIEM como sistema de coleta e correlação de eventos de segurança da informação, é também uma grande variedade de sistemas que permitem que o serviço funcione corretamente. Há uma quantidade absurda de dados dentro do SOC, então há muito o que avaliar.



E, nesse caso, estamos tentando evitar KPIs subjetivos tanto quanto possível, ou seja, aquelas métricas que não podem ser medidas automaticamente. Por exemplo, a métrica "Quão ruim está tudo conosco" é difícil de avaliar diretamente, sem a participação de uma pessoa (que dará sua curvanem sempre a opinião correta, com base na minha própria experiência). Mas se dividirmos essa métrica em outras menores, então elas já podem ser calculadas com base em dados de meios técnicos. Essa. é preciso definir o que está incluído no conceito de "tudo é ruim" para nós: não temos um sistema específico de segurança da informação; antivírus não é implantado onde for necessário; especialistas processam incidentes ou solicitações por muito tempo; todos os nossos hosts têm mais de 10 vulnerabilidades críticas e ninguém as corrige, etc. E agora, se todas essas pequenas métricas, levando em consideração seus coeficientes de peso para o nosso negócio, forem coletadas em um único cálculo, então obteremos o valor da métrica "Quão ruins somos." Além disso, poderemos explicar em que se baseia e porque o seu significado certo sugere que é hora de resolver urgentemente problemas graves na organização da segurança da informação.E o mais importante, podemos sempre nos aprofundar nos detalhes dessa métrica e entender quais tarefas estão em qual prioridade.



Ao construir nosso sistema KPI, aderimos aos seguintes princípios:

• O KPI deve ser realmente importante para o SOC e para o cliente;
• o indicador deve ser mensurável, ou seja, fórmulas de cálculo específicas devem ser construídas e valores limite definidos;
• devemos ser capazes de influenciar o valor do indicador (ou seja, as métricas da categoria “porcentagem de dias de sol em um ano” não são adequadas para nós).

Também chegamos à conclusão de que o sistema KPI não pode ser uniforme e deve ter pelo menos três níveis:

1. “Estratégico”: são KPIs que refletem o quadro geral de cumprimento dos objetivos definidos;
2. “Investigação, análise, identificação de ligações”: são os KPIs, com base nos quais se forma o primeiro nível e que contribuem para a concretização do objetivo principal.
3. « »: KPI, ( – ).

Cada um dos indicadores afeta o superior. Como essa influência não é a mesma, cada um dos indicadores recebe um fator de ponderação.



Obviamente, a primeira coisa que queremos ver o tempo todo é quão eficaz é nosso serviço para nossos clientes. E, claro, essas informações devem ser oportunas. Para tal, desenvolvemos (e continuamos a melhorar) um sistema de métricas que reflecte a qualidade do trabalho de cada um dos serviços: 1ª e 2ª linhas, gestores de serviço, analistas, resposta, administração, etc. Para cada uma destas áreas, cerca de 10-15 KPIs - foram calculados com base no banco de dados dos sistemas nos quais os caras trabalham (se as solicitações são concluídas no prazo, se respondemos rapidamente à solicitação do cliente, como as fontes estão conectadas e muito mais).

SLA é bom, mas a qualidade real do serviço é mais importante

É importante para nós que a cobertura do serviço nos permita identificar o número máximo de incidentes e ataques, e não ser gatinhos cegos. Para que possamos interpretar os incidentes no cliente no formato de seus próprios ativos de TI, e não IPs abstratos. Para que nossas notificações não se reduzam ao fato de que "Mimikatz foi encontrado no host 10.15.24.9" e não obriguem o cliente a descobrir de forma independente que tipo de host é, desperdiçando o tempo necessário para responder e eliminar as consequências.



Em outras palavras, é importante entendermos até que ponto os clientes são protegidos por nosso SOC. Portanto, é necessário determinar o quão detalhados e suficientemente os "vemos":

• todas as fontes significativas estão conectadas a nós;
• quão eficientemente o sistema de segurança da informação do cliente (eles são fontes de nosso serviço) cobre sua infraestrutura;
• todas as fontes estão configuradas conforme recomendamos e quais são os desvios;
• se todos os cenários necessários e suficientes para detectar ataques e incidentes foram lançados nas instalações do cliente;
• se todas as fontes conectadas nos enviam eventos com uma determinada regularidade;
• se o cliente reage a todas as nossas notificações e com que rapidez o faz.

E também - como é "assustador viver dentro deste cliente", isto é:

• quantas vezes ele é atacado, qual a gravidade desses ataques (direcionados ou massivos), qual é o nível do atacante;
• quão eficaz é a proteção do cliente (processos e sistemas de segurança da informação) e com que frequência é atualizada;
• qual é a criticidade dos ativos envolvidos em incidentes, quais dos ativos são usados ​​pelos invasores com mais frequência, etc.

Para calcular todos esses indicadores de alto nível, você deve primeiro dividi-los em menores e aqueles em ainda menores - até atingirmos o nível Zen de pequenas métricas que podem ser calculadas de forma inequívoca com base no banco de dados de fontes e nossos sistemas internos.



O exemplo mais simples: há um indicador de alto nível "Eficiência dos processos de segurança da informação", composto por outros menores, como "Grau de proteção contra malware", "Grau de gerenciamento de vulnerabilidade", "Grau de proteção contra incidentes de segurança da informação", "Eficiência de controle de acesso", etc. ... Como muitos processos de segurança da informação são implementados em uma organização, haverá tantas métricas de segundo nível. Mas para calcular a métrica de segundo nível, você precisa coletar métricas ainda mais refinadas, por exemplo, "O grau de cobertura dos hosts da organização por antivírus", "A porcentagem de incidentes críticos com malware", "O número de ativos envolvidos", "A porcentagem de falsos positivos", "O nível de alfabetização cibernética dos usuários" , “Porcentagem de hosts em uma organização com proteção antivírus desabilitada”, “Porcentagem de hosts com bancos de dados antivírus desatualizados” - você pode continuar indefinidamente.E essas métricas de terceiro nível podem ser coletadas de ferramentas de segurança da informação e outros sistemas em modo automático, e o cálculo pode ser feito no sistema de análise de segurança da informação.



Criar KPIs e gerenciar o desempenho de SOCs ainda é um desafio tanto para os desenvolvedores dessas métricas quanto para o cliente (e esta é uma dança de pares exclusivamente). Mas o jogo vale a pena: no final, é possível avaliar de forma completa, central e rápida o estado da segurança da informação, encontrar pontos fracos, responder rapidamente a incidentes e manter o sistema de segurança da informação atualizado.



Se o assunto acabar sendo interessante, falarei mais sobre métricas nos próximos artigos. Portanto, se você quiser ouvir sobre qualquer aspecto específico da medição do SOC, escreva nos comentários - tentarei responder a todas as perguntas.



Elena Trescheva, analista líder da Solar JSOC