Ter um ROC já não é um luxo; é uma necessidade

Há muito tempo, a segurança corporativa tem priorizado a rapidez de resposta em detrimento da prevenção de riscos. A Qualys, parceira da Nexoria, percebeu desde cedo que isso deixava metade do problema sem solução e passamos anos desenvolvendo estruturas operacionais para preencher essa lacuna. O Centro de Operações de Risco (ROC) é o resultado disso.

Aqui vai um cenário que todo líder de segurança reconhecerá. Uma configuração incorreta na nuvem é sinalizada em uma terça-feira de manhã. O risco real é identificado corretamente. Ele é registrado, categorizado como de gravidade média e atribuído a uma equipe que já está sobrecarregada. Outros 63 tickets estão aguardando.

A configuração incorreta é categorizada como de gravidade média, registrada como um problema conhecido e colocada na fila – triagem de rotina. Priorização sensata. O sistema está funcionando exatamente como foi projetado.

Três meses depois, essa mesma empresa está lidando com uma exposição significativa de dados. A configuração incorreta? Ainda intocada. Nos meses que se passaram, fluxos de trabalho de provisionamento automatizados foram construídos sobre ela, cada um razoável isoladamente, cada um expandindo silenciosamente o raio de impacto. Nenhuma decisão isolada estava errada. Nenhuma pessoa falhou. O ambiente tornou-se frágil enquanto todos os painéis mostravam verde.

Isso não se baseia em uma única violação. É um padrão que temos visto se repetir em todos os setores, ano após ano. E a pergunta em todas as análises pós-incidente é sempre a mesma: como deixamos isso passar?

A verdade incômoda é: você não deixou passar nada. Você viu, registrou e arquivou. O problema nunca foi a visibilidade. O problema era o próprio modelo operacional.

Essa lacuna foi o que nos levou a criar o Centro de Operações de Risco (ROC), não para substituir o Centro de Operações de Segurança (SOC) que a maioria das empresas já utiliza para respostas, mas para realizar o trabalho para o qual ele nunca foi projetado.

Uma máquina otimizada para o momento errado

O SOC foi, para a época, a resposta certa. As ameaças se apresentavam como eventos: um login suspeito, uma assinatura de malware conhecida, uma porta que não deveria estar aberta. Você criou um sistema para detectar esses eventos, responder rapidamente e restaurar a ordem. Em um mundo de redes delimitadas e infraestrutura predominantemente estática, isso funcionava.

A empresa que administramos hoje não se parece em nada com aquele mundo. As plataformas de nuvem tornaram a infraestrutura fluida e constantemente reabastecida. Sistemas de IA com agentes agora tomam decisões antes reservadas aos humanos, raciocinando e agindo simultaneamente em várias ferramentas e conjuntos de dados. Os direitos de acesso se expandem dinamicamente.

Os pipelines de dados são redirecionados meses após sua criação, sem que ninguém reavalie os pressupostos originais de governança. A superfície de ataque não permanece estável o tempo suficiente para ser mapeada, muito menos defendida de forma reativa.

Nesse ambiente, o risco não se anuncia. Ele se acumula, moldado por milhares de pequenas decisões, cada uma delas defensável individualmente, mas coletivamente perigosa. O SOC foi projetado para aguardar que os limites sejam ultrapassados. Ele é estruturalmente cego à longa e silenciosa fase em que esse acúmulo realmente ocorre. Quando um alerta é disparado, não é o início de um problema. É o momento em que o problema não pode mais permanecer oculto.

Resolver mil descobertas de baixo impacto não melhora significativamente a segurança se a exposição mais grave permanecer intocada.

Construindo o Argumento a Favor da Prevenção

O ROC não surgiu de um roteiro de produtos. Ele resultou de uma observação específica e recorrente, extraída de anos de conversas com clientes e de própria experiência na gestão de segurança da Qualys.

