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