Um CISO de uma empresa multibilionária com quem conversamos recentemente fez uma observação que me marcou. A capacidade de segurança que eles mais valorizavam não era outra ferramenta de detecção ou framework. Era a velocidade.
Para eles, a velocidade na identificação de problemas, validação de correções e resposta a mudanças era a principal preocupação. Com tantos "incêndios" para apagar, isso também sugere que o tempo está se tornando uma restrição operacional.
O especialista em cibersegurança Phil Venables sugeriu recentemente que os programas de segurança terão cada vez mais sucesso ou fracasso com base na velocidade.
“A velocidade é tudo. Particularmente, como os defensores podem executar seu ciclo OODA (observar, orientar, decidir, agir) mais rápido do que os atacantes podem se adaptar”.
Este não é mais um artigo sobre "a IA está causando essa bagunça", no entanto – vamos confrontar a realidade mais ampla. Em nossa pesquisa com 200 CISOs e 200 líderes de engenharia (incluindo CTOs), 76% das organizações implementam atualizações significativas semanalmente ou mais rápido, e 39% implementam diariamente. Equipes de engenharia modernas implementam mudanças continuamente.
Mas a validação de segurança não opera nessa cadência; apenas 21% validam a segurança em cada release. Isso é mais do que um desalinhamento, é uma falha estrutural.
Camadas de Ritmo
Venables aponta para o framework “Pace Layers” de Stewart Brand para explicar como sistemas complexos evoluem.
“As camadas rápidas trazem novidade e experimentação, e as camadas lentas fornecem estabilidade e memória.”
A entrega de software é a camada rápida, enquanto a governança e a validação são a camada lenta. Ambientes de software modernos estão empurrando essas camadas para se distanciarem ainda mais. Equipes de engenharia estão aumentando a velocidade com que operam, enquanto a validação de segurança ainda funciona em ciclos trimestrais ou anuais.
Os resultados de segurança chegam depois que o sistema já mudou, então qual é o sentido?
O que acontece como resultado desse descompasso é inevitável; 85% dizem que as descobertas de segurança estão desatualizadas no momento em que os relatórios chegam, pelo menos às vezes, com quase metade (48%) afirmando que isso acontece com muita frequência ou o tempo todo.
Em outras palavras, no momento em que as descobertas dos testes são revisadas, o sistema que elas descrevem já mudou. Na prática, as equipes estão tomando decisões de segurança com base em um estado passado do sistema. Mesmo pequenas mudanças podem alterar a postura de segurança de um sistema. Um novo endpoint, um ajuste na lógica de autorização ou uma dependência atualizada podem abrir caminhos de ataque inteiramente novos. O pentesting frequentemente valida uma versão do sistema que não existe mais.
Como resultado, as correções sugeridas e o reteste podem resolver problemas de segurança mais antigos, mas, à medida que o software avança, as equipes começam a perder a confiança no sinal que o teste lhes forneceu, porque esse sinal chega tarde.
O resultado é um pouco como a mecânica de tempo em camadas em A Origem: diferentes partes do sistema agora operam em velocidades muito distintas, e ações tomadas tarde demais em uma camada podem ter pouco efeito sobre o que já está se desenrolando em outra.
A velocidade não deve vir à custa da profundidade
Para organizações que buscam uma postura de segurança aprimorada, a validação requer raciocínio, exploração, confirmação de exploit e análise de fluxo de trabalho. Precisa ser minuciosa (mas você já sabia disso).
“A análise estática tem seus limites. Se você não consegue validar o problema contra a aplicação em execução, é apenas uma hipótese”, diz Philippe Dourrasov, líder de pentest de IA na Aikido Security.
É por isso que testes de segurança significativos historicamente levaram tempo.
E assim, o desafio não é aumentar o número de testes, mas preservar a profundidade dos testes ofensivos reais enquanto opera em um ritmo muito mais elevado.
No entanto, as limitações dos testes periódicos em profundidade são claras. Em nossa pesquisa, 51% dos entrevistados acreditam que vulnerabilidades mais profundas, como falhas de lógica, controle de acesso quebrado ou caminhos de ataque multi-etapas, são sempre ou frequentemente perdidas.
Isso não é porque as equipes de segurança carecem de expertise. Em vez disso, é porque pentesters e red teams enfrentam uma série de restrições: testes com tempo limitado, sistemas em expansão, complexidade crescente e interconexão de sistemas. Mas, em sua essência, o dilema entre amplitude e profundidade é realmente um problema de tempo.
A validação deve seguir mudanças significativas
As organizações não estão cegas para a crescente incompatibilidade entre a velocidade de entrega e a validação de segurança. Muitos tentaram fechar essa lacuna realizando mais pentests ao longo do ano, escaneando continuamente ou comprimindo engajamentos manuais para se adequar a ciclos de lançamento mais apertados. Em teoria, essas abordagens aumentam a velocidade. Na prática, elas frequentemente apenas transferem o comprometimento para outro lugar.
A melhor mudança a ser feita é alinhar a validação com a forma como o software realmente muda. Isso não significa, na verdade, passar a testar tudo de forma constante ou contínua, mas sim permitir que a validação responda quando uma mudança significativa ocorre. Em outras palavras, validar mudanças que realmente introduzem risco. O desafio é que a maioria das abordagens de teste existentes não consegue operar com esse nível de responsividade. Pentests tradicionais levam dias ou semanas para serem agendados, executados e relatados. Mesmo os engajamentos mais rápidos não conseguem, realisticamente, acompanhar as mudanças que ocorrem diariamente ou várias vezes ao dia. As mudanças não são meramente cosméticas, mas sim coisas como novos endpoints de API, alterações na lógica de autorização, fluxos de trabalho de agentes ou novas integrações de terceiros.
O que isso significa operacionalmente para as equipes de segurança é que a validação deve se tornar parte do pipeline de entrega, e não um evento isolado. Por sua vez, isso muda o foco de testar sistemas inteiros periodicamente para validar sistemas incrementalmente.
{{cta}}
A necessidade de velocidade
Por décadas, as organizações se concentraram em aumentar a produção: mais código, mais funcionalidades, mais aplicações. As equipes que entregam mais rápido ganham uma vantagem competitiva. Venables argumenta que o mesmo princípio se aplica cada vez mais à segurança.
Para realmente se beneficiar da velocidade do desenvolvimento de software moderno, a segurança deve se mover no mesmo ritmo. Organizações que conseguem detectar problemas, validar correções e responder a mudanças mais rapidamente ganham vantagem - não apenas sobre os atacantes, mas também sobre os concorrentes que atuam no mesmo espaço. Aqueles que não conseguem se verão cada vez mais operando com suposições desatualizadas sobre seus próprios sistemas.
Quando diferentes camadas de um sistema se movem em velocidades distintas, a segurança que reage tarde demais pode já estar operando no período de tempo errado, muito parecido com A Origem, onde ações tomadas tarde demais em uma camada têm pouco efeito sobre o que já está se desenrolando em outra.
