Gestão de Vulnerabilidades na Rússia: FSTEC, BDU, Ordem nº 117 e Por Que Atualizações se Tornaram um Risco

A gestão de vulnerabilidades, um pilar fundamental da cibersegurança, apresenta nuances distintas em diferentes países. Embora a existência de hackers, erros humanos e falhas em softwares sejam universais, a abordagem russa para lidar com essas questões tem se moldado por um conjunto específico de requisitos e regulamentações. Leis federais como a nº 149-ФЗ “Sobre Informação, Tecnologias da Informação e Proteção da Informação”, a nº 187-ФЗ “Sobre a Segurança da Infraestrutura Crítica de Informação da Federação Russa” e a nº 152-ФЗ “Sobre Dados Pessoais” formam a base legal. Complementando estas leis, ordens do FSTEC (Serviço Federal de Controle Técnico e de Exportação) traduzem os mandatos legais em requisitos técnicos concretos. Entre elas, destacam-se a ordem nº 21 (medidas de segurança para dados pessoais), a ordem nº 31 (proteção de informações em sistemas de controle industrial), a ordem nº 235 (requisitos para sistemas de segurança em infraestruturas críticas) e a mais recente ordem nº 117, que substituiu a antiga ordem nº 17 e estabeleceu novos padrões para a proteção de informações em sistemas de informação estatais e de órgãos governamentais a partir de março de 2026. O não cumprimento destas regulamentações acarreta sanções crescentes, incluindo multas substanciais por vazamento de dados pessoais e até responsabilidade criminal, marcando o fim da era em que incidentes de segurança tinham custos financeiros e de reputação relativamente baixos.

Um ponto de virada significativo na abordagem russa à gestão de vulnerabilidades ocorreu em 2022. A publicação do documento "Critérios para Tomada de Decisão sobre Atualização de Software Crítico Não-Open Source" pelo NKCKI (Centro Nacional de Cibersegurança) em abril de 2022 refletiu uma mudança de paradigma. O que antes era considerado uma preocupação teórica – a possibilidade de injeção de código malicioso em atualizações de software – tornou-se uma realidade palpável. Desde fevereiro de 2022, usuários na Rússia podem ser bloqueados de receber atualizações com base em geolocalização, e o próprio processo de atualização, antes visto como um procedimento confiável, passou a ser considerado um potencial vetor de ataque. Exemplos notórios incluem o caso do pacote node-ipc, que deletava arquivos em sistemas russos e bielorrussos, e o event-source-polyfill, que exibia mensagens anti-guerra com base na configuração regional do sistema. Outros incidentes, como os envolvendo styled-components, nestjs-pino, colors.js/faker.js, e até mesmo bloqueios de serviços em nuvem como Cisco Meraki e Microsoft Azure devido a sanções, reforçaram a percepção de risco associada a atualizações e serviços externos. O documento do NKCKI, no entanto, oferece ressalvas importantes: o algoritmo é uma recomendação, atualizações devem ser testadas em ambientes controlados, e a prioridade na aplicação de patches pode ser adiada se a vulnerabilidade puder ser mitigada por outros meios de proteção. Para sistemas de controle industrial e sistemas operacionais móveis, o algoritmo não é recomendado. Algumas empresas, diante desse cenário, optaram por bloquear completamente as atualizações de sistemas internos, uma medida drástica cuja eficácia e adequação dependem da avaliação de risco de cada organização.

O cenário regulatório e de ameaças na Rússia continuou a evoluir rapidamente. Em outubro de 2022, o FSTEC introduziu a "Metodologia para Avaliação do Nível de Criticidade de Vulnerabilidades de Software e Hardware", que vincula a avaliação de risco à infraestrutura específica de cada empresa. Em maio de 2023, o FSTEC publicou um "Guia para Organização do Processo de Gestão de Vulnerabilidades", um manual abrangente que detalha as cinco etapas do processo (monitoramento, avaliação, determinação de métodos de remediação, remediação e controle), papéis dos participantes e sua relação com a metodologia de avaliação de criticidade. O ápice dessa evolução regulatória veio em abril de 2025 com a Ordem nº 117, que tornou a gestão de vulnerabilidades um requisito obrigatório com prazos específicos para sistemas de informação estatais: 24 horas para vulnerabilidades críticas, 7 dias para altas, e varreduras mensais. Além disso, novas vulnerabilidades não listadas no Banco de Dados de Vulnerabilidades (BDU) devem ser reportadas ao FSTEC em até 5 dias úteis, estabelecendo um SLA normativo. Em novembro de 2025, o FSTEC publicou a "Metodologia para Análise de Segurança de Sistemas de Informação", definindo os procedimentos de escaneamento externo e interno. O Decreto Presidencial nº 250 de maio de 2022 também impôs responsabilidade pessoal aos vice-líderes pela segurança da informação e proibiu o uso de ferramentas de segurança de países "hostis" a partir de 2025, forçando a substituição de ferramentas e impactando diretamente o processo de gestão de vulnerabilidades. A Rússia, enfrentando um volume sem precedentes de ciberataques, está em um estado de "ciberguerra", o que exige uma revisão constante e adaptativa das práticas de gestão de vulnerabilidades. A exploração de vulnerabilidades, juntamente com ataques DDoS e phishing, continua sendo um vetor de ataque proeminente. A necessidade de soluções nacionais e a substituição de importações tornaram-se imperativas, impulsionando o desenvolvimento de software doméstico. No entanto, a dependência de projetos de código aberto em muitas soluções russas levanta questões sobre a gestão de suas vulnerabilidades. A cultura de segurança e a adoção de práticas como bug bounty e divulgação responsável de vulnerabilidades estão em desenvolvimento, mas ainda enfrentam desafios, especialmente no que diz respeito à regulamentação da atividade de "white hat hackers" e à mentalidade de alguns fornecedores que acreditam que a certificação garante a ausência de vulnerabilidades.

A gestão de vulnerabilidades na Rússia é um campo dinâmico, moldado por um arcabouço legal em evolução, pressões geopolíticas e a necessidade de adaptação a um cenário de ameaças em constante mudança. A transição para a Ordem nº 117, com seus prazos rigorosos, representa um desafio significativo para as organizações, exigindo uma reavaliação das estratégias de patching e remediação. A mudança para o software doméstico, impulsionada pela política de substituição de importações, traz consigo a complexidade de gerenciar vulnerabilidades em sistemas que podem ter origens em projetos de código aberto, mas que foram adaptados e modificados. A FSTEC e outras agências reguladoras estão ativamente desenvolvendo metodologias e diretrizes para orientar as organizações nesse processo, enfatizando a importância de uma abordagem proativa e baseada em risco. A avaliação de criticidade de vulnerabilidades, agora vinculada à infraestrutura específica de cada organização, permite uma priorização mais eficaz dos esforços de remediação. A crescente conscientização sobre a importância da segurança em todo o ciclo de vida do desenvolvimento de software, refletida em normas como o GOST R 56939-2024, visa mitigar vulnerabilidades desde a fase de concepção. Apesar dos avanços, a cultura de divulgação responsável de vulnerabilidades e a regulamentação clara para "white hat hackers" ainda são áreas em desenvolvimento. A experiência russa na gestão de vulnerabilidades, embora marcada por desafios únicos, está se tornando um estudo de caso valioso sobre como as nações podem adaptar suas estruturas de cibersegurança em resposta a um ambiente global complexo e volátil. A adoção de práticas como bug bounty e a colaboração entre o setor público e privado são cruciais para fortalecer a resiliência cibernética do país.