Peguei um caso em que duas pessoas da equipe financeira receberam um e-mail que se passava pelo CEO da empresa. A mensagem autorizava um pagamento de R$ 28.900,00 pelos serviços prestados. A equipe rapidamente identificou que se tratava de uma fraude e reportou o incidente para a área de cibersegurança. Ainda bem!
O atacante criou uma conta @outlook.com utilizando o nome do CEO, tentando conferir legitimidade ao envio (ex.: abc.xyz@outlook.com).
Além disso, ele alterou o campo Display Name da mensagem para o nome completo do executivo e criou uma assinatura com o logo da empresa.
No corpo do e-mail, o fraudador enviava uma chave Pix para a realização do pagamento, sendo essa chave o próprio CNPJ da empresa recebedora.
Até aí tudo comum em um ataque de phishing…
Por curiosidade, busquei informações sobre a empresa fraudadora e, por meio do CNPJ, cheguei até o proprietário. A empresa estava localizada em Arapongas – PR.
Ao analisar o histórico profissional do dono da empresa, encontrei um dado relevante: em 2023, o fraudador havia trabalhado em uma empresa prestadora de serviços para a companhia que agora estava sendo alvo.
Como o ataque foi direcionado, com conhecimento dos e-mails e dos nomes específicos envolvidos no processo de pagamentos, é bem provável que o atacante tenha se apropriado de alguma base contendo dados dos clientes do seu emprego anterior e, agora, estivesse aplicando golpes.
Infelizmente, trata-se de mais um caso típico de falhas de controle em múltiplos processos. A superfície de risco só cresce quando a cadeia de suprimentos não é monitorada de ponta a ponta.
João Fuzinelli, formado em Sistemas de informação possui algumas certificações de mercado e vasta experiência em ambientes de infraestrutura crítica e cibersegurança. Atualmente trabalha nas operações de SOC da CYLO Cybersecurity.
Com o aumento do número de vulnerabilidades descobertas diariamente, conhecer e saber categoriza-las no ambiente que está sendo gerenciado pela equipe de segurança se torna uma medida importante para mitigar os riscos de segurança em um ambiente de T.I.
A etapa da categorização das vulnerabilidades se torna fundamental para a equipe realizar a gestão do risco de forma eficiente e estruturar as ações de defesa do ambiente. Entendendo o que elas representam e seu potencial impacto, conseguimos elaborar um plano de ação mais eficiente e priorizar as ações de defesa.
Para ajudar na categorização, podemos utilizar alguns indicadores padrões de mercado que vão nos ajudar a direcionar o esforço, por exemplo o CVSS e o EPSS.
O CVSS (Common Vulnerability Scoring System), é um indicador padrão utilizado para medir a severidade de vulnerabilidades com um sistema de pontuação padronizado para avaliar e realizar a comparação da gravidade das vulnerabilidades de segurança, aplicando medidas quantitativa para medir o potencial de impacto da vulnerabilidade.
O CVSS atribui pontuações numéricas com base em diferentes métricas, onde este cálculo ajuda a equipe de segurança a priorizar os seus esforços para a correlação de vulnerabilidades e apoiar para uma melhor tomada de decisão para correção ou mitigação das vulnerabilidades.
Para realizar o seu cálculo, o CVSS, vamos exemplificar baseado na versão 3.X, utiliza algumas métricas como principais, como métricas de Base, Temporal e Ambiental. Cada métrica possui características diferentes e um peso no cálculo da pontuação da CVSS.
Métrica de Base são métricas onde são avaliados o potencial dano que a vulnerabilidade pode causar no ambiente, facilidade de exploração e a complexidade do atacante conseguir realizar o ataque bem sucedido.
Métrica Temporal são métricas onde são avaliados a evolução da vulnerabilidade ao longo do tempo, podendo incluir algumas características que são considerados no calculo da sua pontuação, como a maturidade do exploit, facilidade da sua correção, confiabilidade da fonte da informação e a quantidade de evidencias disponíveis.
Métrica Ambiental são métricas relacionadas a importância do impacto real para a organização em particular, baseadas em controles de mitigação que podem existir no ambiente para reduzir ou aumentar o impacto da vulnerabilidade ser explorada no ambiente.
Diante do número elevado de CVSS dos ambientes e com as equipes de segurança enfrentando uma grande dificuldade para priorizar as correções. Um grupo de pesquisadores do FIRST (Forum of Incident Response and Security Teams – https://www.first.org/about/), pensando em resolver esse problema, desenvolveu o EPSS, um modelo para calcular informações sobre exploração das vulnerabilidades e apoiar no direcionamento melhor das ações de correção de vulnerabilidades pela equipe.
O EPSS (Exploit Prediction Scoring System), fornece um “score” que é um indicador baseado em dados do CVSS para estimar a probabilidade de uma vulnerabilidade de software estar sendo explorada ativamente no ambiente, cujo seu objetivo, é auxiliar a equipe de segurança a priorizar os esforços de correção de vulnerabilidades com base no EPSS score.
O EPSS fornece uma perspectiva mais dinâmica e contextual, permitindo que as equipes priorizem vulnerabilidades que estão ativamente sendo exploradas, mesmo que tenham um score no CVSS baixo.
Correlacionando dados de CVSS + EPSS e aplicando inteligencia artificial, concluimos o valor do “Score EPSS”, um indicador mais robusto para a categorização de vulnerabilidades, onde podemos exemplificar conforme informações abaixo :
CVSS alto + EPSS alto = prioridade máxima
CVSS alto + EPSS baixo = monitoramento e mitigação planejada
CVSS baixo + EPSS alto = atenção especial, pois pode indicar ataques em andamento
Com essa informação, conseguimos que as equipe realizem uma gestão de risco mais inteligente, baseada não apenas em um unico indicador, mas também relacionando com a probabilidade real de ataque.
Categorizar as vulnerabilidades com base em métricas como CVSS e EPSS é essencial para uma resposta proativa e eficiente às ameaças cibernéticas. Em vez de reagir a cada alerta, as organizações podem tomar decisões assertivas, proteger seus ativos mais críticos e manter a confiança de seus clientes e parceiros.
Há algumas semanas atrás, colocamos em prática umas das famílias de controle do NIST SP 800-53 denominada: CP Contingency Plan que estamos implantando a alguns meses em um cliente
Esta família possui 13 controles dentre eles os de relevância para este post:
CP-1: Política e Procedimentos – Estabelece uma política e procedimentos formais para o plano de contingência.
CP-2: Plano de Contingência – Define o plano de contingência do sistema, incluindo objetivos de recuperação, prioridades de restauração e métricas de desempenho.
CP-4: Teste do Plano de Contingência – Recomenda a realização de testes para avaliar a eficácia do plano e a prontidão da equipe para executá-lo.
Durante a elaboração do plano de contingência (CP-2), definimos métricas para avaliar o sucesso dos testes. Essas métricas abrangem aspectos técnicos e, principalmente, indicadores alinhados aos objetivos do negócio.
As métricas voltadas para o negócio proporcionam ao corpo diretor uma visão clara do retorno sobre o investimento (ROI). Elas demonstram, na prática, que os recursos investidos no plano de contingência são justificados.
O que aconteceu durante o teste?
Embora o plano tenha sido bem estruturado, enfrentamos uma falha durante os testes devido a uma decisão equivocada. O processo começou bem: a infraestrutura foi restaurada em aproximadamente 20 minutos, bem abaixo da meta de 4 horas para a plena execução do sistema. Nosso plano incluía terceiros, com nomes, funções e contatos devidamente registrados no documento de contingência.
Dois dias antes do teste, foi tomada a decisão de não envolver o terceiro especialista responsável pelo sistema em questão, com a equipe interna assumindo essa responsabilidade. Com a infraestrutura funcionando perfeitamente, estávamos confiantes de que alcançaríamos um tempo de recuperação muito inferior ao planejado. No entanto, ao realizar os testes dos serviços do sistema, enfrentamos um erro inesperado.
A equipe responsável pelos testes e pela resolução do problema não conseguiu solucioná-lo imediatamente. Tentamos, então, contatar o terceiro especialista que havia sido previamente excluído da prática. Após cerca de duas horas sem resposta, declaramos a falha do teste. Ressaltamos que o teste foi realizado em um sábado, o que pode ter dificultado ainda mais comunicação.
Lições aprendidas
Siga o plano à risca: Um plano de contingência bem definido é projetado para antecipar problemas e deve ser rigorosamente seguido.
Impacto em situações reais: Em um cenário de desastre, especialmente em dias críticos para o cliente, a ausência/falta de comunicação com um terceiro essencial poderia resultar em caos operacional e consequentemente em perdas financeiras
Revisão de terceiros críticos: A confiabilidade de terceiros essenciais à operação deve ser constantemente avaliada. Contratos, canais de comunicação e acordos de disponibilidade precisam ser revisados, considerando que desastres não são previsíveis.
Com essa experiência deixo o questionamento: Seu plano de recuperação de desastres está bem definido e principalmente testado?
João Fuzinelli, formado em Sistemas de informação possui algumas certificações de mercado e vasta experiência em ambientes de infraestrutura crítica e cibersegurança. Atualmente trabalha nas operações de SOC da CYLO Cybersecurity.
