O Custo dos Silos na Resposta a Incidentes

Por que integrar observabilidade e segurança é essencial para reduzir riscos e aumentar a resiliência dos negócios?

Você já parou para pensar que quando um incêndio, um acidente de trânsito ou um acidente doméstico ocorre, o cidadão brasileiro precisa saber de cor se deve discar 193 (Bombeiros), 190 (Polícia Militar) ou 192 (SAMU)? Se estiver numa rodovia federal, talvez precise do 191; no caso de risco estrutural, entra em cena o 199 da Defesa Civil.

São ao menos seis números nacionais e outros regionais para termos em mente nos momentos de crises. Grande parte da população certamente admitiria não saber qual número acionar em eventos de urgência ou emergência e várias pessoas já devem ter ligado para o serviço errado, perdendo minutos preciosos.

A ausência de um “911” único cria dois problemas: exige do usuário um diagnóstico prévio, difícil em momentos de pânico, além disso, adiciona uma demora no tratamento da crise. Agora, troque o cenário de incêndio que citei, por uma situação de vazamento de dados, o cidadão por um analista de TI e os bombeiros pelo SOC. Nas empresas, a mesma fragmentação em silos se repete: métricas de performance da infraestrutura ficam no NOC, alertas de ameaças vão para o SOC, e os logs de aplicações estão em outra equipe (quando existem!). O resultado é o mesmo atraso crítico quando segundos valem milhões.

Exemplo prático e situação hipotética

Imagine que uma grande rede de lojas tem sua página de checkout com lentidão no processamento de cartões em plena Black Friday. Operadores percebem o problema, o time de infraestrutura é acionado que atua para resolver, mas sem a visão de todo o contexto. Para entendermos o todo, consideremos abaixo a timeline do ocorrido:

11h30 — Atacantes iniciam um ataque DDoS discreto contra servidores específicos do e-commerce. Não o suficiente para derrubar o site, mas o bastante para degradar sutilmente a performance.

12h15 — O NOC começa a receber as primeiras reclamações de lentidão. Aumentos de 3 a 5 segundos no tempo de processamento afetam 23% dos clientes. A resposta padrão: reiniciar serviços e, logo depois, escalar mais servidores. Afinal, é Black Friday!

14h00 — No momento de pico das vendas, o SOC detecta um comportamento anômalo: múltiplas tentativas de login com falhas em diversos endpoints, seguidas de acessos bem-sucedidos. O padrão indica um ataque de credential stuffing em andamento, quando atacantes testam combinações de usuário e senha obtidas de vazamentos anteriores, até encontrar acessos que funcionam. Havia multifator (MFA) para parte dos acessos, mas a proteção não estava em todas as aplicações (algo muito comum, não é mesmo?).

Seguindo o protocolo padrão, o SOC imediatamente bloqueia os IPs suspeitos e força a redefinição de senhas dos usuários afetados. Retroalimenta o risco já mapeado devido à ausência do MFA junto ao time de GRC e vida que segue. Missão cumprida? Aparentemente sim. O incidente é classificado como “solucionado” e arquivado.

14h30 – 16h45 — O que nem o SOC e nem o time de Infraestrutura ou de sistemas perceberam (e não teriam como perceber sem uma visão integrada da observabilidade) era o contexto completo da situação:

A degradação de performance afetava diretamente uma API crítica de processamento de cartões. Essa API possuía uma vulnerabilidade sutil: uma “race condition” que só se manifestava sob condições específicas de latência. Quando o sistema estava sobrecarregado, com tempos de resposta elevados, várias requisições simultâneas podiam explorar uma janela de tempo na qual reembolsos eram aprovados antes mesmo que todas as checagens de segurança fossem concluídas.

Com as credenciais de funcionários de um setor interno, obtidas no ataque de credential stuffing, os invasores exploraram essa brecha. Durante o período de lentidão, dispararam requisições que aprovaram reembolsos fraudulentos para contas mulas, desviando milhões em horas.

48 horas depois — A contabilidade detecta as primeiras discrepâncias. Uma investigação forense revela a cruel ironia: todos os sinais estavam presentes, mas isolados em diferentes silos organizacionais:

• O SOC identificou as tentativas de logon anômalas, mas sem visibilidade sobre o impacto nos sistemas, tratou o caso de forma pontual.
• O NOC percebeu o aumento de latência que afetou 20% dos usuários, mas atribuiu ao volume normal de Black Friday.
• As ferramentas de observabilidade detectaram picos incomuns de chamadas à API de reembolso — 850% acima da média —, mas como não havia alertas críticos associados, foram ignorados.
• O time de fraude só foi acionado quando o prejuízo já estava consolidado.

Será que uma plataforma integrada de observabilidade e segurança poderia levar esta situação a outro desfecho? Seguramente, o aumento da latência correlacionado ao contexto de vulnerabilidades, contexto de negócio e às tentativas de login anômalas teria disparado um alerta mais efetivo.

Este caso, ainda que simplificado para fins didáticos pois abstrai alguns pontos do mundo real, ilustra perfeitamente por que a convergência entre segurança e observabilidade não é luxo, mas necessidade. Luxo seria mesmo poder manter estes processos completamente segregados.

