PORTARIA SE/MTUR Nº 4, DE 24 DE NOVEMBRO DE 2025

Aprova a Política de Gerenciamento de Vulnerabilidades no âmbito do Ministério do Turismo.

A SECRETÁRIA-EXECUTIVA, no uso das atribuições que lhe conferem o art. 6°, III, do Decreto n° 7.579, de 11 de outubro de 2011, e o art. 13, IV, ‘a”, do Anexo I, aprovado pelo Decreto nº 11.416, de 16 de fevereiro de 2023, combinado com o art. 8° da Portaria SGD/MGI n° 852, de 28 de março de 2023, e o que consta do Processo nº 72031.006111/2023-78,

RESOLVE:

Art. 1º Aprovar, na forma dos Anexos desta portaria, a Política de Gerenciamento de Vulnerabilidades - PGV no âmbito do Ministério do Turismo.

Art. 2º Esta Portaria entra em vigor na data de sua publicação.

ANA CARLA MACHADO LOPES

Este conteúdo não substitui o publicado no Boletim de Serviços, de 25 de novembro de 2025.

ANEXO I

POLÍTICA DE GERENCIAMENTO DE VULNERABILIDADES

CAPÍTULO I

DISPOSIÇÕES GERAIS

Seção I

Do propósito

Art. 1º Esta Portaria tem como objetivo estabelecer regras relacionadas às atividades de identificação, avaliação, documentação, gestão, comunicação e remediação de vulnerabilidades.

Seção II

Do escopo

Art. 2º As disposições desta Portaria se aplicam aos sistemas e aos ativos informacionais do Ministério do Turismo e são de observância de todos aqueles que tenham acesso e/ou utilizem ativos informacionais.

Art. 3º Ficam estabelecidos como serviços e sistemas críticos do órgão:

I - todos os sistemas informatizados do Ministério do Turismo que atendam indiretamente aos cidadãos;

II - todos os painéis gerenciais com informações disponibilizadas diretamente aos cidadãos;

III - todos os ativos ou serviços de TI onde sejam armazenados, de forma permanente ou em backup, as informações e os dados produzidos pelo Ministério do Turismo;

IV - todos os ativos ou serviços de TI cuja função principal seja a segurança da informação, tais como "firewall", antivírus, "antimalware", sistemas de detecção e prevenção de intrusões (IDS/IPS), emissão de certificados digitais entre outros;

V - o serviço de internet; e

VI - o Sistema Eletrônico de Informações (SEI).

Art. 4º A Coordenação-Geral de Tecnologia da Informação é responsável por manter e fazer cumprir a Política de Gerenciamento de Vulnerabilidades, submetendo à decisão da Secretaria-Executiva ou do Comitê de Governança Digital e Segurança da Informação, conforme o caso, as ações que não forem de sua competência.

Seção III

Das exceções

Art. 5º Não serão contemplados nesta Política ativos de informação cuja complexidade técnica, contratual ou normativa impeça sua adequação, devendo ser promovido o registro de tais impedimento em processo de gerenciamento de exceções.

Seção IV

Do público alvo

Art. 6º Esta Política se aplica a responsáveis pela gestão e pela utilização de qualquer ativo de informação da rede de computadores do Ministério do Turismo, bem como a quaisquer provedores e empresas com acesso a informações, redes e aplicativos do órgão.

CAPÍTULO II

CONCEITOS E DEFINIÇÕES

Art. 7º Os termos utilizados nesta Política estão definidos a seguir, conforme Glossário de Segurança da Informação da Presidência da República:

I - ameaça – conjunto de fatores externos com o potencial de causarem dano para um sistema ou organização;

II - análise de vulnerabilidades – verificação e exame técnico de vulnerabilidades, para determinar onde estão localizadas e como foram exploradas;

III - 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;

IV - 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;

V - 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;

VI - CVE (common vulnerabilities and exposures) – vulnerabilidades e exposições comuns;

VII - CVSS (common vulnerability scoring system) – sistema comum de pontuação de vulnerabilidade;

VIII - HOST – um computador ou dispositivo de ti (por exemplo, roteador, switch, gateway, firewall);

IX - ID CVE – identificação para um cve específico;

X - 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;

XI - 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;

