Deixe-me ser claro desde o início: este não é um argumento contra a modernização. O progresso é importante. Novas capacidades são importantes. Segurança melhorias são importantes. O que é perigoso não é a atualização, mas a atualização por reflexo, na linha do tempo de outra pessoa, na esperança de que movimento seja igual a segurança.
Esta distinção é importante, porque os acontecimentos recentes mostraram o que acontece quando a escolha, a visibilidade e o julgamento desaparecem silenciosamente.
Cofundador e Diretor de Inovação da Origina.
Quando a Airbus suspendeu os jatos da família A320 devido a uma falha no controle de voo ligada à radiação solar, parecia um problema de nicho da aviação. Não foi. Foi um lembrete de que mesmo os setores construídos com base em engenharia de segurança e controle de mudanças obsessivos podem ser expostos a riscos de software enterrados em dependências críticas.
E se isso pode acontecer na aviação, com a sua redundância, certificação e disciplina, deveria dar a cada CIO um motivo para hesitar.
Vimos o mesmo padrão acontecer em outros lugares. A atualização CrowdStrike que inutilizou milhões de máquinas Windows. A interrupção do Cloudflare que se espalhou por grandes partes da Internet.
Em cada caso, uma mudança ou falha introduzida muito a montante desencadeou consequências imediatas a jusante. Mas a questão mais profunda não foi simplesmente a atualização. Foi a dependência e as suposições que vieram com ela.
Dependências ocultas e risco herdado
No caso da Airbus, as modernas aeronaves fly-by-wire dependem inerentemente de sistemas de software fortemente integrados. Quando esses sistemas encontravam um modo de falha contra o qual não estavam suficientemente protegidos, não havia uma simples saída de emergência operacional.
As aeronaves foram aterradas não porque os engenheiros foram descuidados, mas porque a segurança exigia certeza, e a certeza exigia mudanças antes que o voo pudesse ser retomado. Cloudflare conta uma história semelhante em escala de internet.
A Cloudflare executa uma operação robusta e fornece serviços críticos. Eles não são os vilões aqui. Mas uma grande parte da Internet depende agora de um pequeno número de redes partilhadas. infraestrutura provedores de DNSroteamento, segurança e disponibilidade.
As organizações que projetam seus serviços para depender inteiramente dessas plataformas herdam seus modos de falha. Quando um serviço principal falha, muitas vezes não há degradação normal, apenas uma parada muito brusca.
Esta é a realidade incômoda das áreas modernas de TI. A dependência não é gratuita. Quando a capacidade é terceirizada, o controle é diluído. A menos que os sistemas sejam concebidos intencionalmente tendo em mente a resiliência, a diversificação e o recurso, as organizações absorvem silenciosamente riscos que poderão não compreender totalmente.
Os líderes técnicos devem ser explícitos sobre aquilo de que dependem, como essas dependências falham e o que acontece quando isso acontece.
Perturbação que ultrapassa os limites da segurança
É aqui que a interrupção deixa de ser um inconveniente e se torna uma questão de segurança. Hospitais, serviços de emergência, serviços públicos e financeiro os mercados operam cada vez mais sobre camadas de software costuradas ao longo de décadas.
As integrações se acumulam, a responsabilidade se fragmenta e ninguém tem visibilidade total do impacto de ponta a ponta. Nesse ambiente, mesmo as mudanças “rotineiras” podem acarretar riscos reais.
Uma atualização do fornecedor ou uma interrupção externa pode atrasar o acesso aos registros dos pacientes, interromper os sistemas de despacho ou interromper os serviços dos quais as pessoas dependem em momentos importantes. A aviação assume que a mudança é perigosa até prova em contrário. Muitas propriedades digitais ainda presumem que a mudança é segura até que algo quebre.
No entanto, a narrativa dominante permanece inalterada: mantenha-se atualizado, aja rapidamente, confie no fornecedor.
Essa narrativa é reforçada por incentivos. Os fornecedores são recompensados pelo impulso da atualização. Modelos de suporte, receitas e estratégias de produtos dependem disso. O impacto operacional posterior, o novo teste de casos de segurança e a reciclagem do pessoal, cabe inteiramente ao cliente.
É aí que a ganância aparece. Não como malícia, mas como indiferença incorporada ao modelo de negócios. As pessoas que promovem a mudança não sentem as consequências quando esta corre mal.
A escolha, e não a obediência, deve impulsionar as atualizações
As atualizações são opcionais. Eles devem acontecer apenas quando uma organização deseja o novo recurso que oferece, e não porque um fornecedor declara uma versão “sem suporte”. O software não possui uma data de validade.
Existe uma crença perigosa incorporada nas práticas de segurança modernas de que, uma vez aplicado o patch mais recente, o risco foi resolvido e o trabalho está concluído. Na realidade, a aplicação de patches é apenas uma resposta possível ao risco e, às vezes, a resposta errada.
Um patch pode reduzir a exposição, mas também pode introduzir instabilidade, novas vulnerabilidades ou modos de falha totalmente novos.
A forma mais forte de defesa não é a velocidade, mas a compreensão. Saber a que você está exposto, como essa exposição se manifesta em seu ambiente e quais controles ou mitigações realmente reduzem o risco na prática. Isso requer evidências, não suposições. Muitas vezes, a aplicação de patches torna-se um ritual e não uma decisão.
A pressão regulatória pode mesmo reforçar involuntariamente este comportamento. As estruturas concebidas para melhorar a resiliência são por vezes reduzidas a “aplicar a correção mais recente e seguir em frente”. A conformidade se torna uma caixa de seleção.
A garantia torna-se performativa. Um sistema recentemente corrigido ainda pode ser mal compreendido, mal monitorado e mal defendido.
O risco deve ser gerenciado deliberadamente, utilizando controles que façam sentido para sua arquitetura e modelo operacional. Às vezes, isso inclui atualização. Muitas vezes significa isolar, compensar, endurecer ou monitoramento em vez de. A evidência, e não o medo ou a pressão do fornecedor, deve orientar a decisão.
Os CIOs podem não conseguir alterar os incentivos dos fornecedores, mas podem mudar a sua própria postura. A verdadeira atualização que a indústria precisa não é uma nova versão de software. É uma mudança de mentalidade, da conformidade para a compreensão, da velocidade para a substância e de “remendado” para “resiliente”. Porque o óleo de cobra e os sistemas críticos ainda não se misturam.
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 do setor de tecnologia atualmente. As opiniões expressas aqui são de responsabilidade do autor e não são necessariamente da TechRadarPro ou Future plc. Se você estiver interessado em contribuir saiba mais aqui: https://www.techradar.com/news/submit-your-story-to-techradar-pro