A aplicação de patches não é uma estratégia de segurança; é uma decisão de gestão de mudanças com implicações financeiras, operacionais e de risco.
Os CIOs já sabem que as ameaças atuais avançam rapidamente. E esse desafio é agravado pelo facto de os atacantes utilizarem cada vez mais a automatização para identificar e explorar vulnerabilidades.
Vice-presidente de segurança cibernética e produtos da Spinnaker Support.
Grande parte do trabalho anterior, que antes levava tempo, agora acontece quase que instantaneamente. Quando uma nova vulnerabilidade se torna pública, os invasores a validam em ativos de software reais em dias, às vezes horas, usando técnicas de descoberta automatizadas e baseadas em IA que revelam explorações muito mais rápido do que os testes humanos jamais conseguiriam.
Isso comprime a janela na qual as organizações podem responder, mesmo quando executam processos disciplinados de aplicação de patches.
Os sistemas empresariais, no entanto, operam em um cronograma diferente. As plataformas ERP evoluem lentamente porque estão no centro dos processos financeiros, operacionais e da cadeia de abastecimento. Mesmo pequenas atualizações podem afetar integrações, lógica de relatório ou extensões personalizadas criadas ao longo de muitos anos. Por definição, esses sistemas só mudam quando é seguro fazê-lo.
Então, o que acontece quando os mecanismos de ataque aceleram, mas os mecanismos de mudança empresarial permanecem cautelosos e lentos? Como resultado, a lacuna entre a forma como o risco é criado e como é mitigado está a aumentar.
Os invasores atacam vulnerabilidades acessíveis em identidade, configuração e arquitetura, enquanto os patches abordam apenas um subconjunto de falhas conhecidas no código do fornecedor. Essa incompatibilidade significa que a exposição é mantida independentemente de quantas atualizações são aplicadas.
Um patch remove uma vulnerabilidade específica, mas os invasores exploram vulnerabilidades subjacentes que podem ter muitas vulnerabilidades, portanto, corrigir um CVE raramente fecha todo o caminho do ataque.
Problema de segurança baseado em patch
A aplicação de patches tornou-se a resposta padrão aos riscos de segurança, mas em ambientes ERP é uma ferramenta crítica e frágil. Esses sistemas são construídos em torno de código personalizado, módulos legados e integrações fortemente acopladas que não refletem um modelo padrão de fornecedor, tornando as atualizações inerentemente imprevisíveis.
À medida que a pressão para corrigir mais rapidamente aumentou, muitas organizações foram forçadas a aceitar mais riscos operacionais em troca da segurança percebida. Os sistemas quebram, as interfaces falham e os fluxos de trabalho críticos são interrompidos, mesmo quando grandes partes do ambiente permanecem sem correção ou sem suporte.
As plataformas ERP não foram projetadas para se moverem na velocidade da descoberta moderna de vulnerabilidades, mas a segurança do patch-first pressupõe que isso seja necessário.
Por que os CIOs estão adaptando a defesa detalhada para estruturas de aplicativos
Muitos CIOs estão revisando a defesa em profundidade e reinterpretando-a para ambientes de aplicativos complexos, em vez de redes ou endpoints. Isso não ocorre porque eles queiram abandonar os patches, mas porque os patches se tornaram uma decisão de alto risco e responsabilidade.
Se uma atualização rápida danificar um processo central do ERP, o fornecedor absorverá grande parte da culpa. Se uma vulnerabilidade conhecida for explorada antes da aplicação de um patch, a falha é propriedade da organização. Este desequilíbrio torna cada vez mais perigoso confiar num único controlo.
A defesa em profundidade proporciona uma forma de difundir este risco. Em vez de depender apenas de patches, garante que a organização tenha mais de uma linha de proteção durante longos períodos quando as atualizações não puderem ser aplicadas ou ainda não existirem.
Na prática, trata-se menos de empilhar ferramentas e mais de moldar o ambiente para que um único controle não funcione como uma solução mágica.
Os modelos Zero Trust pressupõem quebra, exigem verificação constante e minimizam o raio da explosão. Patching desempenha um grande papel, mas sua contribuição é limitada:
– Corrige o bug identificado de ontem, não o desconhecido de hoje ou o dia zero de amanhã.
– Não faz nada para melhorar a governança de identidade, segmentação, força de autenticação ou capacidades de detecção
– Requer conformidade com os termos e práticas de divulgação de um único fornecedor
O Defense in Depth, por outro lado, oferece suporte ao Zero Trust adicionando camadas de compensação: configurações reforçadas, redução de privilégios, controles de movimento lateral, monitoramento e mitigações rápidas que são independentes dos ciclos de patches do fornecedor.
Para sistemas ERP, isso começa com uma base de configuração mais forte, entendendo como as vulnerabilidades atuam no estado da organização e processos de resposta que refletem como o sistema realmente funciona.
Ao contrário dos patches, que criam uma redução limitada e única do risco, esses controles aumentam com o tempo, reduzindo classes inteiras de ataques.
Endurecimento das partes controladas pela organização
Proteger a configuração é uma das primeiras etapas mais eficazes. Muitas vulnerabilidades vêm de configurações ou privilégios que nunca foram totalmente revisados ou de interfaces que são deixadas ativas por hábito e não por necessidade.
Estas são fraquezas estruturais na forma como o sistema funciona, e não bugs no código do fornecedor, e nunca serão eliminadas por patches. É também uma das poucas áreas onde os CIOs têm agência plena.
A proteção não depende de ciclos de lançamento ou roteiros de desenvolvimento e pode ser melhorada de forma incremental, reduzindo imediatamente o risco.
Entenda os pontos fracos de seus ativos
A visibilidade forma a próxima camada. Um comunicado do fornecedor pode descrever como um bug funciona em um produto padrão, mas poucas organizações operam algo parecido com isso. Fluxos de trabalho personalizados, módulos mais antigos e extensões de terceiros afetam a forma como uma vulnerabilidade é realmente exposta.
Portanto, os CIOs precisam de análises baseadas em seus ambientes. Saber se uma vulnerabilidade é realmente acessível, como o código personalizado altera sua capacidade de endereçamento e se os controles existentes atenuam o risco ajuda as equipes a se concentrarem no que é mais importante, em vez de reagir a pontuações de gravidade que podem não se aplicar ao seu legado.
Capacidades responsivas que correspondem ao funcionamento da organização
Quando algo dá errado, a forma como sua organização responde é o teste definitivo de resiliência. As equipes precisam entender quais processos elas afetam, como os dados se movem pelo ambiente e onde o isolamento pode ocorrer sem interrupções desnecessárias. Um modelo de segurança em camadas oferece suporte a isso.
Uma linha de base rígida limita a exposição, a visibilidade aprimorada reduz o tempo de investigação e um processo de resposta projetado em torno da arquitetura da organização permite decisões mais rápidas e confiantes.
Governança, conformidade e controle do roteiro
Os reguladores e os auditores esperam provas de supervisão contínua, em vez de simplesmente garantir que os sistemas estão actualizados. Estruturas como a ISO27001 tornam isso explícito, tratando os patches como um pequeno elemento de proteção e governança, juntamente com identidade, detecção, resposta e recuperação.
Entre as principais atualizações que eles desejam ver está como o risco é gerenciado e mantido quando os roteiros dos fornecedores não estão alinhados com as prioridades de negócios.
Para muitos CIOs, a questão subjacente é o controle. Eles precisam de flexibilidade para decidir quando uma atualização é apropriada, como sequenciar as alterações e como demonstrar conformidade sem colocá-los em fusos horários descontínuos.
A camada de visão de defesa em profundidade apoia o fortalecimento de medidas que a organização pode adaptar diretamente.
Uma base mais sólida para a resiliência a longo prazo
A resiliência é cada vez mais algo incorporado ao ambiente, e não apenas fornecido por meio de patches. Os CIOs ainda dependem de soluções de fornecedores, mas complementam-nas com controles que possuem: opções de configuração, insights detalhados sobre imóveis e processos responsivos adaptados ao modo como seus sistemas funcionam.
Construindo confiança através da independência
Esta mudança para a independência não significa abandonar o seu fornecedor, mas significa fortalecer as camadas de proteção que acompanham o suporte do fornecedor. Em muitos ambientes, isso significa ser realista sobre quando os patches estão atrasados, indisponíveis ou não estão mais em produção, mesmo em sistemas tradicionais ou altamente personalizados.
Muitas organizações, portanto, trabalham com parceiros de suporte terceirizados que oferecem uma abordagem específica de plataforma e fornecem garantia, experiência e rastreamento em todas essas propriedades. Esses relacionamentos oferecem aos CIOs oportunidades de manter a conformidade, gerenciar riscos e manter os sistemas estáveis sem depender de uma única via de proteção.
O produto final é um modelo operacional mais seguro e econômico. As ameaças podem ocorrer rapidamente e os cronogramas dos fornecedores podem nem sempre estar alinhados com os seus, mas sua organização não está mais definida.
Em vez disso, a segurança se alinha à sua realidade operacional com base na continuidade, no controle e na liberdade de tomar decisões dentro do seu cronograma.
Apresentamos o melhor curso online de segurança cibernética.
Este artigo foi produzido como parte do canal Expert Insights da TechRadarPro, onde apresentamos as melhores e mais brilhantes mentes da indústria de tecnologia atualmente. As opiniões expressas aqui são de responsabilidade do autor e não necessariamente da TechRadarPro ou Future plc. Caso tenha interesse em participar, mais informações aqui:
