Eu gosto de etimologia. Às vezes entender a origem histórica das palavras traz insights para entendermos melhor um problema ou um cenário. Então, pesquisei sobre a palavra obsolescência e descobri algumas coisas interessantes:
Tem origem no latim. Deriva do termo obsolescere, que significa “tornar-se antiquado” ou “cair em desuso”. Uma junção de “ob-“, que significa “para fora” ou “contrário a”, e “solescere”, que vem de “olescere”, que quer dizer “começar a ser”.
Portanto, obsolescere refere-se ao processo de algo deixar de ser útil ou relevante com o passar do tempo. Descreve o estado ou processo pelo qual algo se torna obsoleto, isto é, ultrapassado ou fora de uso.
Quando falamos que “algo deixa de ser útil” e consideramos o contexto de segurança da informação, não dá para simplesmente jogar essa responsabilidade para Infraestrutura e sistemas, a rotina dessas áreas tem um foco em operação e entregas que corrigem falhas para o negócio e/ou implementações que trarão receita e esperar que essas áreas elimine a obsolescência, em tempo real, não seria uma boa estratégia.
A verdade é que a responsabilidade é nossa também. Líderes e gestores de segurança.
Segurança da informação já possui a responsabilidade da gestão de vulnerabilidade, que por sua vez olha todo o ambiente de tecnologia. Ao identificar obsolescência, o time de segurança poderia ter um indicador que suportasse a equipe de infra e sistemas no pedido de budget e na transformação digital. E mais: no racional de correção de vulnerabilidade em que é feita a análise de criticidade, exploit público, BIA, exposição do ativo, rede segmentada = Risco X, entre outros, caberia adicionar o critério “obsolescência”.
O custo em ter um ambiente obsoleto deve ser levado em consideração. Ambientes onde ficam os servidores e toda tecnologia que provê conectividade para a empresa precisam nascer apartados, pois mesmo que haja uma camada de patches virtuais, o risco ainda existe e toda materialização pode causar danos para a organização.
Olhando para o negócio, é crucial que a empresa não tenha a receita principal em cima de um ambiente legado. Com isso, cria-se riscos críticos, que precisam ser compartilhados com o board. Uma conversa sobre apetite ao risco é mais do que necessária. É esse entendimento que irá direcionar as ações do líder de segurança para desenhar um plano de gestão desses sistemas legados.
Além disso, é importante lembrar que existem várias regulamentações e normas que, direta ou indiretamente, abordam a obsolescência de ativos de TI, principalmente no contexto de segurança da informação, gerenciamento de riscos e conformidade. Isso precisa ser considerado. Porque, embora não exista uma lei específica focada exclusivamente na obsolescência de ativos de TI, várias normas e regulamentações relevantes trazem requisitos que abordam a gestão e substituição de ativos obsoletos.
Entre elas, ISO/IEC 27001; NIST; Sarbanes-Oxley Act (SOX); PCI DSS (Payment Card Industry Data Security Standard); ITIL (Information Technology Infrastructure Library); e Cobit (Control Objectives for Information and Related Technologies).
Sistemas legados são caros e entradas fáceis para invasores. Para encerrar minha discussão e incentivar você a olhar para a obsolescência no seu ambiente, cito um dado menos recente, mas curioso: em 2021, o relatório do Conselho Econômico Digital do Reino Unido indicou que quase 50% dos gastos de TI do governo do Reino Unido eram dedicados a “manter as luzes acesas” em sistemas legados desatualizados. Isso equivale a um gasto anual de 3 bilhões de dólares para aquele país.
Estreite sua parceria com Sistemas e Infraestrutura. E mantenha a área de risco envolvida no processo. Planeje uma apresentação ao board para um acompanhamento e compreensão clara do que está em jogo.
*Leonel Conti é Diretor de tecnologia da Redbelt Security
