Um CISO de uma empresa multimilionária com quem falámos recentemente fez uma observação que me ficou na memória. A capacidade de segurança que mais valorizavam não era mais uma ferramenta ou estrutura de deteção. Era a rapidez.
Para eles, a rapidez na identificação de problemas, na validação de soluções e na resposta às mudanças era uma prioridade. Com tantos problemas para resolver, isso também sugere que o tempo está a tornar-se uma limitação operacional.
O especialista em cibersegurança Phil Venables sugeriu recentemente que o sucesso ou o fracasso dos programas de segurança dependerá cada vez mais da rapidez.
«A velocidade é tudo. Em particular, a forma como os defensores conseguem executar o seu ciclo OODA (observar, orientar-se, decidir, agir) mais rapidamente do que os atacantes conseguem adaptar-se».
No entanto, este não é mais um artigo do tipo «A IA está a causar esta confusão» — vamos encarar a realidade de forma mais abrangente. Na nossa pesquisa com 200 CISOs e 200 líderes de engenharia (incluindo CTOs), 76% das organizações implementam atualizações significativas semanalmente ou com maior frequência, e 39% fazem-no diariamente. As equipas de engenharia modernas implementam alterações de forma contínua.
Mas a validação da segurança não funciona a esse ritmo; apenas 21% validam a segurança em cada lançamento. Isto é mais do que um desfasamento, é uma falha estrutural.
Camadas de ritmo
Venables recorre ao modelo«Pace Layers», de Stewart Brand, para explicar como os sistemas complexos evoluem.
«As camadas rápidas trazem novidade e experimentação, enquanto as camadas lentas proporcionam estabilidade e memória.»
A entrega de software constitui a camada rápida, enquanto a governação e a validação constituem a camada lenta. Os ambientes de software modernos estão a fazer com que estas camadas se distanciem cada vez mais. As equipas de engenharia estão a acelerar o ritmo a que operam, enquanto a validação de segurança continua a funcionar em ciclos trimestrais ou anuais.
Os resultados de segurança só chegam depois de o sistema ter sido alterado; então, de que serve?
O resultado desta discrepância é inevitável; 85% afirmam que as conclusões de segurança já estão desatualizadas quando os relatórios chegam, pelo menos em alguns casos, sendo que quase metade (48%) afirma que isto acontece com muita frequência ou sempre.
Por outras palavras, quando os resultados dos testes são analisados, o sistema que descrevem já se alterou. Na prática, as equipas estão a tomar decisões de segurança com base num estado anterior do sistema. Mesmo pequenas alterações podem alterar a postura de segurança de um sistema. Um novo terminal, um ajuste na lógica de autorização ou uma dependência atualizada podem abrir vias de ataque totalmente novas. Os testes de penetração estão frequentemente a validar uma versão do sistema que já não existe.
Consequentemente, as correções sugeridas e os novos testes podem muito bem revelar problemas de segurança mais antigos, mas, à medida que o software evolui, as equipas começam a perder a confiança no sinal que o teste lhes forneceu, porque esse sinal chega tarde.
O resultado assemelha-se um pouco à mecânica temporal em camadas de «Inception»: diferentes partes do sistema funcionam agora a velocidades muito diferentes, e as ações realizadas demasiado tarde numa camada podem ter pouco efeito sobre o que já se está a desenrolar noutra.
A rapidez não deve comprometer a profundidade
Para as organizações que procuram melhorar a sua postura de segurança, a validação requer raciocínio, exploração, confirmação de vulnerabilidades e análise de fluxos de trabalho. Tem de ser minuciosa (mas isso já sabiam).
«A análise estática tem os seus limites. Se não for possível validar o problema na aplicação em execução, trata-se apenas de uma hipótese», afirma Philippe Dourrasov, responsável pela avaliação de segurança de IA na Aikido .
É por isso que, historicamente, os testes de segurança rigorosos têm demorado tempo.
Assim, o desafio não consiste em aumentar o número de testes, mas sim em manter a profundidade dos testes ofensivos reais, ao mesmo tempo que se opera a um ritmo muito mais acelerado.
No entanto, as limitações dos testes periódicos no que diz respeito à profundidade são evidentes. Na nossa investigação, 51 % dos inquiridos consideram que as vulnerabilidades mais complexas, tais como falhas lógicas, controlos de acesso defeituosos ou percursos de ataque em várias etapas, são sempre ou frequentemente ignoradas.
Isto não se deve a uma falta de conhecimentos especializados por parte das equipas de segurança. Em vez disso, deve-se ao facto de os pentesters e as equipas vermelhas se depararem com uma série de limitações: testes com prazos definidos, sistemas em expansão, complexidade crescente e interligação dos sistemas. Mas, no fundo, o dilema entre amplitude e profundidade é, na verdade, uma questão de tempo.
A validação deve seguir-se a uma mudança significativa
As organizações não ignoram o crescente desequilíbrio entre a velocidade de entrega e a validação da segurança. Muitas tentaram colmatar essa lacuna realizando mais testes de penetração ao longo do ano, efetuando análises contínuas ou comprimindo os processos manuais para se adaptarem a ciclos de lançamento mais curtos. Em teoria, estas abordagens aumentam a velocidade. Na prática, muitas vezes limitam-se a deslocar o risco para outro ponto.
A melhor mudança a adotar é alinhar a validação com a forma como o software realmente evolui. Isso não significa, na verdade, passar a testar tudo constantemente ou de forma contínua, mas sim permitir que a validação reaja quando ocorrem alterações significativas. Por outras palavras, validar as alterações que introduzem efetivamente riscos. O desafio reside no facto de a maioria das abordagens de teste existentes não conseguir operar com este nível de capacidade de resposta. Os testes de penetração tradicionais demoram dias ou semanas a agendar, executar e gerar relatórios. Mesmo os projetos mais rápidos não conseguem, realisticamente, acompanhar as alterações que ocorrem diariamente ou várias vezes ao dia. As alterações não são meramente cosméticas, mas sim coisas como novos pontos finais de API, alterações na lógica de autorização, fluxos de trabalho de agentes ou novas integrações de terceiros.
Na prática, isto significa que, para as equipas de segurança, a validação deve passar a fazer parte do fluxo de trabalho de implementação, e não ser um processo adicionado posteriormente. Por sua vez, isto faz com que o foco passe de testar sistemas inteiros periodicamente para validar os sistemas de forma incremental.
{{cta}}
A necessidade de velocidade
Há décadas que as organizações se têm concentrado em aumentar a produção: mais código, mais funcionalidades, mais aplicações. As equipas que lançam produtos mais rapidamente ganham uma vantagem competitiva. Venables defende que o mesmo princípio se aplica cada vez mais à segurança.
Para tirar verdadeiro partido da rapidez do desenvolvimento de software moderno, a segurança deve acompanhar esse ritmo. As organizações que conseguem detetar problemas, validar correções e responder às mudanças mais rapidamente ganham vantagem — não só sobre os atacantes, mas também sobre os concorrentes que atuam no mesmo setor. Aquelas que não o conseguem ver-se-ão, cada vez mais, a operar com pressupostos desatualizados sobre os seus próprios sistemas.
Quando as diferentes camadas de um sistema evoluem a ritmos diferentes, um sistema de segurança que reaja demasiado tarde pode já estar a operar num intervalo de tempo errado, tal como no filme «Inception», em que as ações tomadas demasiado tarde numa camada têm pouco efeito sobre o que já se está a desenrolar noutra.