XII - gestor de segurança da informação – responsável pelas ações de segurança da informação no âmbito do órgão ou entidade da administração pública federal;

XIII - LOG (registro de auditoria) – registro de eventos relevantes em um dispositivo ou sistema computacional. ntp (network time protocol) – protocolo de tempo para redes;

XIV - nuvem híbrida - infraestrutura de nuvem composta por duas ou mais infraestruturas distintas (privadas, comunitárias ou públicas), que permanecem com suas próprias características, mas agrupadas por tecnologia padrão que permite interoperabilidade e portabilidade de dados, serviços e aplicações;

XV - nuvem privada (ou interna) - infraestrutura de nuvem dedicada para uso exclusivo do órgão e de suas unidades vinculadas, ou de entidade composta por múltiplos usuários, e sua propriedade e seu gerenciamento podem ser da própria organização, de terceiros ou de ambos;

XVI - nuvem pública (ou externa) -infraestrutura de nuvem dedicada para uso aberto de qualquer organização, e sua propriedade e seu gerenciamento podem ser de organizações públicas, privadas ou de ambas;

XVII - PATCH – uma parte de código adicional desenvolvido para resolver um problema ou falha em um software existente;

XVIII - PENTEST – acrônimo de teste de penetração (penetration test);

XIX - remediação – o ato de corrigir uma vulnerabilidade ou eliminar uma ameaça;

XX - 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;

XXI - 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;

XXII - 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;

XXIII - 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;

XXIV - 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.

CAPÍTULO III

REFERÊNCIA LEGAL E DE BOAS PRÁTICAS

Art. 8º Além da necessidade de observância da legislação correlata, são referências legais e de boas práticas a serem observadas nesta Política as constantes no Anexo II desta Portaria.

CAPÍTULO IV

DECLARAÇÕES DA POLÍTICA

Seção I

Do gerenciamento de vulnerabilidades

Art. 9º Para implementação desta Política deve ser criado, implementado, mantido e aplicado um processo de gerenciamento de vulnerabilidades que deve:

I - conter a implementação de mecanismos para obter informações oportunas sobre vulnerabilidades técnicas dos sistemas e ativos de informação, a avaliação da exposição do órgão a tais vulnerabilidades e a implementação de salvaguardas apropriadas para lidar com o risco associado;

II - contemplar o gerenciamento de vulnerabilidades dos diversos ativos que sustentam os serviços do MTur, como ativos que compõe a rede da organização, aplicações web, aplicativos móveis, sistemas operacionais, dentre outros;

III - incluir atividades de suporte, com métricas de relatório, para implementação eficaz do processo; e

IV - estabelecer mecanismos para obter atualizações de software quando emitidas pelo fabricante ou fornecedor oficial, utilizando regulamente recursos autorizados, tais como: sites de fornecedores de sistemas, fóruns e grupos de notícias, bancos de dados de gerenciamento de vulnerabilidades e diferentes ferramentas para rastrear as vulnerabilidades mais recentes.

Parágrafo único. A consistência e a eficácia do processo devem ser medidas por meio de métricas de gerenciamento de vulnerabilidades a serem definidas pelo órgão.

Subseção I

Do mapeamento de ativos de informação

Art. 10. Sem prejuízo quanto a observação das normas da Política de Gestão de Ativos do Ministério do Turismo, um mapeamento de ativos de informação deve constar no escopo do processo de gerenciamento de vulnerabilidades e patches para 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 no órgão.

Parágrafo único. O mapeamento de ativos de informação deve ser atualizado sempre que ocorrerem alterações significativas para garantir que os recursos informacionais estejam cobertos pelo processo de gerenciamento de vulnerabilidades.

Seção II

Da detecção de vulnerabilidades

Art. 11. A Coordenação-Geral de Tecnologia da Informação definirá, com apoio de equipe técnica especializada, o escopo de vulnerabilidades, conforme níveis de severidade identificados em cada caso, devendo ser observado o seguinte:

I - as ferramentas devem ser configuradas e ajustadas adequadamente de acordo com o escopo avaliado;

II - os tipos de varreduras e os tipos de teste devem ser avaliados e ajustados para que sejam congruentes com o escopo avaliado;

