Portaria nº 16.516/STD, DE 6 de março de 2025
Aprova a Norma Complementar nº 11, que disciplina o Gerenciamento de Vulnerabilidades no âmbito da ANAC. |
O SUPERINTENDENTE DE TECNOLOGIA E TRANSFORMAÇÃO DIGITAL, no uso das atribuições que lhe confere o art. 39 do Regimento Interno, aprovado pela Resolução nº 381, de 14 de junho de 2016, e
Considerando os Decreto nºs 10.332, de 28 de abril de 2020, 10.046, de 9 de outubro de 2019, 10.222, de 5 de fevereiro de 2020, 9.573, de 22 de novembro 2018, e 9.637, de 26 de dezembro de 2018;
Considerando o Framework Control Objectives for Information and Related Technology - Cobit, conjunto de boas práticas a serem aplicadas à governança da TI, o Framework de segurança cibernética do CIS 8 e o Framework Information Technology Infrastructure Library -ITIL, v. 4, conjunto de boas práticas a serem aplicadas na infraestrutura, operação e gerenciamento de serviços de TI;
Considerando o Guia de Framework de Privacidade e Segurança da Informação - PPSI;
Considerando as Instruções Normativas nºs 01/GSI/PR, de 27 de maio de 2020, e 03/GSI/PR, de 28 de maio de 2021;
Considerando a Lei nº 13.709, de 14 de agosto de 2018, a Lei Geral de Proteção de Dados Pessoais - LGPD;
Considerando a Lei nº 12.527, de 18 de novembro de 2011, a Lei de Acesso à Informação - LAI;
Considerando as Normas ABNT NBR ISO/IEC 27001:2013 Tecnologia da informação - Técnicas de segurança - Sistemas de gestão de segurança da informação - Requisitos; ISO/IEC 27002:2013 Tecnologia da informação - Técnicas de segurança - Código de prática para a gestão da segurança da informação;
Considerando o National Institute of Standards and Technology (NIST);
Considerando a Portaria GSI/PR nº 93, de 18 de outubro de 2021;
Considerando o Guia de Gerenciamento de Vulnerabilidades da Secretaria de Governo Digital - SGD;
Considerando as boas práticas dispostas no NGINX.org, Office of the Chief Technology Officer - OCTO e Vulnerability Management Policy Template for CIS Control 7; e
Considerando o que consta do processo nº 00058.083121/2024-07,
RESOLVE:
Art. 1º Instituir, nos termos do Anexo, a Norma Complementar nº 11, que disciplina o Gerenciamento de Vulnerabilidades da Agência Nacional de Aviação Civil - ANAC.
Art. 2º Esta Portaria entra em vigor na data de sua publicação.
FERNANDO ANDRÉ COELHO MITKIEWICZ
ANEXO
NORMA COMPLEMENTAR Nº 11 - GERENCIAMENTO DE VULNERABILIDADES
CAPÍTULO I
DO OBJETIVO
Art. 1º Esta Norma Complementar tem como objetivo geral estabelecer princípios, diretrizes e procedimentos integrados com frameworks como COBIT, ISO/IEC 27002:2013 e o Programa de Privacidade e Segurança da Informação - PPSI da ANAC para a identificação, avaliação, documentação, classificação, tratamento, gestão, comunicação e remediação de vulnerabilidades.
Art. 2º São objetivos específicos desta Norma Complementar:
I - reduzir o número de vulnerabilidades;
II - diminuir o risco de comprometimento da segurança da informação;
III - melhorar a postura de segurança da informação da ANAC;
IV - aumentar a confiança dos stakeholders na segurança da informação da ANAC;
V - garantir a conformidade com regulamentações e normas de segurança;
VI - fortalecer a resiliência contra ameaças cibernéticas;
VII - promover uma cultura organizacional voltada para a segurança;
VIII - implementar medidas preventivas e corretivas eficazes;
IX - desenvolver continuamente capacidades de resposta a incidentes; e
X - adotar melhores práticas e tecnologias emergentes em segurança da informação.
CAPÍTULO II
DAS DEFINIÇÕES
Art. 3º Para os fins desta Norma Complementar, considera-se:
I - ameaça: conjunto de fatores externos com o potencial de causarem dano para um sistema ou organização;
II - ativos de informação: meios de armazenamento, transmissão e processamento da informação, equipamentos necessários a isso, sistemas utilizados para tal, locais onde se encontram esses meios, recursos humanos que a eles têm acesso e conhecimento ou dado que tem valor para um indivíduo ou organização;
III - banco de dados: coleção de dados inter-relacionados, representando informações sobre um domínio específico. São coleções organizadas de dados que se relacionam, a fim de criar algum sentido (informação) e de dar mais eficiência durante uma consulta ou a geração de informações ou conhecimento;
IV - CTIR GOV: Centro de Prevenção, Tratamento e Resposta a Incidentes Cibernéticos de Governo, subordinado ao Departamento de Segurança da Informação do Gabinete de Segurança Institucional da Presidência da República;
V - CVE (Common Vulnerabilities and Exposures): Vulnerabilidades e Exposições Comuns;
VI - CVSS (Common Vulnerability Scoring System): Sistema Comum de Pontuação de Vulnerabilidade;
VII - fraqueza: conjunto de fatores internos com o potencial de causarem dano para um sistema ou organização;
VIII - ID CVE: identificação para um CVE específico;
IX - gerenciamento de vulnerabilidade: processo cíclico e contínuo de identificação, avaliação, documentação, gestão, comunicação e remediação de vulnerabilidades;
X - gestão de mudanças nos aspectos relativos à segurança da informação: processo estruturado que visa aumentar a probabilidade de sucesso em mudanças, com mínimos impactos, e assegurar a disponibilidade, integridade, confidencialidade e autenticidade da informação;
XI - Gestor de Segurança da Informação: servidor responsável pelas ações de segurança da informação no âmbito da ANAC;
XII - host: um computador ou dispositivo de Tecnologia da Informação - TI (por exemplo, roteador, switch, gateway, firewall);
XIIX - log (Registro de Auditoria): registro de eventos relevantes em um dispositivo ou sistema computacional;
XIV - NTP (Network Time Protocol): Protocolo de Tempo para Redes;
XV - patch: uma parte de código adicional desenvolvido para resolver um problema ou falha em um software existente;
XVI - remediação: ato de corrigir uma vulnerabilidade ou eliminar uma ameaça;
XVII - risco: no sentido amplo, trata-se da possibilidade de ocorrência de um evento que pode impactar o cumprimento dos objetivos. Pode ser mensurado em termos de impacto e de probabilidade;
XVIII - risco de segurança da informação: risco potencial associado à exploração de uma ou mais vulnerabilidades de um ou mais ativos de informação, por parte de uma ou mais ameaças, com impacto negativo no negócio da organização;
XIX - teste de invasão: metodologia para testar a eficácia e a resiliência de ativos através da identificação e exploração de fraquezas nos controles de segurança e da simulação das ações e objetivos de um atacante;
XX - teste de penetração (pentest): também chamado de teste de intrusão, é fundamental para a análise de vulnerabilidades e consiste em testar todos os sistemas em busca de, além das já verificadas na fase anterior, vulnerabilidades conhecidas e disponibilizadas por especialistas ou pelas instituições detentoras dos softwares que estão sendo utilizados pelo órgão ou entidade;
XXI - vulnerabilidade: condição que, quando explorada por um criminoso cibernético, pode resultar em uma violação de segurança cibernética dos sistemas computacionais ou redes de computadores, e consiste na interseção de três fatores: suscetibilidade ou falha do sistema, acesso possível à falha e capacidade de explorar essa falha; e
XXII - análise de vulnerabilidades: verificação e exame técnico de vulnerabilidades, com o objetivo de determinar onde estão localizadas e como foram exploradas.
CAPÍTULO III
DO ESCOPO
Art. 4º Esta Norma Complementar aplica-se aos sistemas e ativos informacionais da ANAC.
Art. 5º Os serviços de tecnologia da informação - TI críticos da ANAC deverão ser formalmente estabelecidos pela Superintendência de Tecnologia e Transformação Digital - STD e aprovados pelo Comitê de Segurança da Informação e de Proteção de Dados Pessoais - CSIP.
Art. 6º Compete à Gerência Técnica de Segurança da Informação - GTSI/STD elaborar, manter e fazer cumprir esta Norma Complementar.
CAPÍTULO IV
DO PÚBLICO
Art. 7º Esta Norma Complementar se aplica:
I - a indivíduos responsáveis pela gestão e a indivíduos que utilizam qualquer Ativo de Informação da Rede de Computadores em nome da ANAC; e
II - a quaisquer provedores e entidades terceirizadas com acesso a informações, redes e aplicativos da ANAC.
CAPÍTULO V
DO PROCESSO DE FERENCIAMENTO DE VULNERABILIDADES - PGV
Art. 8º A ANAC deverá, por meio da STD, estabelecer, implementar, manter e aplicar um processo de Gerenciamento de Vulnerabilidades - PGV.
§ 1º A consistência e a eficácia do processo de que trata o caput deverão ser avaliadas por meio de métricas de gerenciamento de vulnerabilidades.
§ 2º Compete à STD definir as métricas de gerenciamento de vulnerabilidades, e suas medições devem ser apresentadas nas reuniões ordinárias do CSIP.
Art. 9º O PGV deverá:
I - incluir mecanismos para obter informações atualizadas sobre vulnerabilidades técnicas dos sistemas e ativos de informação, avaliar a exposição da organização a essas vulnerabilidades e implementar salvaguardas apropriadas para lidar com os riscos associados;
II - abranger o gerenciamento de vulnerabilidades de diversos ativos que suportam os serviços da organização, como ativos de rede, aplicações web, aplicativos móveis, sistemas operacionais, entre outros;
III - incluir atividades de suporte no processo, tais como métricas de relatório e treinamento para a implementação eficaz do PGV;
IV - definir as funções e responsabilidades das equipes para realizar todas as atividades de forma oportuna e eficaz na Agência; e
V - estar integrado com o processo geral de gestão de riscos da ANAC, garantindo que as vulnerabilidades identificadas sejam tratadas como parte do perfil de risco global.
Art. 10. Compete à STD implementar:
I - mecanismos para obter atualizações de software emitidas pelo fabricante ou fornecedor oficial, utilizando recursos autorizados como sites de fornecedores, fóruns e grupos de notícias, bancos de dados de gerenciamento de vulnerabilidades e ferramentas diversas para rastrear as vulnerabilidades mais recentes.
II - programa contínuo de avaliação de vulnerabilidades que inclua testes regulares de penetração e varreduras automatizadas de vulnerabilidades para identificar e corrigir proativamente possíveis falhas de segurança;
III - gestão de Patches, por meio de um cronograma rigoroso de aplicação de patches, garantindo que todos os sistemas e softwares sejam atualizados com as últimas correções de segurança de forma tempestiva;
IV - Plano de Resposta a Incidentes, integrado ao PGV, a fim de garantir que, em caso de detecção de uma vulnerabilidade explorada, a organização tenha um procedimento claro e eficiente para conter e remediar a ameaça;
V - análises de impacto detalhadas para cada vulnerabilidade identificada, avaliando o potencial impacto na confidencialidade, integridade e disponibilidade dos dados e serviços da organização; e
VI - programas contínuos de conscientização para todos os funcionários e colaboradores sobre a importância da segurança cibernética e as práticas recomendadas para evitar a introdução de vulnerabilidades.
Art. 11. Fica estabelecida a realização de revisões periódicas do PGV para garantir sua eficácia e conformidade com as normas de segurança cibernética da organização e da Administração Pública Federal.
Art. 12. A STD deverá manter documentação detalhada de todas as atividades relacionadas ao gerenciamento de vulnerabilidades, incluindo registros de vulnerabilidades identificadas, ações tomadas, e resultados das análises de impacto e mitigação.
CAPÍTULO VI
DO MAPEAMENTO DE ATIVOS DE INFORMAÇÃO
Art. 13. O escopo do processo de gerenciamento de vulnerabilidades e patches deverá contemplar o mapeamento de ativos de informação, a fim de determinar qual marca, modelo e versão de equipamento de hardware, sistemas operacionais, banco de dados, sistema, servidor web e aplicativos de software são usados na ANAC.
Parágrafo único. O mapeamento de ativos de informação deverá ser atualizado sempre que ocorrerem alterações significativas, a fim de garantir que os recursos informacionais estejam cobertos pelo processo de gerenciamento de vulnerabilidades da ANAC.
CAPÍTULO VII
DA DETECÇÃO DE VULNERABILIDADES
Art. 14. Compete à STD:
I - definir as funções e as responsabilidades das equipes para realizar atividades de detecção de vulnerabilidades;
II - configurar e ajustar as ferramentas adequadamente de acordo com o escopo avaliado;
III - avaliar e ajustar os tipos de varreduras e os tipos de teste para que sejam congruentes com o escopo avaliado;
IV - simulações regulares de ataques cibernéticos (pentest), com o objetivo de identificar vulnerabilidades que possam ser exploradas por atores maliciosos em cenários do mundo real;
V - revisões regulares de código fonte como parte do processo de detecção de vulnerabilidades, utilizando ferramentas de análise de segurança estática e dinâmica;
VI - implementar varreduras de vulnerabilidades nos ambientes de desenvolvimento e teste para identificar e corrigir problemas antes da implantação em produção;
VII - implementar um sistema automatizado para geração de relatórios de vulnerabilidades, garantindo que as informações sejam apresentadas de forma clara e acionável para as equipes responsáveis;
VIII - manter um banco de dados atualizado de vulnerabilidades conhecidas e garantir que todas as varreduras considerem essas informações para evitar a exposição a riscos já identificados;
IX - estabelecer um canal de comunicação eficiente entre as equipes de detecção de vulnerabilidades e as equipes de resposta a incidentes, assegurando uma ação rápida e coordenada quando uma vulnerabilidade é detectada;
X - após a detecção de vulnerabilidades, realizar uma revisão detalhada para avaliar a eficácia dos processos e ferramentas utilizadas, identificando áreas de melhoria para futuras varreduras;
XI - manter documentação detalhada de todas as atividades de detecção de vulnerabilidades, incluindo metodologias utilizadas, resultados obtidos e ações de mitigação implementadas, para garantir a rastreabilidade e conformidade com auditorias.
Art. 15. A frequência de testes de segurança deverá considerar os requisitos legais, regulamentares e contratuais que a ANAC deverá cumprir e os riscos associados aos ativos avaliados.
Art. 16. As varreduras de vulnerabilidades na rede corporativa deverão ser realizadas por períodos determinados ou após alteração significativa na rede, por equipe interna ou por terceiro ou uma combinação de ambos.
Art. 17. Os testes de segurança deverão utilizar o feed de vulnerabilidade mais recente, de forma a evitar que determinadas vulnerabilidades não sejam detectadas.
§ 1º Para cada teste, será verificada a integridade da ferramenta utilizada e se ela varreu corretamente os ativos analisados e se existem exceções de vulnerabilidades.
§ 2º As ferramentas utilizadas deverão ser ajustadas continuamente, de forma a evitar que varreduras feitas por ferramentas distintas gerem resultados distintos.
§ 3º A detecção manual de vulnerabilidades deverá ser considerada como complemento à detecção automática de vulnerabilidades.
Art. 18. O teste de invasão ou o teste de penetração (pentest) deverá ser realizado conforme critério de necessidade da Agência, utilizando especialistas qualificados externos como parte de um exercício planejado, que incluirá o escopo da avaliação, os métodos de uso e os requisitos operacionais, a fim de fornecer as informações mais precisas e relevantes sobre as vulnerabilidades atuais, sem comprometer o funcionamento normal do órgão.
Art. 19. A integridade do resultado de detecção de vulnerabilidades deverá ser avaliada antes de sua comunicação, de forma a evitar inconsistências, contradições ou resultados incompletos.
CAPÍTULO VIII
DA ELABORAÇÃO E MANUTENÇÃO DOS RELATÓRIOS
Art. 20. A equipe de gerenciamento de vulnerabilidades deverá elaborar relatórios após cada ciclo de detecção, a fim de auxiliar a ANAC a entender e mensurar as vulnerabilidades existentes.
§ 1º O relatório de que trata o caput deverá ser customizável, de acordo com as necessidades específicas de diferentes partes interessadas.
§ 2º O relatório de que trata o caput deverá ser classificado, durante e após a sua elaboração, de acordo com a sensibilidade das informações presentes.
§ 3º Todas as versões do relatório de que trata o caput deverão ser remetidas ao gerente técnico de segurança de informação.
§ 4º Os relatórios de que trata o caput deverão ser integrados com outros relatórios de segurança da informação da organização, fornecendo uma visão holística do estado de segurança cibernética da entidade.
§ 5º Os relatórios de que trata o caput vulnerabilidades deverão enviados para o CSIP.
Art. 21. Os resultados da varredura deverão ser analisados pela GTSI com o dispositivo ou gerenciador de rede, a fim de identificar e eliminar possíveis falsos positivos.
Art. 22. Os Grupos de ativos de informação deverão ser determinados por tipo de ambiente, por tipo de sistema, por ID CVE ou por tipo de vulnerabilidade.
Art. 23. A equipe de gerenciamento de vulnerabilidades deverá adotar métricas para os relatórios de vulnerabilidade e determinar o valor percentual dos ativos de informação vulneráveis por gravidade e CVSS.
Art. 24. A quantidade e a porcentagem de novas vulnerabilidades deverão ser monitoradas por: severidade, grupos funcionais, tipo de ambiente; tipo de sistema, autoridade de numeração CVE e tipo de vulnerabilidade.
Art. 25. O CSIP deverá estabelecer um processo formal de revisão e aprovação dos relatórios, garantindo que todas as partes interessadas relevantes estejam envolvidas na validação das informações.
Art. 26. Compete à STD:
I - implementar soluções automatizadas para a geração de relatórios, garantindo que os dados sejam atualizados em tempo real e reduzindo a carga de trabalho manual da equipe de gerenciamento de vulnerabilidades; e
II - estabelecer procedimentos seguros para a distribuição dos relatórios, incluindo criptografia e controles de acesso, para proteger as informações sensíveis contra acessos não autorizados.
CAPÍTULO IX
DO BANCO DE DADOS DE VULNERABILIDADES
Art. 27. A STD deverá manter um banco de dados de vulnerabilidades coletadas de várias fontes.
§ 1º As informações armazenadas de que trata o caput deverão ser analisadas regularmente para identificar tendências e padrões visando a tomada de medidas proativas para evitar futuras vulnerabilidades.
§ 2º O banco de dados poderá incluir informações de vulnerabilidade, análise de vulnerabilidade para priorização e plano de correção de vulnerabilidade.
Art. 28. O banco de dados de vulnerabilidades deverá:
I - ser atualizado regularmente com as informações mais recentes e as novas vulnerabilidades deverão ser adicionadas ao banco de dados tão logo forem descobertas; e
II - incluir informações sobre a exploração ativa de vulnerabilidades, ajudando a priorizar a correção de vulnerabilidades que estão sendo ativamente exploradas por atacantes.
Art. 29. Compete à STD:
I - classificar e categorizar as vulnerabilidades no banco de dados por tipo, severidade, CVSS, impacto potencial e urgência de correção, facilitando a priorização e a tomada de decisão;
II - manter um registro histórico das ações de correção implementadas para cada vulnerabilidade, permitindo rastrear a eficácia das medidas de mitigação e facilitar auditorias futuras;
III - implementar notificações automatizadas para alertar as equipes responsáveis sobre novas vulnerabilidades adicionadas ao banco de dados, especialmente aquelas classificadas como críticas ou de alta severidade;
IV - estabelecer controles de acesso ao banco de dados de vulnerabilidades, garantindo que apenas pessoal autorizado possa visualizar e modificar as informações sensíveis;
V - realizar verificações regulares de integridade do banco de dados para assegurar que as informações armazenadas sejam precisas e não tenham sido comprometidas.
VI - permitir a geração de relatórios personalizados a partir do banco de dados, atendendo às necessidades específicas de diferentes partes interessadas, como gerentes de segurança, auditores e equipes técnicas;
VII - utilizar feeds de vulnerabilidades em tempo real de fontes confiáveis para garantir que o banco de dados seja constantemente atualizado com as últimas ameaças e exposições;
VIII - garantir que o banco de dados de vulnerabilidades seja compatível com padrões e frameworks de segurança reconhecidos internacionalmente, como CVE (Common Vulnerabilities and Exposures) e NVD (National Vulnerability Database);
IX - implementar um plano de backup regular para o banco de dados de vulnerabilidades, assegurando que as informações possam ser recuperadas em caso de falha ou comprometimento do sistema; e
X - manter documentação detalhada sobre os procedimentos de atualização, manutenção e uso do banco de dados de vulnerabilidades, garantindo a consistência e continuidade do processo.
CAPÍTULO X
DA PRIORIZAÇÃO DE VULNERABILIDADES
Art. 30. O tratamento de vulnerabilidades deverá ser priorizado com base:
I - na classificação de risco e criticidade;
II - no tempo esperado para correção;
III - no grau de risco;
IV - no impacto em caso de exploração; e
V - no valor que o ativo ou host impactado tem para o negócio da ANAC.
Art. 31. As vulnerabilidades deverão ser tratadas de acordo com o seu nível de severidade e nos prazos estipulados na tabela abaixo:
Nível de severidade |
Prazo de correção |
Descrição do risco |
Muito Crítico |
Até 2 (dois) dias |
Condição totalmente inaceitável quando medidas imediatas devem ser tomadas para eliminar a materialização do risco e mitigar perigos e impactos. |
Crítico |
Até 30 (trinta) dias |
Pessoas mal-intencionadas podem facilmente obter o controle do host, o que pode comprometer toda a sua rede. As vulnerabilidades incluem acesso de leitura e gravação a arquivos, execução remota de comandos e backdoors. |
Alto |
Até 45 (quarenta e cinco) dias |
Pessoas mal-intencionadas podem obter o controle do host ou coletar informações altamente confidenciais, incluindo acesso de "leitura" ao arquivo, backdoors em potencial ou uma lista de todas as contas de usuário no host. |
Médio |
Até 90 (noventa) dias |
Pessoas mal-intencionadas podem obter acesso às configurações de segurança no host, o que pode levar ao acesso a arquivos e à divulgação de conteúdo de arquivos, navegação em diretórios, ataques de negação de serviço e uso não autorizado de serviços. |
Baixo |
Até 120 (cento e vinte) dias |
Pessoas mal-intencionadas podem coletar informações confidenciais do host, como versões de software instaladas, que podem revelar vulnerabilidades conhecidas. |
Muito baixo |
Até 180)cento e oitenta) dias |
Pessoas mal-intencionadas podem coletar informações sobre o host por meio de portas ou serviços abertos, o que pode levar à divulgação de outras vulnerabilidades. |
Art. 32. A STD deverá revisar periodicamente a priorização das vulnerabilidades para garantir que todas as avaliações de risco estejam atualizadas e reflitam o ambiente atual de ameaças.
Parágrafo único. A priorização de que trata o caput deverá incluir os stakeholders chave, a fim de assegurar que todos os aspectos críticos do negócio serão considerados.
CAPÍTULO XI
DA REMEDIAÇÃO DE VULNERABILIDADES
Art. 33. Quando uma vulnerabilidade não for possível de ser corrigida, pelos motivos listados nos incisos a seguir, métodos alternativos para reduzir o risco deverão ser aplicados.
I - ausência de patch de correção;
II - sistema ou aplicação sem suporte;
III - impacto operacional;
IV - compatibilidade;
V - custo;
VI - prioridade de recursos;
VII - avaliação de risco;
VIII - dependências de terceiros;
IX - complexidade técnica; e
X - regulamentação e conformidade.
Parágrafo único. Os métodos alternativos de que trata o caput incluem a implementação de medidas compensatórias e a atualização do risco identificado.
Art. 34. A STD deverá definir um processo claro de aceitação de risco que contemple a documentação da justificativa para a não correção da vulnerabilidade, a avaliação do impacto e a aprovação pela gestão de segurança da informação.
Art. 35. As medidas compensatórias deverão ser revisadas regularmente, a fim de garantir que continuem a ser eficazes e para avaliar a possibilidade de correção futura das vulnerabilidades.
CAPÍTULO XII
DA CORREÇÃO DE VULNERABILIDADES
Art. 36. Os testes concluídos com falha deverão ser examinados novamente até que sua execução seja concluída com êxito. Caso não seja possível, deve-se avaliar se a vulnerabilidade será incluída na lista de exceções por pessoal autorizado, com base no processo de aceitação de risco.
Art. 37. Quando as vulnerabilidades não puderem ser corrigidas dentro do prazo estabelecido no art. 31, a equipe de gerenciamento de vulnerabilidades deverá enviar uma “solicitação de renúncia” à GTSI.
Parágrafo único. A solicitação de que trata o caput deverá conter as seguintes informações:
I - detalhes do sistema ou ativo;
II - descrição detalhada da vulnerabilidade;
III - avaliação de risco que justifique a não correção imediata;
IV - justificativa clara pela qual a correção não pode ser realizada no prazo estabelecido;
V - detalhes dos controles existentes (se houver);
VI - novo prazo de correção; e
VII - plano de ação da remediação (obedecendo o novo prazo de correção).
Art. 38. Compete à STD:
I - aceitar ou rejeitar a solicitação de renúncia, com base na avaliação de risco apresentada. Se a solicitação de renúncia for aceita, a vulnerabilidade deve ser monitorada continuamente, pautado pelo plano de ação apresentado devendo ser corrigida assim que possível;
II - monitorar os alertas de vulnerabilidades, as correções de patches e as ameaças emergentes que correspondam aos recursos informacionais relacionados no inventário de sistema e ativos de informação deverão ser monitorados;
III - implementar um sistema de acompanhamento contínuo do status das vulnerabilidades identificadas, garantindo que cada etapa do processo de correção seja registrada e monitorada até a resolução final;
IV - incluir no processo de priorização e correção a coordenação com fornecedores e terceiros relevantes, garantindo que todas as partes envolvidas sejam notificadas e colaborem na mitigação das vulnerabilidades identificadas;
V - após a aplicação de correções, realizar testes para verificar a eficácia das medidas implementadas e garantir que a vulnerabilidade tenha sido devidamente resolvida sem introduzir novas falhas;
VI - estabelecer um canal de comunicação eficaz para informar todas as partes interessadas dentro da organização sobre o status das vulnerabilidades e as ações de correção em andamento, promovendo a transparência e a colaboração;
VII - manter uma documentação detalhada de todo o processo de priorização e correção, incluindo justificativas para decisões tomadas, ações executadas e resultados obtidos, garantindo a rastreabilidade e a conformidade com auditorias;
VIII - estabelecer um processo de feedback regular para avaliar a eficácia do processo de priorização e correção de vulnerabilidades, identificando áreas de melhoria e ajustando procedimentos conforme necessário;
IX - desenvolver planos de contingência para lidar com situações em que as correções não possam ser aplicadas imediatamente, incluindo medidas temporárias de mitigação para reduzir o risco até que a vulnerabilidade possa ser corrigida;
X - realizar avaliações de impacto após a correção de vulnerabilidades para entender os efeitos das medidas implementadas e ajustar estratégias futuras de gerenciamento de vulnerabilidades.
CAPÍTULO XIII
DAS EXCEÇÕES
Art. 39. Os ativos de informação da ANAC não contemplados por esta Norma Complementar em função de dificuldades técnicas, obrigações contratuais, normativas ou outras razões legítimas deverão ser documentados e aprovados por meio de um processo de gerenciamento de exceções da ANAC.
§ 1º O processo de aprovação das exceções deverá envolver múltiplos níveis de autoridade dentro da organização, incluindo pelo menos a equipe de gerenciamento de vulnerabilidades, a STD e o CSIP, para assegurar uma revisão completa e imparcial.
§ 2º Qualquer incidente de segurança relacionado a um ativo de informação coberto por uma exceção deverá desencadear uma reavaliação imediata da exceção e das medidas de mitigação aplicadas.
Art. 40 A lista de exceções de ativos de informação deve ter validade de 1 (um) ano, devendo ser revisada após esse período.
CAPÍTULO XVI
DOS REGISTROS DE LOGS
Art. 41. Compete à STD identificar quais eventos dos ativos de informação deverão ser registrados, com base nos requisitos regulatórios, nas melhores práticas e nos objetivos da ANAC.
Art. 42. Ativos, físicos ou virtuais, como servidores e recursos de rede, deverão recuperar informações baseadas em tempo de uma única fonte de tempo de referência (servidor NTP) regularmente para que os relógios de registro sejam consistentes.
Art. 43. As configurações referentes a ativos de informação deverão incluir configurações de log para registrar ações que possam afetar ou que sejam relevantes para a segurança da informação.
Art. 44. O procedimento para análise de logs deverá ser definido, com ferramentas de análise e correlação, para identificar possíveis ameaças e vulnerabilidades.
Art. 45. Os arquivos de registro (logs) deverão ser protegidos contra adulteração e acesso não autorizado ou exfiltração.
Art. 46. Registros de logs dos sistemas e ativos informacionais classificados como críticos deverão ser mantidos por pelo menos 90 (noventa) dias, tempo suficiente para cumprir os requisitos regulatórios e permitir a detecção de ameaças passadas.
Art. 47. Os registros de logs para identificar quaisquer tentativas de exploração de vulnerabilidades deverão ser monitorados continuamente.
Art. 48. Os registros de log deverão ser excluídos de forma segura, garantindo que os registros sejam completamente apagados sem deixar vestígios ou dados remanescentes.
Art. 49. Uma revisão dos arquivos de registro (logs) deverá ser conduzida, pelo menos, anualmente.
CAPÍTULO XV
COMUNICAÇÃO DA OCORRÊNCIA DE VULNERABILIDADES E CORREÇÕES
Art. 50. As vulnerabilidades e respectivas informações de correção deverão ser informadas aos usuários afetados, incluindo, mas não se limitando a:
I - administradores de sistema;
II - proprietários de sistema; e
III - usuários finais.
Art. 51. As correções bem-sucedidas de vulnerabilidades poderão ser testadas por meio de verificação de vulnerabilidades de rede e host, verificação de logs de patches, testes de invasão/penetração (Pentest) e verificação das definições de configuração.
CAPÍTULO XVIII
IMPLEMENTAÇÃO E VERIFICAÇÃO DAS CORREÇÕES DE VULNERABILIDADES
Art. 52. As correções de vulnerabilidades deverão ser verificadas para garantir que não haja novas vulnerabilidades introduzidas.
§ 1º As correções de que trata o caput poderão ser realizadas por meio de testes de penetração, testes de vulnerabilidade e análise de logs.
§ 2º Somente correções de vulnerabilidades efetivamente testadas e aprovadas deverão ser implantadas em produção.
Art. 53. Instalações de patches de segurança e ajustes de configuração recomendadas para mitigar as vulnerabilidades deverão ser enviadas por meio do processo de gestão de mudanças para que os controles apropriados sejam implementados para teste, avaliação de riscos e reparação.
CAPÍTULO XIX
DOS SERVIÇOS EM NUVEM OU DE TERCEIROS
Art. 54. A STD deverá definir e acordar as responsabilidades do provedor de serviços em nuvem pública com o cliente do serviço em nuvem.
Parágrafo único. Terceiros deverão cumprir os requisitos do PGV e, sempre que possível, essa obrigação e outras responsabilidades que envolvam o gerenciamento de vulnerabilidades deverão ser incluídas em contratos com terceiros.
CAPÍTULO XX
DAS DISPOSIÇÕES FINAIS
Art. 55. Esta Norma Complementar deverá ser revisada e atualizada a cada 2 (dois) anos ou sempre que ocorrerem eventos ou fatos relevantes que exijam sua imediata alteração.
Art. 56. O cumprimento desta Norma Complementar será avaliado anualmente.
Art. 57. Fica a STD autorizada a elaborar procedimentos específicos para a operacionalização dos controles estabelecidos nesta Norma Complementar.
Art. 58. Os casos omissos serão resolvidos pela STD.
__________________________________________________________________________
Publicada em 19 de março de 2025 no Boletim de Pessoal e Serviço - BPS v.20, nº 11, de 17 a 21 de março de 2025