Ganhos e desafios da observabilidade integrada

Observabilidade não se trata de dashboards bonitos, mas sim da capacidade de deduzir o estado interno de um sistema a partir de tudo que ele emite:

• Métricas revelam tendências e picos inusitados. 
• Logs contam a história do que ocorreu. 
• Rastreamentos (traces) mostram o fio condutor de cada transação.

Quando essas telemetrias fluem para um propósito único de colaboração e sinergia, alertas de segurança são enriquecidos com contexto de performance, comportamento, dependências sistêmicas, assim como alertas de sistemas ganham mais contexto de segurança. Sem essa união, as equipes acabam por, muitas vezes, trabalhar “no escuro”.

Ambientes grandes, heterogêneos e distribuídos certamente sofrem bastante por conta da monitoração em silos, obviamente, também se beneficiam muito com observabilidade integrada. Nesse contexto, eu destacaria os seguintes ganhos:

• Resiliência Mensurável — menos downtime, menor risco reputacional e conformidade facilitada. 
• Eficiência Operacional — redução de ferramentas redundantes e de ruído entre equipes. 
• Visibilidade End-to-End — compreensão em tempo real dos fluxos de negócio críticos. 
• Melhoria nas tomadas de decisão — priorização de investimentos guiada por dados correlacionados e visão holística, não por suposições ou visões míopes.

Para integrar observabilidade e segurança não há necessidade reinventar a roda, mas sim adotar simples práticas que, quando somadas, potencializam um ambiente mais seguro e confiável. Dentre essas práticas, três são fundamentais:

• Gestão de ativos: Assim como não se pode deixar um prédio sem mapa de saídas de emergência, as empresas precisam ter um inventário vivo de sistemas e componentes de tecnologia, atualizado de tudo que roda no ambiente. Hoje, existem excelentes ferramentas que permitem manter esse mapa com bons níveis de automação, identificando todo e qualquer tipo de ativo de tecnologia, softwares, APIs, componentes ou códigos de terceiros etc. 
• Visibilidade de conexões e fluxos: Saber quem conversa com quem dentro da infraestrutura é crucial. Plataformas de telemetria já conseguem gerar visões gráficas automaticamente, revelando relações entre aplicações, servidores e bancos de dados. Isso permite que as equipes possam entender o contexto de negócio e compreender também o mapa de ameaças, entendendo por onde um problema poderia se espalhar caso algo dê errado.
• Automação: Em algumas situações, há muito receio em deixar máquinas tomarem decisões sozinhas em caso de incidentes. A automação não substitui o humano, mas ela ajuda a ganharmos tempo. É como acionar um alarme de incêndio automaticamente ao detectar fumaça, sem depender de alguém apertar o botão. Sem dúvidas, a depender do nível de automação que se quer, é preciso de bastante maturidade no entendimento do contexto de negócio e do real cenário de ameaças (item anterior).

Importante ressaltar que nem tudo são flores. Claro que unir observabilidade e segurança nunca será da noite para o dia. Existem barreiras práticas e culturais no caminho, por exemplo:

• Sistemas Legados: Muitas empresas ainda operam aplicações obsoletas que não foram desenvolvidas para fornecer dados de telemetria. Reescrever tudo pode ser caro e até arriscado. Talvez uma saída seja usar tecnologias como “camadas externas” ou “sensores” que coletem informações sem alterar o código original.
• Resistência Cultural: os times de segurança e os times operações historicamente andam em trilhas separadas, cada uma com suas metas e indicadores. Integrá-las exige criar metas compartilhadas — e o tempo de detecção (MTTD) e de resposta (MTTR) podem ser bons pontos de partida. Quando todos são avaliados pelo mesmo critério, nasce o espírito de colaboração.
• Custo das Ferramentas: Consolidar dados de diferentes áreas e processos pode ser custoso, especialmente se for preciso trocar todo o ecossistema de ferramentas. O ideal é priorizar soluções modulares, que se encaixem no que a organização já possui, e caminhar gradualmente rumo a uma arquitetura unificada e integrada. Não se trata de jogar tudo fora, mas sim de conectar as engrenagens certas no momento certo.

A fragmentação dos canais de emergência brasileiros pode nos ensinar que, quando a crise chega, o tempo gasto escolhendo até encontrar o número certo agrava as consequências. No mundo corporativo, separar times de operações e time de segurança é benéfico para segregar funções, mas isso não quer dizer que esses times não podem buscar sinergias com o propósito de se antecipar a crises e tratar incidentes de maneira integrada e colaborativa.

A integração entre observabilidade e SOC é uma linha de defesa vital na batalha por disponibilidade, confiança e receita. Além disso, pode ser o passo inicial para a fundação de um Fusion Center… mas isso é assunto para outra conversa.

Nota: Este artigo reflete exclusivamente minha visão pessoal sobre o tema abordado. Exemplos, situações e reflexões aqui apresentados não se referem e nem estão vinculados a projetos, atividades ou contextos específicos dos meus empregadores, atuais ou anteriores, e tampouco derivam de quaisquer informações confidenciais ou internas.

Siga o Itshow no LinkedIn e assine a nossa News para ficar por dentro de todas as notícias do setor de TI, Telecom e Cibersegurança!