III - a frequência de testes de segurança deve levar em consideração os requisitos legais, regulamentares e contratuais do MTur e os riscos associados aos ativos avaliados;

IV - as varreduras de vulnerabilidades na rede corporativa devem ser realizadas por períodos determinados ou após alteração significativa na rede;

V - os testes de segurança devem utilizar o feed de vulnerabilidade mais recente, de forma a evitar que determinadas vulnerabilidades não sejam detectadas;

VI - para cada teste, é necessário verificar a integridade da ferramenta utilizada, observando se ocorreu a correta varredura nos ativos analisados e se existem exceções de vulnerabilidades.

VII - as ferramentas utilizadas devem ser ajustadas continuamente, de forma a evitar que varreduras feitas por ferramentas distintas gerarem resultados distintos;

VIII - o teste de invasão ou o teste de penetração (Pentest) deve ser realizado conforme critério de necessidade ou em período adequado, conforme avaliação de equipe técnica;

IX - a integridade do resultado de detecção de vulnerabilidades deve ser avaliada antes de sua comunicação, de forma a evitar inconsistências, contradições ou resultados incompletos; e

X - a detecção manual de vulnerabilidades deve ser considerada como complemento à detecção automática de vulnerabilidades.

Seção III

Da elaboração e manutenção dos relatórios

Art. 12. A Coordenação-Geral de Tecnologia da Informação elaborará, com apoio de equipe técnica especializada, relatórios após cada ciclo de detecção para auxiliar no entendimento e mensuração das vulnerabilidades existentes.

Art. 13. Os resultados da varredura devem passar por análise com o dispositivo ou gerenciador de rede para que possíveis falsos positivos possam ser identificados e eliminados.

Art. 14. Grupos de ativos de informação devem ser determinados por tipo de ambiente, por tipo de sistema, por ID CVE ou por tipo de vulnerabilidade.

Art. 15. deve-se 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. 16. A quantidade e a porcentagem de novas vulnerabilidades devem ser monitoradas por:

a) severidade;

b) grupos funcionais;

c) tipo de ambiente;

d) tipo de sistema;

e) autoridade de numeração CVE; e

f) tipo de vulnerabilidade.

Art. 17. O relatório deve ser classificado, durante e após a sua elaboração, de acordo com a sensibilidade das informações presentes nele.

Art. 18. Todas as versões do relatório devem ser remetidas ao gestor de segurança de informação.

Seção IV

Do banco de dados de vulnerabilidades

Art. 19. Deve ser mantido um banco de dados de vulnerabilidades coletadas de várias fontes, como sites de segurança da informação, boletins de segurança ou publicações de fornecedores de software, que possam subsidiar na proteção de sistemas e ativos informacionais do MTur.

Art. 20. 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. 21. O banco de dados deve ser atualizado regularmente com as informações mais recentes.

§ 1º As novas vulnerabilidades devem ser adicionadas ao banco de dados tão logo forem descobertas.

§ 2º Quando tecnicamente viável e conveniente ao órgão, o banco de dados de vulnerabilidades será integrado com outras ferramentas de segurança, como scanners de vulnerabilidades e sistemas de gerenciamento de patches.

Art. 22. As informações coletadas no banco de dados devem ser analisadas regularmente para identificar tendências e padrões visando a tomada de medidas proativas para evitar vulnerabilidades futuras.

Seção V

Da priorização e correção de vulnerabilidades

Art. 23. O tratamento de vulnerabilidades será priorizado com base em sua classificação de risco e criticidade, tempo esperado para correção, grau de risco, impacto em caso de exploração e no valor que o ativo ou host impactado tem para o negócio.

Art. 24. As vulnerabilidades devem ser tratadas de acordo com o seu nível de severidade e nos prazos estipulados no Anexo II desta Portaria.

Art. 25. Os testes que forem concluídos com falha devem ser examinados novamente até que sua execução seja concluída com êxito.

Parágrafo Único. Caso não seja possível a execução com êxito, deve-se avaliar se a vulnerabilidade será incluída na lista de exceções, com base no processo de aceitação de risco.

Art. 26. Deve-se estabelecer mecanismos para obter atualizações de software quando emitidas pelo fabricante ou fornecedor oficial, utilizando recursos autorizados, tais como sites de fornecedores de sistemas, fóruns e grupos de notícias, bancos de dados de gerenciamento de vulnerabilidades e diferentes ferramentas para rastrear as vulnerabilidades mais recentes.