O lado reativo da segurança sempre teve uma estrutura: fluxos de trabalho compartilhados, ferramentas comuns e um ritmo operacional claro. A prevenção nunca teve. O gerenciamento de vulnerabilidades ficava em um canto da organização, a governança em outro, a configuração incorreta da nuvem e os riscos de contêineres em outro lugar, e os riscos de fornecedores eram tratados por mais uma equipe. Todos estão trabalhando duro. Ninguém está olhando para o mesmo quadro.

Assim, prova-se que as coisas poderiam ser diferentes ao mudarmos isso nós mesmos. Quando a Qualys reorganizou a liderança de segurança, reuniu governança, risco de fornecedores, risco tecnológico, configuração incorreta na nuvem e risco de contêineres em uma única disciplina. A fragmentação desapareceu quase imediatamente. O trabalho avançou mais rapidamente. Os relatórios tornaram-se coerentes. As conversas com a própria liderança ficaram mais precisas. Não era uma teoria que estávamos testando; era a prova de que a prevenção poderia ser conduzida com o mesmo rigor operacional que a resposta.

O que foi descoberto internamente, os clientes da Qualys confirmaram externamente. Empresas descreveram o mesmo problema com palavras diferentes: dados de risco espalhados por sistemas desconectados, falta de linguagem comum entre a segurança e os negócios, e conselhos de administração recebendo mapas de calor que transmitiam urgência sem nunca explicar o que o risco significava em termos financeiros.

Quando os relatórios sobre a exposição financeira vinculada a processos de negócios específicos foram reestruturados, os membros do conselho disseram que gostariam que todas as organizações sob sua supervisão fizessem o mesmo. Pessoas com visibilidade em toda a organização afirmavam que essa era uma lacuna generalizada no mercado, e não apenas um problema nosso a ser resolvido.

A prevenção como disciplina operacional

Se o lado reativo da segurança se beneficia de um modelo operacional centralizado, por que o lado preventivo deveria ser diferente?

O Centro de Operações de Risco é a resposta a essa pergunta. Não é um produto novo. Não é um SOC renomeado. É um modelo operacional orientado para a prevenção que compreende que o risco não surge repentinamente; ele se desenvolve continuamente.

O SOC pergunta: o que acabou de acontecer?; O ROC pergunta: o que está mudando, onde está a vulnerabilidade com uma rota de ataque aos nossos ativos críticos e quais controles estão em vigor ao longo dessa rota de ataque e se são eficazes contra um agente de ameaça específico que utilize ferramentas, técnicas e táticas específicas? Ele observa como o acesso evolui à medida que os projetos ganham escala. Ele acompanha como ocorrem as mudanças no fluxo de dados quando os pipelines são redirecionados. Ele monitora como os fluxos de trabalho automatizados aumentam o risco à medida que ganham autonomia. Sua função não é prever a próxima violação. É revelar exposições emergentes enquanto ainda há tempo para tomar uma decisão deliberada, em vez de reativa.

O risco neste modelo é pontuado com base nas consequências para os negócios, não apenas na gravidade técnica. Uma vulnerabilidade em um servidor interno não crítico não é o mesmo que uma exposição explorável em um sistema que lida com pagamentos de clientes. A mesma configuração incorreta que parece de baixa prioridade isoladamente pode representar um risco significativo quando se consideram as identidades que podem acessá-la, as ferramentas que essas identidades podem invocar e o processo de negócios que depende dela. Esse contexto é o que muda a decisão. O ROC o revela continuamente, não no relatório trimestral que chega depois que a janela para agir já se fechou.

O sucesso no ROC não é medido pelo número de tickets encerrados. É medido pela tendência do risco geral da organização: se está caminhando na direção certa. Essa é a diferença entre uma função de segurança que explica o que deu errado e uma que garante que menos coisas deem errado. Há anos, a Qualys vem trabalhando para alcançar esse modelo.

Este artigo foi escrito por Jonathan Trull, CISO, EVP & GM na Qualys, e foi traduzido e adaptado pela Nexoria.