Art. 27. Quando as vulnerabilidades não puderem ser corrigidas dentro do prazo estabelecido na tabela de que trata o art. 24, a Coordenação Geral de Tecnologia da Informação avaliará a possibilidade de renúncia, com avaliação de seu impacto, transcrevendo:

I - detalhes do sistema ou ativo;

II - descrição detalhada da vulnerabilidade;

III - a 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).

Parágrafo único. Se a renúncia for considerada viável, a vulnerabilidade deve ser monitorada continuamente, pautado pelo plano de ação apresentado, devendo ser corrigida assim que possível.

Art. 28. 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 devem ser monitorados.

Seção VI

Das exceções

Art. 29. Os ativos de informação do MTur não contemplados por esta política em função de dificuldades técnicas, contratuais, normativas ou outras razões legítimas serão tratados como exceções que deverão ser documentadas e aprovadas por meio de um processo de gerenciamento de exceções.

Parágrafo único. A lista de exceções de ativos de informação valerá enquanto perdurar o impedimento, devendo ser reavaliada sempre que necessário.

Seção VII

Dos registros de logs

Art. 30. O registo de logs para análise de vulnerabilidades deve ser efetuada em observância, no que couber, à Política de Gestão de Registros (Logs) de Auditoria do Ministério do Turismo, e deve ainda:

I - Identificar quais eventos dos ativos de informação serão registrados, com base nos requisitos regulatórios, nas melhores práticas e nos objetivos do MTur;

II - recuperar regularmente nos ativos físicos ou virtuais, como servidores e recursos de rede, informações baseadas em uma única fonte de tempo de referência (servidor NTP) para que os relógios de registro sejam consistentes;

III - incluir, nas configurações referentes a ativos de informação, configurações de log para registrar ações que possam afetar ou que sejam relevantes para a segurança da informação;

IV - definir procedimento para análise de logs, como ferramentas de análise e correlação, para identificar possíveis ameaças e vulnerabilidades; e

V - ser monitorado regularmente para identificar quaisquer tentativas de exploração de vulnerabilidades.

Art. 31. Uma revisão dos arquivos de registro (logs) deve ser conduzida sempre que necessário.

Art. 32. Os arquivos de registro (logs) devem ser protegidos contra adulteração e acesso não autorizado ou exfiltração.

Art. 33. Registros de logs dos sistemas e ativos informacionais classificados como críticos devem ser mantidos por pelo menos o tempo necessário para cumprir os requisitos regulatórios e permitir a detecção de ameaças passadas.

Art. 34. Registros de log devem ser excluídos de forma segura, garantindo que sejam completamente apagados sem deixar vestígios ou dados remanescentes.

Seção VIII

Da implementação e verificação das correções de vulnerabilidades

Art. 35. As correções de vulnerabilidades devem ser verificadas para se apurar se não há novas vulnerabilidades.

Parágrafo único. As verificações podem ser feitas por meio de testes de penetração, testes de vulnerabilidade, análise de logs ou outros meios adequados.

Art. 36. Somente correções de vulnerabilidades que foram efetivamente testadas e aprovadas devem ser implantadas em produção.

Parágrafo único. As atividades de correção de vulnerabilidades podem incluir, entre outras:

I - instalação de patches de segurança; e

II - ajustes de configuração e/ou remoção de software.

Art. 37. No caso de ser recomendado patches de segurança e ajustes de configuração para mitigar vulnerabilidades, deve ser implementado, preferencialmente, por meio de processo de gestão de mudanças que indique controles apropriados para teste, avaliação dos riscos e reparação.

Seção IX

Dos serviços em nuvem

Art. 38. Esta Política se aplica, no que couber, nas relações do MTur com provedores de serviço em nuvem pública, privada ou híbrida.

CAPÍTULO V

DISPOSIÇÕES FINAIS

Art. 39. A implementação das diretrizes e normas de que tratam esta Política, conforme suas peculiaridades e complexidades, ocorrerá de forma gradual, de acordo com as possibilidades técnica, operacional, administrativa e, se for o caso, financeira do órgão.

ANEXO II

ANEXO III