RELATÓRIO DE CONSULTORIA

Programa de Privacidade e Segurança da informação - PPSI

Secretaria de Governo Digital – SGD
Exercício 2022

05 de dezembro de 2022
Controladoria-Geral da União (CGU)
Secretaria Federal de Controle Interno (SFC)

RELATÓRIO DE CONSULTORIA
Órgão: Ministério da Economia – ME
Unidade: Secretaria de Governo Digital – SGD
Município/UF: Brasília/DF
Relatório de Consultoria: 1168823
Missão
Elevar a credibilidade do Estado por meio da participação social, do controle
interno governamental e do combate à corrupção em defesa da sociedade.

Consultoria
O serviço de consultoria é uma atividade de auditoria interna governamental que
consiste em assessoramento, aconselhamento e outros serviços relacionados
fornecidos à alta administração com a finalidade de respaldar as operações da
unidade. Tem como finalidade agregar valor à organização e melhorar os seus
processos de governança, de gestão de riscos e de controles internos, de forma
condizente com seus valores, estratégias e objetivos, sem que o auditor interno
governamental assuma qualquer responsabilidade que seja da administração.

QUAL FOI O
TRABALHO
REALIZADO
PELA CGU?
O presente relatório
apresenta os resultados da
consultoria de
assessoramento realizada
para elaboração dos modelos
referentes às Políticas de
Controle de Acesso, de
Gestão de Ativos, de Backup,
de Gerenciamento de
Vulnerabilidades e de Gestão
de Registros (Logs) de
Auditoria, no escopo do
Programa de Privacidade e
Segurança da informação –
PPSI, junto à Secretaria de
Governo Digital do Ministério
da Economia – SGD/ME, no
âmbito de suas competências
normativas e orientativas,
como Órgão Central do
Sistema de Administração dos
Recursos de Tecnologia da
Informação – SISP.
POR QUE A CGU REALIZOU ESSE
TRABALHO?
Enquanto Órgão Central do Sistema de
Administração dos Recursos de Tecnologia da
Informação – SISP, a SGD edita normas e
orientações relacionadas à tecnologia da
informação, incluindo a segurança. Neste
sentido, a Coordenação-Geral de Auditoria de
Tecnologia da Informação –
CGATI/DG/SFC/CGU tem trabalhado junto
àquela Secretaria, com a finalidade de
contribuir no processo normativo com a
experiência do controle interno.
QUAIS AS CONCLUSÕES
ALCANÇADAS PELA CGU? QUAIS
AS RECOMENDAÇÕES QUE
FORAM EMITIDAS?
Foram identificados pontos de melhoria em
diversas partes dos modelos, a exemplo dos
tópicos que abordam: Acesso Lógico;
Bloqueio, desbloqueio e cancelamento da
conta de acesso; Inventário de ativos;
Responsabilidade pelos Ativos; Salvaguarda
dos dados; Dos testes de backup;
Procedimento de restauração de backup;
Priorização e correção de vulnerabilidades; e
Gestão de registros de auditoria.
Para melhoria dos pontos identificados foram
emitidas sugestões ou recomendações, que
incluíram a substituição de termos por outros
mais adequados ao tema, a exclusão de temas
que seriam melhor tratados em outros
documentos, a inserção de diretrizes
importantes, a revisão acerca do nível de
detalhamento do modelo, a definição clara de
tópicos que podem gerar dúvidas, a
atualização de norma referenciada, o
alinhamento à legislação de Segurança da
Informação, a referência a outros normativos,
o acréscimo de comandos normativos
importantes, o reposicionamento de
instruções para tópicos mais adequados e a
padronização dos modelos nos itens comuns.
LISTA DE SIGLAS E ABREVIATURAS
APF Administração Pública Federal
Art. Artigo
CIS Center for Internet Security
CGATI Coordenação-Geral de Auditoria de Tecnologia da Informação
CGU Controladoria-Geral da União
COBIT Control Objectives for Information and Related Technologies
CPF Cadastro de Pessoa Física
CVE Common Vulnerabilities and Exposures
CVSS Common Vulnerability Scoring System
DG Diretoria de Gestão
DTI Diretoria de Tecnologia da Informação
DSIC Departamento de Segurança da Informação
GSIPR Gabinete de Segurança Institucional da Presidência da República
IN Instrução Normativa
Inc. Inciso
LAI Lei de Acesso à Informação
LGPD Lei Geral de Proteção de Dados Pessoais
ME Ministério da Economia
NIST National Institute of Standards and Technology
NTP Network Time Protocol
PenTest Teste de penetração
PGRA Política de Gestão de Registros (Logs) de Auditoria
PGVP Processo de gerenciamento de vulnerabilidades e patches
PoSIN Política de Segurança da Informação
PPSI Programa de Privacidade e Segurança da informação
RFB Receita Federal do Brasil
RPO Recovery Point Objective
RTO Recovery Time Objective
SEI Sistema Eletrônico de Informação
SFC Secretaria Federal de Controle Interno
SGD Secretaria de Governo Digital
SIC Segurança da Informação e Comunicação
SIEM Security Information and Event Management
SISP Sistema de Administração dos Recursos de Tecnologia da Informação
SLA Service Level Agreement
TI Tecnologia da Informação
SUMÁRIO
INTRODUÇÃO 6

CONSIDERAÇÕES INICIAIS 7

RESULTADOS DOS EXAMES 9

1. Modelo de Política de Controle de Acesso 9

2. Modelo de Política de Gestão de Ativos 11

3. Modelo de Política de Backup 16

4. Modelo de Política de Gerenciamento de Vulnerabilidades 18

5. Modelo de Política de Gestão de Registros (Logs) de Auditoria 25

RECOMENDAÇÕES 35

CONCLUSÃO 35

ANEXOS 38

I. Manifestação da Unidade 38
INTRODUÇÃO
O presente relatório apresenta os resultados da consultoria de assessoramento realizada para
elaboração dos modelos referentes às Políticas de Controle de Acesso, de Gestão de Ativos,
de Backup, de Gerenciamento de Vulnerabilidades e de Gestão de Registros (Logs) de
Auditoria, no escopo do Programa de Privacidade e Segurança da informação – PPSI, junto à
Secretaria de Governo Digital do Ministério da Economia – SGD/ME, no âmbito de suas
competências normativas e orientativas, como Órgão Central do Sistema de Administração
dos Recursos de Tecnologia da Informação – SISP.

O PPSI tem como objetivo cumprir as atribuições da Secretaria de Governo Digital em matéria
de segurança da informação, privacidade e proteção de dados, na forma do Decreto nº 9.745,
de 8 de abril de 2019, e do Decreto nº 10.332, de 28 de abril de 2020. Em um primeiro
momento, o programa tem priorizado e fomentado, dentre outras iniciativas, o
desenvolvimento de ações que garantam a observância de cinco medidas emergenciais
referentes à área, que incluem o Inventário de Ativos, a Política de Backup, a Gestão de
Controle de Acessos, a Gestão de Vulnerabilidades e a Auditoria.

No fluxo comum do processo de gestão, em sua abordagem mais básica, o planejamento

figura na parte inicial e o controle na parte final do processo, que normalmente se dá de forma
linear, sobretudo na execução orçamentária e financeira da Administração Pública.

Figura 1: Fluxo do processo de gestão

Normatização Planejamento Execução Controle

Consultoria

Fonte: Elaborado pela CGU.

Neste sentido, a estratégia da CGU nas referidas consultorias é trazer a experiência do

controle interno, que atua nos casos concretos, para a fase de normatização, a qual define as
diretrizes em âmbito geral. Com a aplicação desse controle a priori, espera-se como benefício
a redução da necessidade de controle a posteriori na medida em que as normas e orientações
já partem com diretrizes que carregam em si medidas de controle embutidas.

A atuação da CGATI, coordenação de auditoria especializada, dedicada exclusivamente à

tecnologia da informação, encontra-se aderente aos termos do item 16 da IN CGU nº 3, de 9
de junho de 2017, apoiando, por meio de consultoria, no processo de gerenciamento de riscos
associados aos resultados finalísticos e competências da SGD (Art. 137 do Decreto nº 9.745,
de 8 de abril de 2019).

6
CONSIDERAÇÕES INICIAIS
Sobre o Modelo de Política de Controle de Acesso

A Política de Controle de Acesso objetiva estabelecer controles de identificação, autenticação

e autorização para salvaguardar as informações do órgão, estejam elas em qualquer meio,
seja digital ou físico, a fim de evitar a quebra da segurança da informação e quaisquer acessos
não autorizados que impliquem em risco de destruição, alteração, perda, roubo ou divulgação
indevida. Sem controles de autorização, identificação e autenticação, existe o risco potencial
de que os sistemas de informação possam ser acessados ilicitamente e que a segurança desses
sistemas de informação seja comprometida.

Considera-se, portanto, que as credenciais crachá de identificação funcional e logins de acesso

dos sistemas de informações são pessoais e intransferíveis e são o único método legítimo pelo
qual o direito de acesso físico e/ou lógico podem ser exercidos. Os controles de autorização,
identificação e autenticação garantem que apenas usuários autorizados tenham acesso físico
ou façam uso dos sistemas de informação do órgão.

Sobre o Modelo de Política de Gestão de Ativos

O objetivo desta política é garantir que os ativos de informação sejam identificados

adequadamente e que os controles de proteção recomendados para estes ativos de
informação estejam em vigor.

Para manter a segurança e continuidade do negócio do órgão em sua missão é fundamental

mapear e monitorar os ativos tecnológicos, para maior controle da organização, auxiliando na
aplicação de atualizações, implementação de controles de segurança e gestão de riscos da
organização e auxiliando também na recuperação de incidentes.

Os ativos de informação do órgão devem ser classificados a fim de permitir a definição de

níveis de segurança para eles. Cada ativo de informação deverá ter um “dono”, no qual
realizará a classificação do ativo de informação e deverá ser registrado em uma base de dados
gerenciada de forma centralizada.

Sobre o Modelo de Política de Backup

A Política de Backup e Restauração de Dados Digitais objetiva instituir diretrizes,

responsabilidades e competências que visam à segurança, proteção e disponibilidade dos
dados digitais custodiados pelas unidades de tecnologia da informação e formalmente
definidos como de necessária salvaguarda na organização, para se manter a continuidade do
negócio.

No sentido de assegurar sua missão é fundamental estabelecer mecanismos que permitam a

guarda dos dados e sua eventual restauração em casos de indisponibilidades ou perdas por
erro humano, ataques, catástrofes naturais ou outras ameaças. Na Política de Backup e

7
Restauração de Dados Digitais se estabelece o modo e a periodicidade de cópia dos dados
armazenados pelos sistemas computacionais.

Sobre o Modelo de Política de Gerenciamento de Vulnerabilidades

O objetivo da Política de Gerenciamento de Vulnerabilidades é estabelecer as regras

relacionadas às atividades de identificação, avaliação, documentação, gestão, comunicação e
remediação de vulnerabilidades. Além disso, contempla ações e boas práticas que devem ser
observadas para se evitar que vulnerabilidades estejam presentes nos ativos da organização.

A revisão, a avaliação, a aplicação e a verificação das atualizações de ativos de informação

auxiliam a mitigar as vulnerabilidades no ambiente de Tecnologia da Informação e
Telecomunicações, bem como os riscos associados a tais vulnerabilidades.

Sobre o Modelo de Política de Gestão de Registros (Logs) de Auditoria

O objetivo da Política de Gestão de Registros (Logs) de Auditoria é estabelecer e manter um

processo de gestão de log de auditoria que defina os requisitos de log do órgão. Tal processo
deve tratar da coleta, armazenamento, uso e exclusão de logs de auditoria e sistemas para os
ativos de informação do órgão. É importante que seja estabelecida a revisão periódica deste
processo de gestão de log de auditoria.

Neste sentido, o modelo serve para definir os princípios de atuação da auditoria interna nos
processos de TI do órgão e as diretrizes para a administração e gerenciamento de registros de
logs gerados pelos ativos de informação.

Notas Técnicas da consultoria

Tendo desenvolvido, inicialmente, os três primeiros modelos de controles essenciais, a SGD

os encaminhou à CGATI/DG/SFC/CGU, em 08 de março de 2022, para coleta de contribuições
deste órgão de controle. As contribuições foram apresentadas à SGD por meio da Nota
Técnica nº 01, de 04 de abril de 2022. Posteriormente, a SGD encaminhou, em 24 de junho de
2022, o Modelo de Política de Gerenciamento de Vulnerabilidades, para o qual as
contribuições da CGU foram apresentadas por meio da Nota Técnica nº 03, de 07 de julho de
2022. Por fim, encaminhou a SGD, em 20 de julho de 2022, o Modelo de Política de Gestão de
Registros (Logs) de Auditoria, para o qual as contribuições da CGU foram enviadas por meio
da Nota Técnica nº 04, de 19 de agosto de 2022.

Forma de apresentação dos resultados

Os apontamentos registrados em cada tópico de resultados dos exames são compreendidos

de maneira mais adequada em conjunto com o modelo correspondente, cuja minuta foi
analisada pela CGU, tendo em vista que se referem aos itens nele dispostos. Neste sentido, a
estrutura textual de cada tópico apresenta sugestões diretas acerca dos itens abordados no
modelo correspondente e, na medida do possível, a própria estrutura do modelo enviado,
cujo link do documento final é apresentado no início do tópico.

8
RESULTADOS DOS EXAMES
1. Modelo de Política de Controle de Acesso
tem por finalidade prover diretrizes para o controle de acesso.

https://www.gov.br/governodigital/pt-br/seguranca-e-protecao-de-dados/ppsi/modelo_politica_controle_acesso.pdf
Acessado em 08/11/2022

1.1. Introdução

Sugere-se que seja substituído o termo “manual” por “modelo” na segunda coluna da terceira
linha do primeiro quadro, de modo que o texto final fique da seguinte forma:

Relacione outras políticas corporativas relacionadas dentro ou externas a este

modelo, por exemplo, Código de Conduta\Política de Senhas \ PoSIN

Tendo em vista que o documento em questão se trata de um Template1, é um modelo a ser

adaptado e não um manual a ser seguido.

1.2. Propósito

É recomendável substituir o termo “usuários conhecidos” por “usuários autorizados” no

terceiro parágrafo do Propósito, de modo que o texto final fique da seguinte forma:

Os controles de autorização, identificação e autenticação garantem que apenas

usuários autorizados tenham acesso físico ou façam uso dos sistemas de
informação do [Nome do órgão/empresa/fundação].

O termo usuário conhecido abrange apenas o usuário identificado, mas não o usuário
autorizado a acessar o sistema. Por outro lado, o usuário autorizado pressupõe a sua
identificação e autenticação.

1.3. Acesso Lógico

Foram previstas diretrizes para o controle de acesso lógico. Entretanto, o presente Template
é silente quanto ao controle de acesso físico. Desta forma é recomendável inserir as diretrizes
para o controle dos acessos físicos, conforme prevê o item 7 da Norma Complementar nº
7/IN01/DSIC/GSIPR2, a qual estabelece as Diretrizes para Implementação de Controles de
Acesso Relativos à Segurança da Informação e Comunicações, nos órgãos e entidades da
Administração Pública Federal (APF), direta e indireta.

1.4. Bloqueio, desbloqueio e cancelamento da conta de acesso

1
O termo Template é utilizado como sinônimo de Modelo.
2
https://pesquisa.in.gov.br/imprensa/jsp/visualiza/index.jsp?data=16/07/2014&jornal=1&pagina=3&totalArquivos=84
9
Alguns itens trazem exigências em nível de detalhamento cuja definição, em princípio, caberia
à área responsável pela tecnologia da informação do órgão, como é o caso da Diretoria de
Tecnologia da Informação – DTI. Citam-se como exemplos, não exaustivos, os seguintes itens
em negrito:

7. As senhas de acesso serão renovadas a cada 90 (noventa) dias...

8. A conta de acesso será bloqueada nos seguintes casos: Após 5 (cinco)
tentativas consecutivas de acesso errado;
11. A conta de acesso não utilizada há mais de 180 (cento e oitenta) dias
poderá ser cancelada.

Em uma Política de Segurança da Informação, enquanto documento da alta gestão, não cabe
detalhamento nesse nível, o que deveria ser abordado dentro de um procedimento da DTI.
Sugere-se, portanto, rever os itens com este nível de detalhamento e, se for o caso de mantê-
los, deixá-los em texto cinza, de modo que sejam informações personalizadas pelo órgão.

1.5. Administradores

O significado do texto do item 14, inciso VII, abaixo reproduzido, ficou confuso:

VII. Em nenhuma hipótese será concedida identificação (login) com privilégio de

administrador para mais de uma estação de trabalho, para um mesmo usuário
ou para acesso a equipamentos servidores e a dispositivos de rede.

Não está claro se ele quer dizer que um mesmo usuário não pode ser administrador de mais
de uma estação de trabalho, equipamentos servidores e dispositivos de rede, ou, se de outro
modo, estações de trabalho distintas não podem ser administradas por um mesmo usuário,
equipamento servidor ou dispositivo de rede.

Se for a primeira opção, o texto seria mais claro se escrito de uma forma diferente, a exemplo
da que segue:

VII. Em nenhuma hipótese será concedida, para um mesmo usuário,

identificação (login) com privilégio de administrador para mais de uma estação
de trabalho, ou para acesso a equipamentos servidores e a dispositivos de rede.

Se for a segunda opção, ficaria mais claro algo escrito da seguinte forma:

VII. Em nenhuma hipótese será concedida identificação (login) com privilégio de

administrador para mais de uma estação de trabalho a um mesmo usuário ou
equipamento servidor ou dispositivo de rede.

Seja como for, o teor dessa proibição parece engessar as atividades da área responsável pela
gestão da tecnologia da informação do órgão. Ou seja, “em nenhuma hipótese” quer dizer que
nem mesmo o servidor da DTI pode ser administrador de mais de uma máquina. Isso terá
impactos quando for necessário, por exemplo, que a equipe de suporte promova instalação

10
ou desinstalação de programa nas máquinas. Ou quando for necessário, a partir de um
servidor, instalar atualizações nas máquinas.

1.6. ANEXO A – Modelo de Termo de Responsabilidade

O inciso III do Anexo A, que trata do Modelo de Termo de Responsabilidade, faz referência à
versão revogada da Instrução Normativa GSI nº 01, de 13 de junho de 2008:

III. Contribuir para assegurar a disponibilidade, a integridade, a

confidencialidade e a autenticidade das informações, conforme descrito na
Instrução Normativa nº 01, do Gabinete de Segurança Institucional da
Presidência da República, de 13 de junho de 2008, que Disciplina a Gestão de
Segurança da Informação e Comunicações na Administração Pública Federal,
direta e indireta;

Neste sentido, é recomendável atualizar para a nova versão daquela IN, incluindo o seu
preâmbulo, conforme a seguir:

III. Contribuir para assegurar a disponibilidade, a integridade, a

confidencialidade e a autenticidade das informações, conforme descrito na
Instrução Normativa nº 01, do Gabinete de Segurança Institucional da
Presidência da República, de 27 de maio de 2020, que Dispõe sobre a Estrutura
de Gestão da Segurança da Informação nos órgãos e nas entidades da
administração pública federal;

2. Modelo de Política de Gestão de Ativos

tem por objetivo prover diretrizes para a gestão de ativos.

https://www.gov.br/governodigital/pt-br/seguranca-e-protecao-de-dados/ppsi/modelo_politica_gestao_ativos_versao_1-1_.pdf
Acessado em 08/11/2022

2.1. Introdução

Sugere-se que seja substituído o termo “manual” por “modelo” na segunda coluna da terceira
linha do primeiro quadro, de modo que o texto final fique da seguinte forma:

Relacione outras políticas corporativas relacionadas dentro ou externas a este

modelo, por exemplo, Política de Gestão de Riscos \ Política de Retenção de
Dados \ PoSIN

Tendo em vista que o documento em questão se trata de um Template, é um modelo a ser

adaptado e não um manual a ser seguido.

2.2. Propósito

11
No exemplo apresentado no presente item é descrito o objetivo da política nos seguintes
termos:

O objetivo desta política é garantir que os ativos sejam identificados

adequadamente e que os controles de proteção recomendados para estes
ativos estejam em vigor.

Em outra parte:

Os ativos da (o) [Organização] devem ser classificados a fim de permitir a

definição de níveis de segurança para eles. Cada ativo deverá ter um “dono”,
no qual realizará a classificação do ativo e deverá ser registrado em uma base
de dados gerenciada de forma centralizada.

O termo mais adequado aos propósitos deste Template, de modo a se conformar à definição
do Glossário de Segurança da Informação, seria “ativos de informação”. Aprovado pela
Portaria GSI Nº 93, de 26 de setembro de 20193, o referido glossário apresenta a seguinte
distinção

ATIVO - qualquer coisa que tenha valor para a organização;

ATIVOS DE INFORMAÇÃO - os meios de armazenamento, transmissão e

processamento da informação, os equipamentos necessários a isso, os sistemas
utilizados para tal, os locais onde se encontram esses meios, e também os
recursos humanos que a eles têm acesso;

No conceito de “ativo” do Glossário de SIC entraria até mesmo a “imagem” do Órgão, que é
considerado um ativo relevante, porém fora do escopo deste documento. Já o conceito de
“ativos de informação” está mais alinhado ao propósito do Template. Convém lembrar ainda
que o próprio Template, na parte de Termos e Definições, reproduz o conceito de “ativos de
informação” do Glossário de SIC. Portanto, para alinhar com a própria definição do modelo, é
importante adotar, não só neste item, mas em todo o documento, o termo na sua forma
restrita.

2.3. Referência legal e de boas práticas

É recomendável incluir, de preferência logo após a referência à Instrução Normativa nº

01/GSI/PR, uma referência para a Instrução Normativa nº 03/GSI/PR, de 28 de maio de 2021,
a qual dispõe sobre os processos relacionados à gestão de segurança da informação nos
órgãos e nas entidades da administração pública federal. A referida IN, em seu capítulo II, trata
justamente do mapeamento dos ativos de informação.

3
Por um lapso, utilizou-se nas Notas Técnicas 01 e 02 da Consultoria de nº 1168823, como referência ao Glossário
de SIC, a Portaria GSI/PR Nº 93, de 26 de setembro de 2019, ao invés da versão atualizada de 18 de outubro de
2021. O erro foi corrigido nas Notas Técnicas 03 e 04 da Consultoria de nº 1168823, bem como na Nota Técnica
01 da Consultoria de nº 1281193.
12
2.4. Declarações da política

Nos dois primeiros incisos do subitem “Dos princípios gerais” é utilizado o termo “Política de
Ativos”. Sugere-se que seja utilizado o mesmo termo que nomeia o Template, qual seja,
“Política de Gestão de Ativos”.

2.5. Inventário de ativos

a) Ainda no tópico referente a Declarações da política, o Template traz orientações acerca de

inventário dos ativos de informação. Neste sentido, recomenda-se o alinhamento do
documento com a Instrução Normativa GSI/PR nº 3/2021, que trata de “mapeamento de
ativos de informação” e não “inventário”.

b) Sugere-se ainda, para alinhamento com os art. 5º e 6º daquela IN, avaliar a oportunidade
de acréscimo dos seguintes incisos nos princípios gerais:

iv. O processo de mapeamento de ativos de informação deve considerar,

preliminarmente os objetivos estratégicos da organização, seus processos
internos, os requisitos legais e sua estrutura organizacional.

v. O registro de ativos de informação resultante do processo de mapeamento

de ativos de informação deverá conter: os responsáveis (proprietários e
custodiantes) de cada ativo de informação; as informações básicas sobre os
requisitos de segurança da informação de cada ativo de informação; os
contêineres de cada ativo de informação; as interfaces de cada ativo de
informação e as interdependências entre eles.

2.6. Responsabilidade pelos Ativos

a) Avaliar a conveniência de inserir as responsabilidades previstas no Art. 9º da IN GSI/PR nº

3/2021, especialmente no que diz respeito aos seguintes incisos:

II - identificar potenciais ameaças aos ativos de informação;

III - identificar vulnerabilidades dos ativos de informação;
IV - consolidar informações resultantes da análise do nível de segurança da
informação de cada ativo de informação ou de grupos de ativos de informação
em um relatório;
VI - avaliar os riscos dos ativos de informação ou do grupo de ativos de
informação.

b) O tópico “3 Os seguintes ativos devem ser considerados no processo de inventário” não

deveria estar na seção de "Responsabilidade pelos Ativos". Neste sentido, convém avaliar a
oportunidade de criar um item específico para tratar do processo de “Mapeamento dos ativos
de informação”, apartado dos itens “Dos princípios gerais” e “Responsabilidade pelos Ativos”,
deixando neste último somente as diretrizes atinentes às responsabilidades, aprovações,
competências etc.

13
c) Ainda quanto ao tópico “3 Os seguintes ativos devem ser considerados no processo de
inventário”, sugere-se excluir o inciso “V Informações críticas”, pois a definição de ativo de
informação não inclui a informação propriamente dita.

d) Por fim, na diretriz “Os processos em torno do gerenciamento de configuração também

serão estabelecidos e monitorados.”, seria interessante também considerar o gerenciamento
de mudanças.

2.7. Classificação das informações:

1. Da classificação

a) Ao definir que:

Todos os ativos devem ser classificados em termos de requisitos legais, valor,

sua importância para a organização e sigilo se forem divulgados por uma parte
não autorizada.

Não está claro se o termo “valor” se refere ao valor do ativo de informação em termos
financeiros (ex.: custo ou preço do ativo), ou se é referente ao potencial que este tem de
agregar valor ao negócio da organização, no caso, à prestação dos serviços públicos ou
políticas públicas geridas pela organização. Importa observar que nem todo ativo terá seu
valor quantificável numericamente, principalmente quando se tratar de ativos intangíveis.

b) Sugere-se ainda acrescentar, à lista de requisitos, os “requisitos regulatórios e contratuais”.

Isto se deve ao fato de que a prática BAI 09.01 do Cobit tem como atividade associada:

Identificar os requisitos (legais, regulatórios e contratuais) que devem ser

considerados ao se gerenciar cada ativo.

c) No caso de ativos físicos relacionados no item “3.I” do Template, convém incluir que eles
devem ser classificados também em termos de “vida útil”.

2. Criticidade

Segundo o inc. I do Art. 9º da IN GSI/PR Nº 03/2021, os ativos de informação devem ser

classificados por “nível de criticidade”.

Assim, sugere-se incluir um item sobre a identificação de quais seriam os ativos de informação
críticos da organização, tomando como base, em sua importância para a organização, seu
potencial de agregação de valor e outros critérios de risco ou fatores de criticidade.

Convém também destacar que devem estar claros na política os fatores de criticidade, ou
critérios de riscos, utilizados para classificar os ativos em críticos.

3. Lei de Acesso à Informação

14
Tendo em vista que os ativos de informação se referem aos meios de armazenamento,
transmissão e processamento da informação, e não da informação em si, e ainda que a Lei de
Acesso à Informação – LAI regula o acesso à informação, recomenda-se a adequação do texto:

Os ativos da [organização] devem ser classificados de acordo com a legislação

pertinente (recomenda-se leitura da LEI Nº 12.527, DE 18 DE NOVEMBRO DE
2011), podendo ser classificado em uma das seguintes categorias:

Sugere-se como alternativa algo como:

As informações armazenadas, transmitidas, processadas ou que se

encontram sob a guarda dos ativos de informação da [organização] devem ser
classificadas de acordo com a legislação pertinente (recomenda-se leitura da
LEI Nº 12.527, DE 18 DE NOVEMBRO DE 2011), podendo ser classificadas em
uma das seguintes categorias:

2.8. Uso aceitável

No item 6 do presente Template, ao definir o uso aceitável dos ativos de informação, a

utilização do termo “sistemas de informação” pode restringir o alcance das diretrizes
apresentadas. Ao restringir que os documentos indiquem o que os usuários dos sistemas de
informação podem ou não fazer, a diretriz do primeiro parágrafo não abarca o uso dos outros
ativos de informação que não sejam sistema, como por exemplo, o uso de computadores ou
telefones:

Padrões ou diretrizes para o uso aceitável de ativos devem ser documentados

para indicar o que os usuários dos sistemas de informação podem ou não fazer.

O mesmo ocorre com a seguinte diretriz:

Como requisito de acesso ao sistema de informação e como componente do

treinamento de conscientização de segurança, todos os usuários dos sistemas
de informação, sejam funcionários ou terceiros, serão obrigados a fornecer
aceitação assinada das diretrizes de uso aceitáveis.

Desta forma, é recomendável substituir o termo “sistema de informação” por “ativo de

informação”, de modo que o documento de aceitação assinado pelo usuário, quanto às
diretrizes de uso aceitáveis, contemple todo e qualquer ativo de informação da organização,
a exemplo dos itens relacionados nas cinco alíneas do segundo parágrafo, e não somente os
sistemas de informação, os quais são apenas parte da alínea “i”.

2.9. Concordância

Na declaração que confirma o entendimento e o acordo para cumprir a política:

Eu li e entendi a Política de Controle de Ativos do [órgão/empresa/fundação].

Entendo que se eu violar as regras aqui explicadas, posso enfrentar ações legais
ou disciplinares de acordo com as leis aplicáveis ou a política da empresa.
15
O termo empresa deveria ser grafado em cinza com as opções iguais às da primeira frase, ou
seja, [órgão/empresa/fundação].

3. Modelo de Política de Backup

tem por enfoque prover diretrizes para política de backup e restauração
de dados digitais.
https://www.gov.br/governodigital/pt-br/seguranca-e-protecao-de-dados/ppsi/modelo_politica_de_backup_versao_1-1.pdf
Acessado em 08/11/2022

3.1. Escopo

Ao definir o escopo do Template da Política de Backup e Restauração de Dados Digitais, a sua

aplicação ficou restrita aos dados críticos, conforme reproduzido a seguir:

Esta política se aplica a todos os dados críticos no âmbito da [organização],

incluindo dados fora da [organização] armazenados em um serviço de nuvem
Pública ou Privada. “Dados críticos”, neste contexto, incluem [citar os dados
considerados críticos para organização, ex.: e-mail, arquivos pessoais e
compartilhados, bancos de dados e conteúdo da web específicos e sistemas
operacionais]. A definição de dados críticos e o escopo desta política de backup
serão revisados [informar a periodicidade, ex.: anualmente].

Entretanto, as orientações definidas neste documento, por tratarem de política de backup e

restauração de dados, em princípio, não estariam restritas a dados críticos. Elas deveriam ser
implementadas por todos os setores da organização que necessitem fazer cópias e
restauração de informações em meio digital, que sejam mantidos em servidores pertencentes
à organização ou plataforma de nuvem adotada. Desta forma, não ficou claro porque a política
irá focar apenas em dados críticos.

3.2. Dos princípios gerais

1. Gestão de Continuidade

No item Dos Princípios Gerais, do capítulo Declarações da Política, foi definido o seguinte
princípio:

2. A Política de Backup e Restauração de Dados deve estar alinhada com uma

gestão de continuidade de negócios em nível organizacional.

Para fins de maior alinhamento à IN GSI nº 01/2020, mais precisamente ao Art.12, inciso IV,
item h, que trata da Gestão de Continuidade, seria recomendada a elaboração de um
Template para um plano de continuidade de negócios que conteria uma política de backup e
restauração, cujo Template está sendo aqui proposto.

2. Armazenamento de backup

16
Ao tratar do local de armazenamento de backup, no princípio de número 6, é recomendável
enfatizar a questão de os dados de serviços críticos serem armazenados em local remoto. Uma
sugestão pode ser algo como o seguinte complemento:

6. O armazenamento de backup, se possível, deve ser realizado em um local

distinto da infraestrutura crítica. É desejável que se tenha um sítio de backup
em um local remoto ao da sede da organização para armazenar cópias extras
dos principais backups, a exemplo dos backups de dados de serviços críticos.

3.3. Salvaguarda dos dados

Ao tratar da salvaguarda dos dados, no item 15, foram utilizadas duas siglas, RPO e RTO, sem
definição prévia. É recomendável esclarecer os termos Recovery Point Objective – RPO e
Recovery Time Objective – RTO.

Uma sugestão aplicável é a criação de uma lista de siglas/acrônimos. Na inviabilidade de

criação de uma lista de siglas/acrônimos, os termos podem ter sua definição apresentada na
seção Termos e Definições.

3.4. Do transporte e armazenamento

Apresenta-se, para o tópico Do transporte e armazenamento, as seguintes sugestões:

a) Acrescentar uma observação de que a execução das rotinas de backup deve envolver a
previsão de ampliação da capacidade dos dispositivos envolvidos no armazenamento;
b) Incluir um item sobre o tempo de permanência do backup dos arquivos em nuvem de
usuários/colaboradores que foram desligados da organização. Exemplo:
“No caso de desligamento do usuário (de forma permanente ou temporária), o
backup de seus arquivos em nuvem deverá ser mantido por, no mínimo, ___
dias. Após esse período os arquivos poderão ser excluídos a qualquer tempo.”.
c) Adicionar no item 26, que trata do acondicionamento, os fatores ambientais sensíveis
“poeira” e “pressão” nos exemplos citados;
d) Acrescentar também, no mesmo item 26, as medidas usadas pelos fabricantes como
balizadores dos fatores ambientais sensíveis. O texto poderia ficar, por exemplo, parecido
com o seguinte:
26. As unidades de armazenamento dos backups devem ser acondicionadas em
locais apropriados, com controle de fatores ambientais sensíveis, como
umidade, temperatura, poeira e pressão, e com acesso restrito a pessoas
autorizadas pelo administrador de backup. Além disso, as condições de
temperatura, umidade e pressão devem ser aquelas descritas pelo fabricante
das unidades de armazenamento.

3.5. Dos testes de backup

a) Quanto ao item 29, que trata dos testes de restauração de backups, sugere-se incluir a
seguinte diretriz:

17
 “Os registros deverão conter, no mínimo, o tipo de sistema/serviço que teve o
seu reestabelecimento testado, a data da realização do teste, o tempo gasto
para o retorno do backup e se o procedimento foi concluído com sucesso.”

b) Considerar também, na avaliação dos testes de restauração, a verificação do atendimento

dos níveis de serviço pactuados, tais como os Recovery Time Objective – RTOs.

3.6. Procedimento de restauração de backup

Na alínea a do item 32, que trata do tempo de restauração, sugere-se detalhar mais o acordo
de SLA de restore, como por exemplo, da seguinte forma:

a. O tempo de restauração, preferencialmente definido em Acordo de Nível de

Serviço entre as áreas de negócio e de TIC, é proporcional ao volume de dados
necessários para o restore. A cada [XXGB] de dados, o tempo de restauração é
de [informar o tempo ex: uma hora]. Esta estimativa é do tempo de
atendimento da [Informar a Equipe responsável], não contemplando o tempo
antes ou após o pedido a equipe.

4. Modelo de Política de Gerenciamento de Vulnerabilidades

tem por objetivo prover diretrizes para política de gerenciamento de
vulnerabilidades.
https://www.gov.br/governodigital/pt-br/seguranca-e-protecao-de-dados/ppsi/modelo_politica_vulnerabilidades.pdf
Acessado em 08/11/2022

4.1. Política de Gerenciamento de Vulnerabilidades

1. Orientações iniciais

As orientações iniciais para utilização do modelo recomendam substituir os textos em cinza

itálico. Desta forma, recomenda-se revisar o documento colocando em itálico todos os textos
que deverão ser substituídos. No quadro introdutório, por exemplo, os textos da segunda
coluna não estão em itálico.

2. Data de revisão

No quadro introdutório, onde consta a data de revisão da política, seria interessante o modelo
sugerir, como exemplo, uma data para revisão e atualização da política. Se a SGD entender
que, por exemplo, um ano seria um período adequado para se fazer revisão da política,
poderia colocar como exemplo no quadro.

4.2. Propósito

18
Inserir no início, antes do exemplo, o texto introdutório padrão utilizado nos outros 3 modelos
que orienta a elaboração do tópico:

"Levando em consideração natureza e a finalidade do órgão ou da entidade,

descreva os fatores ou circunstâncias que determinam a existência da política
de gerenciamento de vulnerabilidades. Além disso, informe os objetivos básicos
da política e o que ela pretende alcançar. "

4.3. Escopo

1. Texto introdutório

Inserir no início, antes de qualquer texto, o texto padrão utilizado nos outros 3 modelos que
orienta a elaboração do tópico:

“Defina a quem e a quais sistemas esta política se aplica. Liste os agentes

públicos e colaboradores necessários para cumprir ou simplesmente indique
"todos" se todos devem cumprir. Também indique quaisquer exclusões ou
exceções que estejam fora de escopo, ou seja, essas pessoas, elementos ou
situações que não estejam cobertas por esta política ou onde uma consideração
especial possa ser feita.”

2. Instituição/Organização/Órgão/Entidade

Apresenta-se como sugestão, numa eventual revisão que porventura venha a ocorrer nos
modelos, procurar padronizar o termo empregado para se referir à instituição no sentido
genérico, ainda que na aplicação concreta cada instituição se identificará com seu nome.
Senão vejamos:

• No Modelo de Política de Controle de Acesso utilizou-se o termo [Nome do

órgão/empresa/fundação];
• No Modelo de Política de Backup utilizou-se o termo [organização];
• No Modelo de Política de Gestão de Ativos utilizou-se o termo [Órgão ou entidade];
• Neste Modelo de Política de Gerenciamento de Vulnerabilidades usa-se o termo [da
instituição].

Não há prejuízo concreto com a utilização de termos distintos que aludem a um mesmo
sentido. A sugestão se dá em vista da padronização dos modelos. Também não é o caso de
alterá-los por tão pequena motivação isolada, mas em circunstância oportuna de revisão
ordinária que venha a ocorrer.

3. Disposição dos tópicos

Os tópicos “Exceções” e “Público”, por se referirem ao Escopo, deveriam ser subtópicos

daquele. Da forma apresentada não fica clara essa disposição.

4. Exceções

19
Ao tratar das exceções ao escopo do gerenciamento de vulnerabilidades, situação em que
alguns ativos de informação do órgão não seriam contemplados por possíveis dificuldades
técnicas ou obrigações contratuais e normativas, mencionando a necessidade de um processo
de gerenciamento de exceções, seria importante também alertar aos órgãos que estas
exceções precisam ser tratadas no mapeamento de riscos de segurança da informação que o
órgão deve efetuar em cumprimento ao Capítulo III da Instrução Normativa GSI/PR Nº 3, de
28 de maio de 2021.

5. Público

O texto do tópico “Público” contradiz o primeiro parágrafo do item “Escopo”. Lá é informado

que a política se aplica aos usuários em geral, ou seja, aos funcionários, gestores, prestadores
de serviços e contratados que utilizam os ativos, conforme a seguir:

Esta política de gerenciamento de vulnerabilidades se aplica aos sistemas e

ativos informacionais [da instituição], incluindo funcionários, gestores,
prestadores de serviços e contratados que tenham acesso e ou utilize de ativos
informacionais.

Aqui, o modelo restringe o público ao corpo técnico, informando que a política se aplica aos
indivíduos responsáveis pela gestão de ativos, de ferramentas e processos de rede, além dos
provedores e terceirizados, como segue:

Esta Política de Gerenciamento de Vulnerabilidades (PGV) [da instituição] se

aplica a indivíduos responsáveis pela gestão de Ativos de Informação que
executam funções relacionadas à gestão das ferramentas e processos da Rede
Computadores em nome [da instituição]. Além disso, essa política se aplica a
quaisquer provedores e entidades terceirizadas com acesso às informações,
redes e aplicativos [da instituição].

Desta forma, sugere-se harmonizar os textos para um mesmo entendimento. Além disso, é
importante avaliar se convém restringir a política de gerenciamento de vulnerabilidades às
equipes de segurança da informação ou de tecnologia do órgão. Importa refletir se o usuário
na ponta, os gestores, ou a alta administração, não tem nenhuma atribuição, ainda que
secundária, no processo.

4.4. Termos e Definições

1. AMEAÇA

Conferida a versão certificada da Portaria GSI/PR Nº 93, de 18 de outubro de 2021, publicada

na página 36 da Seção 1 do Diário Oficial da União de 19 de outubro de 2021, verificou-se que
o texto realmente foi publicado conforme reproduzido no presente modelo, ou seja, com o
erro ortográfico presente no verbo causar, motivado provavelmente por falha de digitação ou
correção automática do editor de texto que tenha separado parte do verbo de sua conjugação
no plural. Nesse sentido, pode-se corrigir a falha em vista do melhor entendimento do termo,
juntando as partes separadas da seguinte forma:
20
 AMEAÇA - conjunto de fatores externos com o potencial de causarem dano para
um sistema ou organização;

Convém observar, para conhecimento, que o termo AMEAÇA teve sua definição alterada em
relação à Portaria nº 93, de 26 de setembro de 2019, que era:

AMEAÇA - conjunto de fatores externos ou causa potencial de um incidente

indesejado, que pode resultar em dano para um sistema ou organização;

2. ANÁLISE DE VULNERABILIDADES

É recomendável inserir o termo ANÁLISE DE VULNERABILIDADES, conforme a Portaria GSI/PR

Nº 93/2021, reproduzido a seguir:

ANÁLISE DE VULNERABILIDADES - verificação e exame técnico de

vulnerabilidades, para determinar onde estão localizadas e como foram
exploradas;

O referido termo servirá para embasar as ideias expressas nos itens 23 e 30 do tópico
Declarações da Política.

3. TESTE DE INVASÃO

Na Portaria GSI/PR Nº 93/2021 o termo apresentado é o seguinte:

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 pela instituição;

Desta forma, é recomendável apresentar a definição do termo PENTEST em consonância com

o Glossário de SIC. Por outro lado, observa-se que no termo definido pelo Glossário de SIC, o
procedimento consiste em testar todos os sistemas, diferentemente da definição aqui
exposta, a qual está em consonância com o Controle 18 do Center for Internet Security – CIS.
A propósito, a descrição do Glossário de SIC não parece a melhor para definir o pentest. Neste
sentido, sugere-se que a SGD, quando oportuno, comunique o GSI para revisão do respectivo
termo apresentado no Glossário de SIC.

Por fim, caso entenda necessária a definição de TESTE DE INVASÃO conforme apresentada no
presente modelo, tendo em vista que é diferente o seu conteúdo, sugere-se adotá-la como
termo distinto e, portanto, não como sinônimo de teste de intrusão ou teste de penetração,
tendo em vista que estes foram definidos diversamente na Portaria do GSI.

4. Itens utilizados no texto

Os acrônimos CVE e CVSS utilizados no texto não foram definidos. Recomenda-se utilizar as
definições apresentadas no Guia de Gerenciamento de Vulnerabilidades:
21
 CVE (Common Vulnerabilities and Exposures):
Vulnerabilidades e Exposições Comuns

ID CVE:
Identificação para um CVE específico

CVSS (Common Vulnerability Scoring System):

Sistema comum de pontuação de vulnerabilidade

Recomenda-se incluir ainda o seguinte termo:

NTP (Network Time Protocol): utilizado no item 38, ao tratar dos registros de logs.

4.5. Referência legal e de boas práticas

1. CIS (Center for Internet Security)

Ao referenciar o Framework de segurança cibernética do CIS 8, convém mencionar, na coluna

Seção, além do Controle 11, que trata da Recuperação de dados, também e principalmente o
Controle 07, que trata da gestão contínua de vulnerabilidades, e ainda o Controle 18, que trata
de testes de invasão.

2. NIST (National Institute of Standards and Technology)

Ao referenciar o NIST, a citação ao documento CSF: SP 800-40 Rev. 4, Creating a Patch and
Vulnerability Management Program, apresentou uma inconsistência. A versão 4 é outro
documento e tem outro título, qual seja: Guide to Enterprise Patch Management Planning:
Preventive Maintenance for Technology, conforme pode ser conferido no endereço:
https://csrc.nist.gov/publications/detail/sp/800-40/rev-4/final.

Tendo em vista que a estrutura das diretrizes apresentadas no tópico de Declarações da

Política se assemelha, em parte, à versão 2.0 do documento CSF: SP 800-40, ou seja, a que
possui de fato o título (Creating a Patch and Vulnerability Management Program), talvez seja
o caso de referenciar as duas versões do documento.

3. Guia de Gerenciamento de Vulnerabilidades

É recomendável que esse guia receba uma referência de destaque na política. Convém
lembrar que ele foi proposto inicialmente para ser o modelo de política de gerenciamento de
vulnerabilidades e, portanto, tem peso significativo para este modelo.

Tomando a política como documento de diretrizes que figura em nível mais estratégico, como
um elo entre a governança e a gestão da Unidade, e o guia como documento mais operacional,
próprio do dia a dia da gestão relativa ao tema, convém avaliar a conveniência em adotá-lo
como parte ou anexo desta.

22
Um tópico possível de fazer esta referência poderia ser, por exemplo, no de “Procedimentos
Relevantes”, tendo em vista que o Guia de Gerenciamento de Vulnerabilidades seria um
documento de procedimento formal que reforça e apoia as declarações da política.

4.6. Declarações da política

1. Estrutura

A estrutura das diretrizes se assemelha, em parte, à versão 2.0 do documento CSF: SP 800-40
(Creating a Patch and Vulnerability Management Program) do NIST, disposta no seguinte
endereço:
https://csrc.nist.gov/publications/detail/sp/800-40/version-20/archive/2005-11-16

Entretanto esta versão foi publicada em novembro de 2005 e retirada em julho de 2013,
conforme alerta o primeiro parágrafo do documento e o quadro que o sucede:

Figura 2: Versão 2.0 do documento CSF: SP 800-40

Fonte: NIST Special Publication 800-40 Version 2.0

Em princípio, as diretrizes ou boas práticas do documento não deixam de ser importantes

simplesmente pela descontinuidade do documento. O que há de ser observado é se as
referidas diretrizes ou práticas não foram substituídas ou atualizadas por instruções melhores.

2. Processo de gerenciamento de vulnerabilidades e patches (PGVP)

A gestão de patches tem uma importância de destaque no gerenciamento de

vulnerabilidades, entretanto, não o esgota por completo, havendo práticas afetas ao
gerenciamento de vulnerabilidades que não envolvem diretamente patches de correção.
Neste sentido, é recomendável, ao tratar de diretrizes no documento de política, abordar o
processo de gerenciamento de vulnerabilidades de forma geral. Um processo de
gerenciamento de vulnerabilidades envolve tudo relacionado ao tema e nele já está contida
ou implícita a gestão de patches.

3. Métricas
23
Verificar a conveniência de inserir uma diretriz relativa ao emprego das métricas, citadas nos
itens 7 e 8, na melhoria contínua do processo. Esta sugestão tem como referência o seguinte
documento do Gartner: "A Guidance Framework for Developing and Implementing
Vulnerability Management"; Fase "Improve".

4. Padronização

Ao mencionar o Comitê de Segurança da Informação, no item 8, convém inserir o termo "ou

estrutura equivalente", conforme padrão utilizado na Instrução Normativa GSI/PR Nº 01/2020,
art. 10.

8. As métricas de gerenciamento de vulnerabilidades e patches devem ser

definidas pelo [Comitê de Segurança da Informação ou estrutura equivalente]
e suas medições devem ser apresentadas a cada [período].

4.7. Inventário de sistemas e ativos de informação

a) Ao tratar do Inventário de sistemas e ativos de informação, itens 9 e 10, avaliar a

conveniência de alterar o termo "Inventário" para "Mapeamento", para fins de
compatibilidade com a IN GSI/PR nº 03/2021, a qual dispõe sobre os processos relacionados
à gestão de segurança da informação na administração pública federal e dispõe de um capítulo
específico para Mapeamento de Ativos de Informação.

b) O "programa de gerenciamento de vulnerabilidades" mencionado nos itens 9 e 10 do tópico

relacionado ao inventário de sistemas não foi previamente definido e nem mencionado em
outro item do presente modelo. Uma possibilidade seria a menção ao “Processo de
gerenciamento de vulnerabilidades e patches (PGVP)” definido no tópico anterior. Desta
forma, recomenda-se a revisão dessa citação, e se for o caso, definir o que seria esse
programa.

4.8. Priorização e correção de vulnerabilidades

a) Como pode ser observado da leitura dos riscos descritos no quadro do item 32 (coluna
Descrição do Risco), que vão desde o risco de coletar informações de um host até o caso mais
crítico de obter o controle do host, a comparação de criticidade dos riscos possui variação em
relação a um host determinado, porém não considera o valor do ativo para o negócio da
organização. Como resultado, o tempo de resposta para correção de uma mesma
vulnerabilidade, isto é, com o mesmo grau de severidade, em hosts distintos, que hospedam
serviços de valores distintos para a organização, será o mesmo.

Sugere-se, portanto, em relação à priorização do tratamento de vulnerabilidades disposta no

item 31, que se avalie a conveniência de adicionar como critério o valor do ativo para o
negócio. Neste sentido, o nível de severidade poderia ser definido também com base no valor
do ativo para o negócio da organização.

24
b) De forma complementar, considerar a possibilidade de adicionar o tratamento de
vulnerabilidade (remediação) emergencial sobre sistemas críticos, ou seja, de alto valor para
o negócio, em períodos menores. Exemplo: 24 a 48 horas da ciência da vulnerabilidade.

A sugestão apresentada tem como referência o seguinte documento do Gartner: "A Guidance
Framework for Developing and Implementing Vulnerability Management"; Fase "Act"; Passo
"Remediate".

4.9. Das exceções

Ainda com referência ao documento do Gartner "A Guidance Framework for Developing and
Implementing Vulnerability Management", em sua fase "Act", passo "Accept Risk", verificar a
conveniência da inserção de uma diretriz que alerte sobre a necessidade de revisão periódica
das condições de exceção.

4.10. Implementação e verificação das correções de vulnerabilidades

Ao tratar, no item 45, do “processo de gerenciamento de alterações da instituição”, como

meio de instalação de patches, considerar alterar o nome do processo para "processo de
gestão de mudanças" a fim de guardar maior aderência à definição constante no Glossário de
SIC, Portaria GSI/PR Nº 93, de 18 de outubro de 2021:

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;

A definição de gestão de mudanças é aderente também à terminologia do ITIL.

5. Modelo de Política de Gestão de Registros (Logs) de Auditoria

tem por objetivo prover diretrizes para a gestão de registros de auditoria.

https://www.gov.br/governodigital/pt-br/seguranca-e-protecao-de-dados/ppsi/modelo_politica_logs_auditoria.pdf
Acessado em 08/11/2022

5.1. Esclarecimentos

a) O último parágrafo do tópico relativo aos esclarecimentos traz uma definição para o termo
Log, acrescida de explicações complementares relativas ao tema.

É recomendável levar o conceito de Log para o item de Termos e Definições.

b) O restante do parágrafo está mais alinhado com o último parágrafo da Introdução do que
com o texto de Esclarecimentos. Sugere-se, portanto, compor aquele parágrafo com estas
informações explicativas acerca dos Logs.

25
5.2. Política de Gestão de Registro de Auditoria – PGRA

1. Orientações iniciais

As orientações iniciais para utilização do modelo recomendam substituir os textos em cinza

itálico. Desta forma, recomenda-se revisar o documento colocando em itálico todos os textos
que deverão ser substituídos. No quadro introdutório, por exemplo, os textos da segunda
coluna não estão em itálico.

2. Data de revisão

No quadro introdutório, onde consta a data de revisão da política, seria interessante o modelo
sugerir, como exemplo, uma data para revisão e atualização da política. Se a SGD entender
que, por exemplo, um ano seria um período adequado para se fazer revisão da política,
poderia colocar como exemplo no quadro. Caso entenda pertinente, para fins de
padronização, pode ser copiado o texto colocado no último modelo publicado, Modelo de
Política de Gerenciamento de Vulnerabilidades:

“Liste a data em que a política deve passar por revisão e atualização.

Recomenda-se que seja definido um período de revisão da política, pelo menos
um ano, ou quando houver alterações de normativos legais significativos sobre
o tema.”

5.3. Propósito

É recomendável inserir no início, antes do exemplo, o texto introdutório padrão, utilizado nos
outros 4 modelos, que orienta a elaboração do tópico:

"Levando em consideração natureza e a finalidade do órgão ou da entidade,

descreva os fatores ou circunstâncias que determinam a existência da Política
de Gestão de Registros de Auditoria. Além disso, informe os objetivos básicos
da política e o que ela pretende alcançar."

5.4. Escopo

1. Texto introdutório

Inserir no início, antes de qualquer texto, o texto padrão utilizado nos outros 4 modelos que
orienta a elaboração do tópico:

“Defina a quem e a quais sistemas esta política se aplica. Liste os agentes

públicos e colaboradores necessários para cumprir ou simplesmente indique
"todos" se todos devem cumprir. Também indique quaisquer exclusões ou
exceções que estejam fora de escopo, ou seja, essas pessoas, elementos ou
situações que não estejam cobertas por esta política ou onde uma consideração
especial possa ser feita.”

2. Serviços de TI críticos
26
Reavaliar a pertinência de trazer o estabelecimento de serviços de TI críticos dentro do tópico
Escopo de cada modelo de Política. Este mesmo conteúdo foi colocado nos modelos de política
de Gerenciamento de Vulnerabilidades e de Backup. Ao se definir uma relação de serviços
críticos em cada modelo corre-se o risco de não serem iguais, sobretudo quando as políticas
passarem por revisões em tempos distintos no órgão.

Ademais, a seleção de sistemas críticos não deveria constar no escopo da política de logs, uma
vez que este escopo não se restringe a sistemas críticos, o que pode confundir o usuário da
norma.

Tendo em vista que o Guia do Framework de Privacidade e Segurança da Informação,

proposto no âmbito do PPSI, traz a metodologia para seleção de sistemas críticos em seu
Anexo I, e, portanto, fora dos controles de cibersegurança e de privacidade, a relação desses
sistemas deveria ser definida em documento a parte, o qual poderia ser referenciado nos
modelos.

3. Exceções

Ao tratar das exceções ao escopo da gestão de registros de auditoria, situação em que alguns
ativos de informação do órgão não seriam contemplados por possíveis dificuldades técnicas
ou obrigações contratuais e normativas, mencionando a necessidade de um processo de
gerenciamento de exceções, seria importante também alertar aos órgãos que estas exceções
precisam ser tratadas no mapeamento de riscos de segurança da informação que o órgão deve
efetuar em cumprimento ao Capítulo III da Instrução Normativa GSI/PR Nº 3, de 28 de maio
de 2021.

4. Público

O texto do tópico “Público” contradiz o primeiro parágrafo do item “Escopo”. Lá é informado

que a política se aplica aos usuários em geral, ou seja, aos funcionários, gestores, prestadores
de serviços e contratados que tenham acesso ou utilizem os ativos informacionais, conforme
a seguir:

Esta Política de Gestão de Registro de Auditoria – PGRA se aplica aos ativos

informacionais [do órgão ou entidade], incluindo funcionários, gestores,
prestadores de serviços e contratados que tenham acesso e ou os utilize.

Aqui, o modelo restringe o público ao corpo técnico, informando que a política se aplica aos
indivíduos responsáveis pela gestão de ativos, de ferramentas e processos de rede, além dos
provedores e terceirizados, como segue:

Esta Política de Gestão de Registro de Auditoria – PGRA [do órgão ou entidade]

se aplica a indivíduos responsáveis pela gestão de Ativos de Informação que
executam funções relacionadas à gestão das ferramentas e processos da Rede
Computadores em nome [do órgão ou entidade]. Além disso, essa política se
aplica a quaisquer provedores e entidades terceirizadas com acesso às
informações, redes e aplicativos [do órgão ou entidade].
27
Desta forma, sugere-se harmonizar os textos para um mesmo entendimento. Além disso, é
importante avaliar se realmente convém restringir a política de gestão de registros de
auditoria às equipes de segurança da informação ou de tecnologia do órgão conforme foi
mencionado. Importa refletir se os usuários, os gestores, ou a alta administração, não têm
nenhuma atribuição, ainda que secundária, no processo.

Convém observar, quanto ao corpo técnico, que a política de logs não deve estar restrita a
equipes de redes, pois as equipes que desenvolvem sistemas têm papel bastante relevante na
elaboração dos artefatos e envio dos registros/logs transacionais dos sistemas. É importante
citar ainda que, em especial nos sistemas transacionais da APF, pode haver necessidade de se
evidenciar o crime tipificado no Código Penal, em seu art. 313-A:

"Inserir ou facilitar, o funcionário autorizado, a inserção de dados falsos,

alterar ou excluir indevidamente dados corretos nos sistemas informatizados
ou bancos de dados da Administração Pública com o fim de obter vantagem
indevida para si ou para outrem ou para causar dano": Pena- reclusão de 2
(dois) a 12 (doze) anos e multa. (grifo nosso)

Por fim, ao tratar dos provedores e empresas terceirizadas, o texto não considerou as
especificidades contratuais:

Além disso, essa política se aplica a quaisquer provedores e entidades

terceirizadas com acesso às informações, redes e aplicativos [do órgão ou
entidade].

O provedor não é obrigado a cumprir cláusulas que não estejam em contrato. Assim,
requisitos envolvendo os eventos (seleção, tempo de guarda/volume, uso de ferramentas
como SIEMs (Security Information and Event Management), sistemas de armazenamento,
entre outros recursos) devem ser descritos na especificação do objeto e as regras para o seu
cumprimento estabelecidas em contrato. Logs podem ter custos elevados de
armazenamento, bem como demandar sistemas específicos para ingestão e coleta,
tratamento, indexação. Portanto, é recomendável deixar uma ressalva de que a aplicação da
política para os contratados está restrita aos limites estabelecidos contratualmente, a
exemplo do seguinte texto:

Além disso, essa política se aplica, nos limites estabelecidos contratualmente, a

quaisquer provedores e entidades terceirizadas com acesso às informações,
redes e aplicativos [do órgão ou entidade].

5.5. Termos e Definições

1. ATIVOS DE INFORMAÇÃO

O conceito aqui apresentado para o termo ATIVOS DE INFORMAÇÃO tem como referência o
Glossário de Segurança da Informação – SIC, publicado por meio da Portaria GSI/PR Nº 93 de
26 de setembro de 2019, revogada pela Portaria GSI/PR Nº 93 de 18 de outubro de 2021. A
versão atualizada traz o seguinte conceito:
28
 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;

Desta forma, recomenda-se atualizar o referido conceito e, na oportunidade, revisar os

demais termos frente ao Glossário de SIC atualizado.

2. INCIDENTE CIBERNÉTICO

O texto referente ao termo INCIDENTE CIBERNÉTICO não foi copiado da Portaria GSI/PR Nº
93/2021 na sua integralidade. Faltaram os tipos de incidentes apresentados naquela norma:

INCIDENTE CIBERNÉTICO - ocorrência que pode comprometer, real ou

potencialmente, a disponibilidade, a integridade, a confidencialidade ou a
autenticidade de sistema de informação ou das informações processadas,
armazenadas ou transmitidas por esse sistema. Poderá também ser
caracterizada pela tentativa de exploração de vulnerabilidade de sistema de
informação que caracterize violação de norma, política de segurança,
procedimento de segurança ou política de uso. De maneira geral, os tipos de
atividade comumente reconhecidas como incidentes cibernéticos são: a)
tentativas de obter acesso não-autorizado a um sistema ou a dados
armazenados; b) tentativa de utilização não-autorizada de sistemas para a
realização de atividades de processamento ou armazenamento de dados; c)
mudanças não-autorizadas de firmware, hardware ou software em um
ambiente computacional; d) ataques de negação de serviço (DoS); e) demais
ações que visem afetar a disponibilidade ou integridade dos dados. Um
incidente de segurança cibernética não significa necessariamente que as
informações já estão comprometidas; significa apenas que a informação está
ameaçada;

Desta forma, recomenda-se complementar o texto com os tipos de incidentes exemplificados,

os quais o GSI entendeu pertinentes para melhor ilustrar o termo definido no Glossário de SIC.

3. LOG

É recomendável inserir, antes dos termos LOG DE AUDITORIA e LOG DE SISTEMA, o termo
LOG, conforme consta na Portaria GSI/PR nº 93/2021:

LOG (REGISTRO DE AUDITORIA) - registro de eventos relevantes em um

dispositivo ou sistema computacional;

Posteriormente podem ser apresentadas as variações, de auditoria e de sistema, sem prejuízo

do Glossário de SIC, que não entra nesse detalhe.

4. TRILHA DE AUDITORIA

29
O termo TRILHA DE AUDITORIA não está alinhado ao apresentado na Portaria GSI/PR nº
93/2021. Recomenda-se, portanto, copiar a definição do Glossário de SIC:

TRILHA DE AUDITORIA - registro ou conjunto de registros gravados em arquivos

de log ou outro tipo de documento ou mídia, que possam indicar, de forma
cronológica e inequívoca, o autor e a ação realizada em determinada operação,
procedimento ou evento;

5. Itens utilizados no texto

Avaliar a viabilidade de definir os seguintes termos utilizados no texto, os quais foram

definidos no Modelo de Política de Gerenciamento de Vulnerabilidades:

HOST – Um computador ou dispositivo de TI (por exemplo, roteador, switch,

gateway, firewall).

NTP (Network Time Protocol) – Protocolo de Tempo para Redes.

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.

5.6. Referência legal e de boas práticas

1. NC nº 21/IN01/DSIC/GSIPR

Incluir na referência legal a Norma Complementar nº 21/IN01/DSIC/GSIPR, a qual estabelece

as diretrizes para o registro de eventos, coleta e preservação de Evidências de Incidentes de
Segurança em Redes nos órgãos e entidades da Administração Pública Federal, direta e
indireta.

2. CIS (Center for Internet Security)

Ao referenciar o Framework de segurança cibernética do CIS 8, convém mencionar, na coluna

Seção, além do Controle 11, que trata da Recuperação de dados, e do Controle 8, que
apresenta a Gestão de registros de auditoria, o item 3.14, de elevada importância nos sistemas
transacionais da união.

3.14 - Registrar o acesso a dados sensíveis

Registre o acesso a dados sensíveis, incluindo modificação e descarte.

Além disso, outros itens do CIS têm relação indireta com a gestão de registros de auditoria:

13.1 - Centralizar o alerta de eventos de segurança

Centralize os alertas de eventos de segurança em ativos corporativos para
correlação e análise de log. A melhor prática requer o uso de um SIEM, que
inclui alertas de correlação de eventos definidos pelo fornecedor. Uma

30
 plataforma de análise de log configurada com alertas de correlação relevantes
para a segurança também atende a esta medida de segurança.

13.6 - Coletar logs de fluxo de tráfego da rede

Colete logs de fluxo de tráfego de rede e/ou tráfego de rede para revisar e
alertar sobre dispositivos de rede.

3.1 - Estabelecer e manter um processo de gestão de dados

Estabeleça e mantenha um processo de gestão de dados. No processo, trate a
sensibilidade dos dados, o proprietário dos dados, o manuseio dos dados, os
limites de retenção de dados e os requisitos de descarte, com base em padrões
de sensibilidade e retenção para a empresa. Revise e atualize a documentação
anualmente ou quando ocorrerem mudanças significativas na empresa que
possam impactar esta medida de segurança.

3.4 - Aplicar retenção de dados

Retenha os dados de acordo com o processo de gestão de dados da empresa. A
retenção de dados deve incluir prazos mínimos e máximos.

17.8 - Conduzir análises pós-incidente

Realize análises pós-incidente. As análises pós-incidente ajudam a prevenir a
recorrência do incidente por meio da identificação de lições aprendidas e ações
de acompanhamento.

Desta forma, avaliar a viabilidade de citá-los também nas referências.

3. Processo de gestão de registros de auditoria

Recomenda-se citar a referência de base utilizada para o processo de gestão de registros de

auditoria, apresentado no tópico Declarações da Política, o qual fora organizado em quatro
fases, Coleta, Armazenamento, Uso e Exclusão.

5.7. Gestão de registros de auditoria

O texto apresentado no tópico Gestão de registros de auditoria é basicamente uma

introdução às quatro fases da referida gestão, quais sejam: Coleta, Armazenamento, Uso e
Exclusão. Entretanto, as fases são apresentadas no tópico Declarações da política, a partir do
item 21, de modo que este texto introdutório ficou descolado, em tópico à parte, e diverso do
padrão seguido nos outros modelos, os quais trazem o tópico Declarações da Política logo
após Referência legal e de boas práticas.

Assim, sugere-se criar um subtópico dentro de Declarações da política para registrar as fases
da gestão de registros de auditoria, iniciado com essa introdução e seguido com as fases
propriamente ditas, de modo que a estrutura forme um bloco coeso da seguinte forma:

Declarações da política [Regras aplicáveis ao caso específico]

Premissas e responsabilidades

31
 Requisitos do plano de registros de auditoria
Fases da gestão de registros de auditoria
Coleta
Armazenamento
Uso
Exclusão
Recomendações técnicas

Do modo como está, as fases estão soltas no meio das diretrizes do tópico Declarações da
política, entre a parte de Requisitos do plano de registros de auditoria e a parte de
Recomendações técnicas.

5.8. Declarações da política

1. Premissas e responsabilidades

a) A primeira diretriz trata da competência da atividade de auditoria, nos seguintes termos

1. A atividade de auditoria é de competência da [equipe responsável] [do órgão

ou entidade].

Há uma premissa de que existe uma equipe de auditoria central que seria responsável pelos
logs, porém nos órgãos esta responsabilidade pode ser compartilhada com gestores de
sistemas, área de tecnologia e prestadores de serviço.

b) A segunda diretriz aborda o monitoramento de privilégios elevados:

2. Privilégios elevados devem ser sempre monitorados.

Avaliar se essa premissa é realmente necessária nessa política de gestão de registros de

auditoria ou se estaria mais adequada nas políticas relacionadas aos controles de acesso ou
gestão de contas (controles 5 e 6 do Guia do Framework de Privacidade e Segurança da
Informação).

c) Avaliar, por fim, a viabilidade de acrescentar as seguintes diretrizes, com a finalidade de

tornar claras tais disposições:

• Os eventos de log devem ser gerados, selecionados e armazenados para todos

os ativos.
• A [equipe responsável] deve selecionar os eventos e os respectivos tempos de
guarda, bem como as demais características de uso dos eventos.
• As exceções deverão ser documentadas.

2. Requisitos do plano de registros de auditoria

Ao citar a sincronização de data e hora, avaliar eventual necessidade de se utilizar o horário

de Greenwich em sistemas hospedados em provedores de nuvem onde o fuso local pode ser
diferente do fuso do provedor.
32
3. Coleta

a) No texto explicativo que antecede às diretrizes para a fase de coleta de logs é abordada a
coleta de logs de forma detalhada, nos seguintes termos:

Para melhorar o nível de maturidade desta atividade, é importante que o órgão

ou entidade consiga coletar os logs de auditoria de forma detalhada, e tais logs
tenham dados importantes como data, hora de criação, atualização,
permissões, nome do usuário, origem do evento, e demais metadados dos
arquivos que o órgão ou entidade possa determinar como importantes.

Sugere-se que sejam incluídos os dados mencionados no CIS 8.5, a exemplo de: endereços de
origem, endereços de destino e outros elementos úteis que podem ajudar em uma investigação
forense.

b) Também no tópico da coleta de logs de auditoria, é feito seguinte alerta:

A não observância da conformidade do item 21, pode acarretar prejuízos

financeiros e reputacionais.

Neste caso, convém incluir a menção às sanções administrativas relacionadas no art. 52 da

LGPD:

A não observância da conformidade do item 21, pode acarretar prejuízos

financeiros e reputacionais, além das sanções administrativas relacionadas no
art. 52 da LGPD.

4. Armazenamento

a) No texto explicativo que antecede às diretrizes para a fase de armazenamento de logs, é

abordada a questão de transferência de logs para armazenamento alternativo, nos seguintes
termos:

A transferência de logs para armazenamento alternativo, deve ser feita para

um ativo de informação que esteja em uma rede lógica, ou física diferente, com
o propósito de proteger a confidencialidade e integridade dos registros de
auditoria.

Neste caso, convém especificar que a transferência seja realizada por meio de comunicação
segura, isto é, criptografada.

b) Ao tratar do período de guarda dos logs, recomenda-se, como sugestão, referenciar a tabela
de temporalidade dos ativos de informação do órgão. O CIS menciona 90 dias, o que
certamente é insuficiente para a maioria dos sistemas transacionais públicos (Ex: A RFB guarda
alguns eventos por 8 anos). Em nuvem alguns sistemas têm log nativo inferior a 30 dias (Ex:
Azure AD), alguns SIEMs de nuvem têm cobrança diferenciada para períodos superiores a 90
dias. Uma boa prática seria o órgão adotar um artefato por sistema inventariado em que se

33
analisa, com base em riscos e custos, quais eventos devem ser guardados e por quais
intervalos de tempo.

Quanto a retenção dos registros, é importante observar, sobre o mesmo item, que os prazos
administrativos e judiciais são muito superiores a tempos de guarda previstos em soluções
analíticas. Desta forma pode ser conveniente elencar eventos que deverão ser guardados no
longo prazo, para permitir apurações, pesando o risco e os custos. Pode ser necessário
executar esse processo para cada sistema. Considerar a obrigatoriedade de
Apagamento/Esquecimento previsto na LGPD, Art. 16.

Os dados pessoais serão eliminados após o término de seu tratamento, no

âmbito e nos limites técnicos das atividades, autorizada a conservação para as
seguintes finalidades:
I - cumprimento de obrigação legal ou regulatória pelo controlador;
II - estudo por órgão de pesquisa, garantida, sempre que possível, a
anonimização dos dados pessoais;
III - transferência a terceiro, desde que respeitados os requisitos de tratamento
de dados dispostos nesta Lei; ou
IV - uso exclusivo do controlador, vedado seu acesso por terceiro, e desde que
anonimizados os dados.

5. Uso

a) Na diretriz 39 é abordada a questão de análise forense para os casos de incidentes de

segurança:
39. Ativos de informação devem ser submetidos a análise forense em caso de
incidentes de segurança da informação devidamente comprovados.

Avaliar se a submissão de ativos a análise forense cabe na política de eventos de auditoria, ou

se seria algo restrito à política de tratamento de incidentes de segurança da informação
(controle 17 do Guia do Framework de Privacidade e Segurança da Informação).

b) De forma similar, o item 46 parece trazer tema mais adequado à política de tratamento e
resposta a incidentes e pode, portanto, ser estranho a essa política de logs:

46. A rede deve ser monitorada para detectar possíveis eventos de segurança
cibernética.

c) Por fim, a diretriz do item 52 pode ser de difícil implementação, a depender do caso:

52. O acesso a sistemas críticos por terceiros deve ser monitorado quanto a
atividades não autorizadas ou incomuns.

O cadastro CPF, por exemplo, é acessado por mais de 800 órgãos e não há como diferenciar
terceiros. O sistema não tem como definir sozinho o que é uma atividade incomum, e para
esses casos pode ser necessário o uso de sistemas auxiliares. Neste sentido, é recomendável
inserir a expressão quando possível ou suportado na referida diretriz.

34
RECOMENDAÇÕES
As recomendações, sugestões, reflexões e riscos apresentados sobre o teor dos modelos,
consignadas nos itens 1, 2, 3, 4 e 5 dos resultados dos exames do presente relatório, foram
objeto de consideração por parte da equipe da Secretaria de Governo Digital – SGD, cabendo
a esta a adoção das recomendações e sugestões que entenderam pertinentes. Em síntese, a
Unidade incorporou aos respectivos modelos as alterações propostas nos seguintes itens:
Tabela 1: Alterações incorporadas pela SGD

Alterações Não
Política Nota Técnica Alterações incorporadas *
incorporadas

Controle de Acesso 01 1.1, 1.2, 1.4, 1.5 e 1.6 1.3

2.1, 2.2, 2.3, 2.4, 2.5.a, 2.5.b, 2.6.a, 2.6.b,

Gestão de Ativos 01 2.6.c, 2.6.d, 2.7.1.a, 2.7.1.b, 2.7.1.c, 2.7.2, -
2.7.3, 2.8 e 2.9

3.1, 3.2.2, 3.3, 3.4.a, 3.4.b, 3.4.c, 3.4.d,

Backup 01 3.5.a, 3.5.b e 3.6
3.2.1

4.1.1, 4.1.2, 4.2, 4.3.1, 4.3.2, 4.3.3, 4.3.4,

Gerenciamento de 4.3.5, 4.4.1, 4.4.2, 4.4.3, 4.4.4, 4.5.1,
03 4.5.2, 4.5.3, 4.6.1, 4.6.2, 4.6.3, 4.6.4,
-
Vulnerabilidades
4.7.a, 4.7.b, 4.8.a, 4.8.b, 4.9 e 4.10
5.1.a, 5.1.b, 5.2.1, 5.2.2, 5.3, 5.4.1, 5.4.2,
5.4.3, 5.4.4, 5.5.1, 5.5.2, 5.5.3, 5.5.4,
Gestão de Registros
04 5.5.5, 5.6.1, 5.6.2, 5.7, 5.8.1.a, 5.8.1.b, 5.6.3
(Logs) de Auditoria 5.8.1.c, 5.8.2, 5.8.3.a, 5.8.3.b, 5.8.4.a,
5.8.4.b, 5.8.5.a, 5.8.5.b e 5.8.5.c
* A indicação das alterações incorporadas segue a numeração do presente relatório e difere da numeração
original das Notas Técnicas e da manifestação da Unidade.
Fonte: elaborado pela CGU

Como pode ser observado, a adesão da Unidade atingiu 85 das 88 sugestões apresentadas
nas Notas Técnicas, aproximadamente 96%, o que demonstra grande contribuição da
consultoria ao Programa de Privacidade e Segurança da informação – PPSI.
O detalhamento das medidas adotadas pela SGD, bem como as justificativas relacionadas aos
itens não incorporados, encontram-se no Anexo I. Manifestação da Unidade.

CONCLUSÃO
A parceria entre a CGU, órgão de controle do Governo, cujas competências incluem a auditoria
e a fiscalização da execução orçamentária e financeira, e a SGD, posicionada no planejamento
do Governo e cujas competências incluem as atribuições de orientar e normatizar, trouxe
resultados importantes para a Administração Pública Federal nos últimos anos, no tocante à
gestão dos recursos de tecnologia da informação. A consultoria tem sido esse canal, por meio

35
do qual este órgão de controle participa no assessoramento ou aconselhamento daquela
Secretaria.

Neste sentido, o benefício esperado da citada consultoria, qual seja, a aplicação da experiência
do controle interno na etapa de normatização, foi alcançado, tendo sido identificados pontos
de melhoria em diversas partes dos modelos, a saber:

• Em relação ao Modelo da Política de Controle de Acesso, nos seguintes tópicos:

Introdução; Propósito; Acesso Lógico; Bloqueio, desbloqueio e cancelamento da conta
de acesso; Administradores; e Modelo de Termo de Responsabilidade;
• Em relação ao Modelo da Política de Gestão de Ativos, nos seguintes tópicos:
Introdução; Propósito; Referência legal e de boas práticas; Declarações da política;
Inventário de ativos; Responsabilidade pelos Ativos; Classificação das informações;
Uso aceitável; e Concordância;
• Em relação ao Modelo da Política de Backup, nos seguintes tópicos: Escopo; Dos
princípios gerais; Salvaguarda dos dados; Do transporte e armazenamento; Dos testes
de backup; e Procedimento de restauração de backup.
• Em relação ao Modelo da Política de Gerenciamento de Vulnerabilidades, nos
seguintes tópicos: Orientações iniciais; Propósito; Escopo; Termos e Definições;
Referência legal e de boas práticas; Declarações da política; Inventário de sistemas e
ativos de informação; Priorização e correção de vulnerabilidades; Das exceções; e
Implementação e verificação das correções de vulnerabilidades;
• Em relação ao Modelo da Política de Gestão de Registros (Logs) de Auditoria, nos
seguintes tópicos: Esclarecimentos; Política de Gestão de Registro de Auditoria –
PGRA; Propósito; Escopo; Termos e Definições; Referência legal e de boas práticas;
Gestão de registros de auditoria; e Declarações da política;

Para melhoria dos pontos identificados foram emitidas sugestões ou recomendações, que
incluíram a substituição de termos por outros mais adequados ao tema, a exclusão de temas
que seriam melhor tratados em outros documentos, a inserção de diretrizes importantes, a
revisão acerca do nível de detalhamento do modelo, a definição clara de tópicos que podem
gerar dúvidas, a atualização de norma referenciada, o alinhamento à legislação de Segurança
da Informação, a referência a outros normativos, o acréscimo de comandos normativos
importantes, o reposicionamento de instruções para tópicos mais adequados, a
reestruturação de tópicos, a ênfase em pontos específicos, a revisão textual de pontos
relevantes, a padronização dos modelos nos itens comuns, a importância do mapeamento de
riscos paras as exceções e a indicação de prazos para revisão dos modelos.

Dentre os riscos passíveis de ser mitigados a partir da implementação das medidas

recomendadas pela consultoria, merecem destaque a utilização de termos inadequados ou
contrários aos padrões já estabelecidos no governo, a ausência de comandos importantes
para o tema trabalhado, as dúvidas decorrentes de diretrizes confusas, a utilização de
normativo desatualizado, o desalinhamento do modelo com as normas de Segurança da
Informação e a falta de padronização entre os modelos.

36
Pode-se observar, portanto, conforme conclusões da própria SGD registradas nas
manifestações em anexo, que as contribuições da presente consultoria foram fundamentais
para melhoria e aderência dos modelos de políticas propostos pela SGD às melhores práticas
e ao arcabouço normativo existente sobre o tema em questão. Merecem destaque os
modelos referentes às políticas de Gestão de Ativos e Gerenciamento de Vulnerabilidades,
para os quais todas as sugestões feitas pela equipe da CGU foram aceitas e incorporadas à
minuta da política. Quanto aos outros três, apenas uma contribuição em cada, de modo
excepcional, não pode ser aproveitada. No total, foram elaboradas 88 sugestões, das quais a
Unidade aderiu a 96% aproximadamente, demonstrando a grande contribuição da consultoria
ao PPSI.

37
ANEXOS
I. Manifestação da Unidade
I.I. Quanto aos Modelos de Política de Controle de Acesso, de Gestão de Ativos
e de Backup e Restauração de Dados Digitais:
A Secretaria de Governo Digital apresentou, por meio da Nota Técnica SEI nº 18581/2022/ME,
de 05 de maio de 2022, a seguinte manifestação:
“SUMÁRIO EXECUTIVO
1. A presente Nota Técnica apresenta análise e comentários sobre as contribuições da
Controladoria-Geral da União (SEI-ME nº 23792121) a respeito da elaboração dos Modelos
de Política de Backup e Restauração de Dados Digitais, Controle de Acessos e Gestão de
Ativos, inseridos no Programa de Privacidade e Segurança da informação (PPSI).
2. Em breve síntese, os órgãos da SGD concordam com as conclusões da Nota Técnica 01 da
Consultoria de nº 1168823, elaborada pela CGU. Constata-se que as contribuições da equipe
técnica do referido órgão de controle interno são de extrema importância para o
aprimoramento do arcabouço institucional e normativo desta Secretaria, bem como auxiliam
a promover a segurança da informação dos órgãos e das entidades da administração pública
federal direta, autárquica e fundacional.
CONTEXTUALIZAÇÃO
3. O Departamento de Privacidade e Segurança da Informação, órgão integrante da Secretaria
de Governo Digital (anteriormente designado como Departamento de Governança de Dados e
Informações), deu início ao Programa de Privacidade e Segurança da Informação (PPSI) no
mês de dezembro de 2021.
4. O PPSI tem como objetivo cumprir as atribuições da Secretaria de Governo Digital em
matéria de segurança da informação, privacidade e proteção de dados, na forma do Decreto
nº 9.745, de 8 de abril de 2019, e do Decreto nº 10.332, de 28 de abril de 2020. Note-se que o
PPSI segue em andamento e tem como objetivo elevar o grau de maturidade e resiliência em
privacidade e segurança da informação nos órgãos integrantes do Sistema de Administração
dos Recursos de Tecnologia da Informação (SISP) instituído pelo Decreto nº 7.579, de 11 de
outubro de 2011.
5. Em um primeiro momento, o programa tem priorizado e fomentado, dentre outras iniciativas,
o desenvolvimento de ações que garantam a observância de 5 (cinco) medidas emergenciais
referentes à área, que incluem a Política de Backup, a Gestão de Controle de Acessos, a Gestão
de Vulnerabilidades, o Inventário de Ativos e a Auditoria.
6. Visando a auxiliar os órgãos integrantes do SISP no desenvolvimento de estratégias para
estabelecer e aperfeiçoar processos relacionados aos 5 (cinco) controles críticos supracitados,
a Coordenação-Geral de Proteção de Dados (CGPD) do Departamento de Privacidade e
Segurança da Informação desenvolveu, até o presente momento, 3 (três) modelos (templates)
de controles essenciais. Tais modelos foram enviados para avaliação da equipe da CGU e,
após análise e incorporação das contribuições, foram publicados na página do PPSI no site
Gov.br (https://www.gov.br/governodigital/pt-br/seguranca-e-protecao-de-dados/PPSI).
ANÁLISE
38
7. A presente nota técnica abordará as sugestões efetuadas sobre os Modelos de Política de
Backup e Restauração de dados, Controle de Acessos e Gestão de Ativos, formuladas pela
equipe técnica da CGU no referido documento (SEI nº 23792121), notadamente nos itens 3.1
a 3.3. Em cada caso, serão descritas as providências adotadas pela Secretaria de Governo
Digital:
8. Modelo de Política de Controle de Acesso:
8.1. Todas as sugestões feitas pela equipe da CGU foram aceitas e incorporadas à minuta da
política, exceto a sugestão que diz respeito à inclusão de diretrizes de controle de acesso físico,
conforme prevê o item 7 da Norma Complementar nº 7/IN01/DSIC/GSIPR1. Tal decisão foi
tomada levando-se em consideração a iminente revogação da referida norma complementar e
o objetivo de, para este momento, manter o enfoque em medidas de controle de acesso lógico,
conforme previsto no Anexo III do Programa de Privacidade e Segurança da Informação
(PPSI).
9. Modelo de Política de Gestão de Ativos:
9.1. Todas as sugestões feitas pela equipe da CGU foram aceitas e incorporadas à minuta da
política.
10. Modelo de Política de Backup e Restauração de Dados Digitais:
10.1. Todas as sugestões feitas pela equipe da CGU foram aceitas e incorporadas à minuta da
política, exceto a sugestão referente à elaboração de um template para um plano de
continuidade de negócios, conforme prevê o art. 12, inciso IV da IN GSI nº 1/2020. Tal decisão
foi tomada levando-se em consideração do objetivo de, para este momento, manter o enfoque
em medidas de preservação de dados mediante uma política específica de backup e restauração
de dados digitais, conforme previsto no Anexo III do Programa de Privacidade e Segurança
da Informação (PPSI).
CONCLUSÃO
11. Observa-se que as contribuições da equipe da CGATI/CGU foram fundamentais para
melhoria e aderência dos modelos de políticas propostos pela equipe da SGD às melhores
práticas e ao arcabouço normativo existente sobre o tema em questão.
12. Portanto, a SGD anui às sugestões propostas e as incorpora na forma proposta pela nota
técnica da CGU (SEI nº 23792121), com especial observância dos itens 3.1 a 3.3, com a
ressalva de que apenas 2 (duas) contribuições específicas não puderam ser incorporadas, em
decorrência dos motivos descritos nos itens 8.1 e 10.1 da presente Nota Técnica.
13. É mister ressaltar que os modelos publicados seguem em fase de produção contínua e
passarão por revisões periódicas com o propósito de adequação e aderência às melhores
práticas e aos normativos sobre os temas abordados.
14. Está em fase final de elaboração o modelo de política de gestão de vulnerabilidades. O
documento será enviado tempestivamente para avaliação e considerações da equipe da CGU.
RECOMENDAÇÃO
15. Diante do exposto, propõe-se o encaminhamento desta Nota Técnica à apreciação do
Secretário Adjunto de Governo Digital para subscrevê-la, caso esteja de acordo. Sugere-se,
ainda, a restituição dos presentes autos eletrônicos à Secretaria Especial de
Desburocratização, Gestão e Governo Digital para encaminhamento da manifestação desta
Secretaria de Governo Digital à Controladoria-Geral da União.”
39
I.II. Quanto ao Modelo de Política de Gerenciamento de Vulnerabilidades:
A Secretaria de Governo Digital apresentou, por meio da Nota Técnica SEI nº 32039/2022/ME,
de 22 de julho de 2022, a seguinte manifestação:

“SUMÁRIO EXECUTIVO
1. A presente nota técnica aborda as contribuições da CGU no âmbito do Modelo de
Política de Gerenciamento de Vulnerabilidades, elaborado no escopo do Programa de
Privacidade e Segurança da informação (PPSI) da Secretaria de Governo Digital do
Ministério da Economia (SGD/ME). Isso ocorre no contexto das competências normativas e
orientativas da SGD como Órgão Central do Sistema de Administração dos Recursos de
Tecnologia da Informação (SISP).
2. Em 24 de junho de 2022, a SGD encaminhou à CGATI/DG/SFC/CGU o modelo em
questão para coleta de contribuições do referido órgão de controle interno. Tal órgão remeteu,
em 08 de julho de 2022, a Nota Técnica 03 (26244363) da Consultoria de nº 1168823, que
contém as contribuições aqui analisadas.
3. No segundo tópico II da seção ANÁLISE, apresenta-se a análise por tópico das
contribuições enviadas pela CGU. Para facilitar o entendimento, elas foram dispostas em
forma de tabela da seguinte forma:
• Primeira coluna: apresentam-se os respectivos tópicos da Nota Técnica 03;
• Segunda coluna: resultado da análise realizada (acatado, acatado parcialmente, não
acatado);
• Terceira coluna: conteúdo do tópico da Nota Técnica 03, com a respectiva sugestão;
• Quarta coluna: apresenta-se de que modo a contribuição foi incorporada.

ANÁLISE

I. Análise geral
4. A CGU apresentou, no tópico 3.1. Política de Gerenciamento de Vulnerabilidade -
Orientações Iniciais, da Nota Técnica 03 (26244363), a seguinte observação.
“Orientações Iniciais
As orientações iniciais para utilização do modelo recomendam substituir os textos em cinza
itálico. Desta forma, recomenda-se revisar o documento colocando em itálico todos os textos
que deverão ser substituídos. No quadro introdutório, por exemplo, os textos da segunda coluna
não estão em itálico.”

5. Nesse sentido, a orientação em epígrafe, destacada no item 4 na presente nota técnica,

foi integralmente acatada pelo DPSI/SGD/ME.
6. No tópico 3.3 Escopo, a CGU apresentou como sugestão padronizar o termo
empregado para se referir à instituição no senti do genérico. Seguindo os guias operacionais
publicados pelo Departamento de Privacidade e Segurança da Informação da Secretaria de
Governo Digital, optou-se para ser uti lizado os termos “órgão ou entidade” tanto nos modelos
que virão a ser publicados quanto nos modelos que passarão por revisões ou atualizações no
futuro.
7. As demais contribuições da Nota Técnica 03 foram analisadas e incorporadas ao
documento e estão dispostas em forma de tabela no tópico II (Análise por tópicos).
40
II. Análise por tópicos
Resultado
Tópico da Proposta Forma de incorporação
avaliação
Optou-se por incluir o seguinte texto:
Data de revisão: Acrescentar
“Liste a data em que esta política deve passar por revisão e atualização.
no quadro introdutório, uma
3.1 Acatado Recomenda-se que seja definido um período de revisão da política, pelo
data para revisão e
menos um ano, ou quando houver alterações de normativos legais
atualização da política.
significativos sobre o tema.”
O texto a seguir foi inserido dentro do tópico Propósito antes do
Inserir no início, antes do exemplo:
exemplo, o texto introdutório “Levando em consideração natureza e finalidade do órgão ou da
3.2 Acatado padrão uti lizado nos outros entidade, descreva os fatores ou circunstâncias que determinam a
3modelos que orienta a existência da política de gerenciamento de vulnerabilidades. Além
elaboração do tópico. disso, informe os objetivos básicos da política e o que ela pretende
alcançar.”
O texto a seguir foi acrescentado dentro do tópico Escopo antes do
Escopo exemplo:
Inserir no início, antes do “Defina a quem e a quais sistemas esta política se aplica. Liste os
exemplo, o texto introdutório agentes públicos e colaboradores necessários para cumprir ou
3.3 Acatado
padrão utilizado nos outros 3 simplesmente indique “todos” se todos devem cumprir. Também
modelos que orienta a indique quaisquer exclusões ou exceções que estejam fora de escopo, ou
elaboração do tópico. seja, essas pessoas, elementos ou situações que não estejam cobertas
por esta política ou onde uma consideração especial possa ser feita.”
Disposições dos tópicos: Os A formatação do Sumário foi reescrita de forma com que o leitor tenha
tópicos Exceções e Público, ciência que Exceções e Público são subtópicos de Escopo.
3.3 Acatado
devem ser subtópicos do Além disso, optou-se por diminuir o tamanho da fonte de Exceções e
tópico Escopo. Público no modelo.
Exceções: Alertar aos órgãos
que as exceções precisam ser
O texto a seguir foi inserido no subtópico Exceções: “Importante
tratadas no mapeamento de
ressalvar que estas exceções precisam ser tratadas no mapeamento de
risco de segurança da
3.3 Acatado riscos de segurança da informação que o órgão ou entidade deve efetuar
informação em cumprimento
em cumprimento ao Capítulo III da Instrução Normativa GSI/PR Nº 3,
ao Capítulo III da Instrução
de 28 de maio de 2021.”
Normativa GSI/PR N° 3, de
28 de maio de 2021.
Optou-se por alterar a descrição do subtópico Público, pelo seguinte
Público: Harmonizar, para
texto: “Esta Política de Gerenciamento de Vulnerabilidade (PGV) [do
um mesmo entendimento, os
órgão ou entidade] se aplica a indivíduos responsáveis pela gestão e à
textos do primeiro parágrafo
3.3 Acatado indivíduos que utilizam qualquer Ativo de Informação da Rede
do tópico “Escopo” e do texto
Computadores em nome [do órgão ou entidade]. Além disso, essa
encontra dono subtópico
política se aplica a quaisquer provedores e entidades terceirizadas com
“Público”.
acesso às informações, redes e aplicativos [do órgão ou entidade].”
O texto foi corrigido para a forma correta de sua conjugação:
Ameaça: Corrigir o erro
3.4 Acatado “AMEAÇA – conjunto de fatores externos com o potencial de causarem
ortográfico do verbo causar.
dano para um sistema ou organização.”
Análise de Vulnerabilidades: Inserido o termo ANÁLISE DE VULNERABILIDADES, conforme
Inserir o termo ANÁLISE DE Portaria GSI/PR N°93 de 18 de outubro de 2021. “ANÁLISE DE
3.4 Acatado VULNERABILIDADES VULNERABILIDADES – verificação e exame técnico de
no tópico Termos e vulnerabilidades, para determinar onde estão localizadas e como foram
Definições. exploradas;”.
TESTE DE INVASÃO:
A Nota Técnica 03 (26244363), será apresentada a GSI com a sugestão
Recomenda-se a comunicação
de revisão para o termo PENTEST. O texto do termo
ao GSI para revisão do termo
TESTE DE INVASÃO foi atualizado: “TESTE DE INVASÃO –
3.4 Acatado PENTEST no Glossário de
metodologia para testar a eficácia e a resiliência de ativos através da
SIC. Sugere adotar o termo
identificação e exploração de fraquezas nos controles de segurança e
TESTE DEINVASÃO como
da simulação das ações e objetivos de um atacante.”
termo distinto.
Itens utilizados no texto:
Incluir os acrônimos CVE,
Optou-se por incluir os acrônimos CVE, CVSS e ID CVE, e o termo
3.4 Acatado CVSS e ID CVE, e o termo
NTP, conforme sugerido no tópico Termos e Definições.
NTP no tópico Termos e
Definições.
41
 Referenciar controles 07, 11
3.5 Acatado e18 do framework de Realizou-se a adequação da referência de acordo com o sugerido.
segurança cibernética CIS 8
Adequar a referência do
3.5 Acatado NISTCSF: SP 800-40 Rev. 4 e Adequou-se a referência de acordo com o sugerido.
Rev. 2
Inclui-se o link de acesso ao Guia de Gerenciamento de
Inserir como referência de
Vulnerabilidades, e foi inserido o seguinte texto no tópico
destaque o Guia de
Procedimentos Relevantes: "Um exemplo de documento que possuí
3.5 Acatado Gerenciamento de
procedimentos relevantes e que possa ser consultado é o Guia de
Vulnerabilidades no tópico
Gerenciamento de Vulnerabilidades presente na página de guias e
Procedimentos Relevantes.
modelos da SGD.”
Declarações da política.
As diretrizes se assemelham em parte à versão 2.0 do documento CSF:
Observar se as diretrizes ou
SP 800-40, porém outras fontes e referências, como por exemplo a
3.6 Acatado práticas não foram
versão 4.0 do mesmo documento, foram uti lizadas para criação das
substituídas ou atualizadas
melhores diretrizes ou práticas.
por instruções melhores.
Processo de gerenciamento de
vulnerabilidades e patches
(PGVP). Abordar o processo O termo “e Patches” foi retirada do título do tópico, e optou-se por
3.6 Acatado
de gerenciamento de forma Processo de gerenciamento de vulnerabilidade – (PGV).
geral, uma vez que está
implícita a gestão de patches.
Acrescentou-se como exemplo após os itens 7 e 8 o seguinte texto:
“Algumas métricas fundamentais que recomendamos, mas não
Métricas limitamos, de serem acompanhadas em uma estratégia de
Inserir uma diretriz para o gerenciamento de vulnerabilidade são: Cobertura, tempo de detecção,
3.6 Acatado
emprego de métricas para a tempo de permanência, tempo para contenção ou atenuação, número
melhoria contínua. médio de vulnerabilidade ao longo do tempo, eficiência no
gerenciamento de patches e resultados de correção em relação aos
SLAs da tabela de priorização de vulnerabilidades.”
Adequou-se o texto conforme padrão uti lizado pelo GSI/PR N° 01/2020,
Padronização
art. 10: “As métricas de gerenciamento de vulnerabilidades devem ser
Adequar o item 8 de acordo
3.6 Acatado definidas pelo [Comitê de Segurança da Informação ou estrutura
com Instrução Normativa
equivalente] e suas medições devem ser apresentadas a cada
GSI/PRNº 01/2020, art. 10.
[período].”
Realizou-se a adequação conforme sugerido nos itens 9 e 10.
“9. Um mapeamento de ativos de informação deve constar no escopo
do processo de gerenciamento de vulnerabilidades e patches para
Inventário de sistemas e
determinar qual marca, modelo e versão de equipamento de hardware,
ativos de informação
sistemas operacionais, banco de dados, sistema, servidor web e
Alterar o termo “inventário”
3.7 Acatado aplicativos de software são usados [no órgão ou entidade].”
para “mapeamento”,
“10. O mapeamento de ativos de informação deve ser
conforme o documento a IN
atualizado[periodicamente] ou sempre que ocorrerem alterações
GSI/PR nº03/2021.
significativas para garantir que os recursos informacionais estejam
cobertos pelo processo de gerenciamento de vulnerabilidades e patches
[do órgão ou entidade].”
Inventário de sistemas e
ativos de informação
Alterar o termo “programa de
gerenciamento de Adequou-se o texto “programa de gerenciamento de vulnerabilidade”
3.7 Acatado
vulnerabilidade” para para “processo de gerenciamento de vulnerabilidades (PGV).”
“processo de gerenciamento
de vulnerabilidades e patches
(PGVP)”.
Priorização e correção de Adicionou-se no texto como critério de avaliação o valor do ativo para
vulnerabilidades. o negócio:
Avaliar a possibilidade de “O tratamento de vulnerabilidades deve ser priorizado com base em sua
3.8 Acatado
adicionar como critério classificação de risco e criticidade, tempo esperado para correção, grau
priorização o de valor do de risco, impacto em caso de exploração e no valor que o ativo ou host
ativo para o negócio. impactado tem para o negócio [do órgão ou entidade].”
Realizou-se a inserção de novos valores na tabela de exemplo após o
Priorização e correção de
3.8 Acatado item 32. “Nível de severidade - muito crítico; Prazo de correção – até
vulnerabilidades.
[2 dias]; Descrição do risco – Condição totalmente inaceitável quando
42
 Adicionar o tratamento de medidas imediatas devem ser tomadas para eliminar a materialização
vulnerabilidade sobre do risco e mitigar perigos e impactos.”
sistemas críticos de alto valor
para o negócio.
Das exceções
Criou-se o item 38 com o seguinte texto: “A lista de exceções de ativos
Inserir uma diretriz sobre
3.9 Acatado de informação deve ter validade de [período], devendo ser revisada
revisão periódica das
após esse período.”
condições de exceção.
Realizou-se adequação do termo e optou-se pela inclusão do termo
Implementação e verificação
“Gestão de Mudanças nos aspectos relativos à Segurança da
das correções de
Informação” na seção Termos e Definições conforme Glossário de SIC,
vulnerabilidades.
Portaria GSI/PR N° 93.
Alterar o termo “processo de
3.10 Acatado “GESTÃO DE MUDANÇAS NOS ASPECTOS RELATIVOS À
gerenciamento de alterações
SEGURANÇA DAINFORMAÇÃO – processo estruturado que visa
da instituição” para
aumentar a probabilidade de sucesso em mudanças, com mínimos
“processo de gestão de
impactos, e assegurar a disponibilidade, integridade, confidencialidade
mudanças.
e autenticidade da informação.”

CONCLUSÃO
8. A presente nota apresentou uma avaliação acerca das contribuições da CGU sobre o
Modelo de Política de Gerenciamento de Vulnerabilidades (MPGV), bem como as referidas
contribuições foram incorporadas ao documento em questão. Destacando-se que as valorosas
contribuições trazidas pela CGU foram integralmente acatadas pela SGD/ME.

RECOMENDAÇÃO
9. Sugere-se que o Departamento de Privacidade e Segurança da Informação (DPSI)
encaminhe uma resposta formal à CGU acerca das providências adotadas pela Coordenação-
Geral de Proteção de Dados (CGPD/DPSI/SGD/SEDGG/ME).”

I.III. Quanto ao Modelo de Política de Gestão de Registros (Logs) de Auditoria -

(PGRA):
A Secretaria de Governo Digital apresentou, por meio da Nota Técnica SEI nº 39999/2022/ME,
de 15 de setembro de 2022, a seguinte manifestação:
“SUMÁRIO EXECUTIVO
1. A presente nota técnica aborda as contribuições da CGU no âmbito do Modelo de
Política de Gestão de Registros (Logs) de Auditoria - (PGRA), elaborado no escopo do
Programa de Privacidade e Segurança da informação (PPSI) da Secretaria de Governo Digital
do Ministério da Economia (SGD/ME). Isso ocorre no contexto das competências normativas
e orientativas da SGD como Órgão Central do Sistema de Administração dos Recursos de
Tecnologia da Informação (SISP).
2. Em 20 de julho de 2022, a SGD encaminhou à CGATI/DG/SFC/CGU o modelo em
questão para coleta de contribuições do referido órgão de controle interno. Tal órgão remeteu,
em 19 de agosto de 2022, a Nota Técnica 04(27489700) da Consultoria de nº 1168823, que
contém as contribuições aqui analisadas.
3. No segundo tópico II da seção ANÁLISE, apresenta-se a avaliação por tópico das
contribuições enviadas pela CGU. A fim de facilitar o entendimento, as referidas contribuições
foram dispostas em formato de tabela da seguinte maneira:
• Primeira coluna: apresentam-se os respectivos tópicos da Nota Técnica 04;

43
 • Segunda coluna: resultado da análise realizada (acatado, acatado parcialmente, não
acatado);
• Terceira coluna: conteúdo do tópico da Nota Técnica 04, com a respectiva sugestão;
• Quarta coluna: apresenta-se de que modo a contribuição foi incorporada.

ANÁLISE

I. Análise geral
4. A CGU apresentou, no tópico 3.2. Política de Gestão de Registros (Logs) de Auditoria
– PGRA, Orientações Iniciais, da Nota Técnica 04 (27489700), a seguinte observação.
“Orientações Iniciais
As orientações iniciais para utilização do modelo recomendam substituir os textos em cinza
itálico. Desta forma, recomenda-se revisar o documento colocando em itálico todos os textos
que deverão ser substituídos. No quadro introdutório, por exemplo, os textos da segunda coluna
não estão em itálico.”
5. Nesse senti do, a orientação em epígrafe, destacada no item 4 na presente nota técnica,
foi integralmente acatada pelo DPSI/SGD/ME.
6. As demais contribuições da Nota Técnica 04 foram analisadas e incorporadas ao
documento e estão dispostas em forma de tabela no tópico II (Análise por tópicos).

II. Análise por tópicos

Resultado da
Tópico Proposta Forma de incorporação
avaliação
Foi inserido em “Termos e Definições” o conceito de Log, sendo
assim, foi suprimido do tópico “Esclarecimentos” a definição do
Esclarecimentos: Transferir o
termo LOG.
conceito de Log para o tópico
No último parágrafo do tópico “Introdução” o seguinte texto foi
“Termos e Definições”; Sobre
acrescentado: “Muitos logs dentro de um órgão ou entidade contém
3.1 Acatado o parágrafo que faz referência
registros relacionados à segurança dos ativos de informação. Esses
a Log, compor o texto com o
logs são gerados por muitas fontes, incluindo: software de segurança,
último parágrafo do tópico
como software antivírus, firewalls e sistemas de prevenção e detecção
“Introdução”.
de intrusão; sistemas operacionais em servidores, estações de
trabalho e equipamentos de rede e aplicações.”
Optou-se por incluir o seguinte texto: “Liste a data em que esta
Data de revisão: Acrescentar
política deve passar por revisão e atualização. Recomenda-se que
no quadro introdutório, uma
3.2 Acatado seja definido um período de revisão da política, pelo menos um ano,
data para revisão e atualização
ou quando houver alterações de normativos legais significativos
da política.
sobre o tema.”
Inseriu-se dentro do tópico “Propósito” antes do exemplo o seguinte
Propósito: Inserir no início,
texto: “Levando em consideração a natureza e a finalidade do órgão
antes do exemplo, o texto
ou da entidade, descreva os fatores ou circunstâncias que determinam
3.3 Acatado introdutório padrão utilizado
a existência da Política de Gestão de Registro de Auditoria – PGRA.
nos outros 4 modelos que
Além disso, informe os objetivos básicos da política e o que ela
orienta a elaboração do tópico.
pretende alcançar.”
O texto a seguir foi acrescentado dentro do tópico “Escopo” antes do
exemplo: “Defina a quem e a quais sistemas esta política se aplica.
Escopo: Inserir no início, antes
Liste os agentes públicos e colaboradores necessários para cumprir
do exemplo, o texto
ou simplesmente indique "todos" se todos devem cumprir. Também
3.4 Acatado introdutório padrão utilizado
indique quaisquer exclusões ou exceções que estejam fora de escopo,
nos outros 4 modelos que
ou seja, essas pessoas, elementos ou situações que não estejam
orienta a elaboração do tópico.
cobertas por esta política ou onde uma consideração especial possa
ser feita.”
Optou-se por se manter a referência sobre serviços de TI críticos, pois
Serviços de TI críticos:
Acatado não são todos os órgãos que têm definidos seu(s) sistema(s) de TI
3.4 Reavaliar a pertinência de
Parcialmente crítico(s). Porém, acrescentamos o seguinte texto de forma
trazer o estabelecimento de
explicativa: “A seguir são consideradas duas opções de texto uma

44
 serviços de TI críticos dentro para caso o órgão já possua o mapeamento dos sistemas críticos e
do tópico “Escopo”. outra para caso o órgão não possua esse documento de mapeamento
dos sistemas críticos.
Opção 1:
Já ficam previamente estabelecidos como serviços e sistemas críticos
do [órgão ou entidade] os relacionados em [nome do documento que
possui a seleção de sistemas críticos].
Opção 2:
Já ficam previamente estabelecidos os [citar tipo ou nome dos
processos ou sistemas críticos], como serviços críticos do [órgão ou
entidade].”
Exceções: Alertar aos órgãos O seguinte texto foi inserido: “É importante salientar que tais
que exceções precisam ser exceções precisam ser tratadas no mapeamento de riscos de
3.4 Acatado tratadas no mapeamento dos segurança da informação que o órgão ou a entidade deve efetuar em
riscos de segurança da cumprimento ao Capítulo III da Instrução Normativa GSI/PRNº 3, de
informação. 28 de maio de 2021.”
Público: Harmonizar os textos Optou-se por alterar o texto do tópico “Público” para atender todas
para qual a política é aplicada as propostas, segue o novo texto: “Esta Política de Gestão de
nos tópicos “Escopo” e Registro de Auditoria – PGRA se aplica aos ativos informacionais [do
“Público”; órgão ou entidade], incluindo funcionários, gestores, prestadores de
Não restringir a política a serviços e contratados que tenham acesso e ou os utilize, com
3.4 Acatado
equipes de redes; responsabilidades específicas a indivíduos atuantes na gestão,
Ao tratar os provedores e processo e desenvolvimento em nome [do órgão ou entidade]. Além
empresas terceirizadas, o texto disso, essa política se aplica, nos limites estabelecidos
não considerou as contratualmente, a quaisquer provedores e entidades terceirizadas
especificidades contratuais. com acesso aos ativos de informação [do órgão ou entidade]. ”
Alterou-se no tópico “Termos e Definições” a definição atualizada
do termo Ativos de Informação: “meios de armazenamento,
transmissão e processamento da informação, equipamentos
Termos e Definições: Ativos de
3.5 Acatado necessários a isso, sistemas utilizados para tal, locais onde se
Informação desatualizado;
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.”
Alterou-se no tópico “Termos e Definições” a definição na sua
integralidade do termo Incidente Cibernético: “Ocorrência que pode
comprometer, real ou potencialmente, a disponibilidade, a
integridade, a confidencialidade ou a autenticidade de sistema de
informação ou das informações processadas, armazenadas ou
transmiti das por esse sistema. Poderá também ser caracterizada pela
tentativa de exploração de vulnerabilidade de sistema de informação
que caracterize violação de norma, política de segurança,
Termos e Definições: Incidente
procedimento de segurança ou política de uso. De maneira geral, os
Cibernético não está em sua
tipos de atividade comumente reconhecidas como incidentes
3.5 Acatado integralidade conforme
cibernéticos são: a)tentativas de obter acesso não-autorizado a um
definido pela Portaria
sistema ou a dados armazenados; b)tentativa de utilização não-
GSI/PRn°93/2021;
autorizada de sistemas para a realização de atividades de
processamento ou armazenamento de dados; c) mudanças não-
autorizadas de firmware, hardware ou software em um ambiente
computacional; d) ataques denegação de serviço (DoS); e e) demais
ações que visem afetar a disponibilidade ou integridade dos dados.
Um incidente de segurança cibernética não significa necessariamente
que as informações já estão comprometi das; significa apenas que a
informação está ameaçada;”
Termos e Definições: LOG
O termo LOG (Registro de Auditoria) foi inserido no tópico “Termos
(Registro de Auditoria), inserir
3.5 Acatado e Definições”, com a seguinte definição: “registro de eventos
o termo conforme consta na
relevantes em um dispositivo ou sistema computacional.”
Portaria GSI/PR n°93/2021;
Alterou-se a definição do termo Trilha de Auditoria, no tópico
Termos e Definições: Alterar a
“Termos e Definições” para: “registro ou conjunto de registros
definição do termo Trilha de
3.5 Acatado gravados em arquivos de log ou outro tipo de documento ou mídia,
Auditoria, conforme consta na
que possam indicar, de forma cronológica e inequívoca, o autor e a
Portaria GSI/PR n°93/2021;
ação realizada em determinada operação, procedimento ou evento.”

45
 Optou-se por incluir os acrônimos e o termo conforme sugerido no
tópico “Termos e Definições”: “HOST - Um computador ou
dispositivo de TI (por exemplo, roteador, switch, gateway, firewall);”,
Termos e Definições: Inserir
“NTP (Network Time Protocol) – Protocolo de Tempo para Redes.”
3.5 Acatado itens utilizados no texto, como
e “RISCO – No sentido amplo, trata-se da possibilidade de
HOST, NTP e RISCO;
ocorrência de um evento que pode impactar o cumprimento dos
objetivos. Pode ser mensurado em termos de impacto e de
probabilidade.”
Referência legal e de boas
práticas: Incluir a referência
3.6 Acatado NC n°21/IN01/DSIC/GSIPR, Inseriu-se a referência de acordo com o sugerido.
no tópico “Referência legal e
de boas práticas.”
Referenciar controles03, 13 e
3.6 Acatado 17 do framework de segurança Realizou-se a adequação da referência de acordo com o sugerido.
cibernética CIS 8
Processo de gestão de registros
Não há referência que indique a ordem das fases definidas (Coleta,
de auditoria: Inserir referência
Armazenamento, Uso e Exclusão). A equipe técnica de elaboração do
apresentado no tópico
3.6 Não Acatado documento, após algumas reuniões, decidiu-se por organizar a
“Declarações da Política”, o
Gestão de registros de auditoria na ordem apresentada, pois
qual foi apresentado em quatro
entendeu que ficaria mais didático e compreensível para o leitor.
fases.
Criou-se o subtópico “Fases da gestão de registro de auditoria”
Gestão de registros de dentro do tópico “Declarações da política”, além disso, a formatação
auditoria: Criar um subtópico do Sumário foi reescrita de forma com que o leitor tenha ciência que
dentro de “Declarações da “Fases da gestão de registro de auditoria”, “Coleta”,
3.7 Acatado
política”, para registraras “Armazenamento”, “Uso” e “Exclusão” são subtópicos de
fases da gestão de registros de “Declarações da política”. Optou-se também por diminuir o tamanho
auditoria; da fonte de “Fases da gestão de registro” e Coleta”,
“Armazenamento”, “Uso” e “Exclusão” no modelo.
Declarações da política:
Premissas e responsabilidades
Inserir na primeira diretriz
como responsáveis pela
3.8 Acatado Optou-se por seguir o proposto e a diretriz foi retirada do documento.
atividade de auditoria,
gestores de sistemas, área de
tecnologia e prestadores de
serviços.
Inseriu-se as três diretrizes conforme sugerido: “Os eventos de log
devem ser gerados, selecionados e armazenados para todos os
Declarações da política:
ativos.”
Premissas e responsabilidades.
3.8 Acatado “A [equipe responsável] deve selecionar os eventos e os respectivos
Acrescentar três novas
tempos de guarda, bem como as demais características de uso dos
diretrizes;
eventos.”
“As exceções deverão ser documentadas. ”
Declarações da política:
Requisitos do plano de
registros de auditoria. Utilizar
Adicionou-se a seguinte premissa: “Uti lizar o horário de Greenwich
o horário de Greenwichem
3.8 Acatado em sistemas hospedados em provedores de nuvem onde o fuso local
sistemas hospedados em
pode ser diferente do fuso do provedor.”
provedores de nuvem, onde o
fuso local pode ser diferente do
fuso do provedor.
Adequou-se o texto conforme sugerido: “Para melhorar o nível de
maturidade desta atividade, é importante que o órgão ou entidade
Declarações da política:
consiga coletar os logs de auditoria de forma detalhada, e tais logs
Coleta. Incluir dados
3.8 Acatado tenham dados importantes como data, hora de criação, atualização,
mencionados no CIS controle
permissões, nome do usuário, origem do evento, endereços de origem,
8.5
endereços de destino e outros elementos úteis que podem ajudar em
uma investigação forense.”
Declarações da política: Adicionou-se o seguinte texto conforme sugerido: “A não
Coleta. Incluir sanções observância da conformidade do item 21, pode acarretar prejuízos
3.8 Acatado
administrativas conforme Art. financeiros e reputacionais, além das sanções administrativas
52 da LGPD. relacionadas no art 52 da LGPD. ”
46
 Adequou-se o texto: “A transferência de logs, também conhecida
como off -loading, é um processo comum em sistemas com capacidade
limitada de armazenamento de logs e, portanto, oferece suporte à
disponibilidade dos logs. O armazenamento de log inicial é usado
Declarações da política: apenas de forma transitória até que o sistema possa se comunicar
Armazenamento Especificar como sistema secundário ou alternativo alocado para
3.8 Acatado que a transferência de logs seja armazenamento de log, momento em que os logs são transferidos. A
realizada por meio de transferência de logs para armazenamento alternativo, deve ser feita
comunicação segura. para um ativo de informação que esteja em uma rede lógica, ou física
diferente, com o propósito de proteger a confidencialidade e
integridade dos registros de auditoria, para isso, tal transferência
convém ser realizada por meio de comunicação segura
(criptografada).”
Adicionou-se no texto explicativo do tópico “Armazenamento” o
seguinte texto e link para tabela do CONARQ: “Esteja ciente de que
a alocação de capacidade de armazenamento de log sufi ciente reduz
a probabilidade de tal capacidade ser excedida e resultar na perda
ou redução potencial da capacidade de log.
Importante ressaltar que no momento de definir o período de retenção
Declarações da política:
dos logs é indicado verificar:
Armazenamento Referenciar
· A existência de definição legal de tempo de
tabela de temporalidade de
3.8 Acatado retenção/guarda/arquivamento de documentos e/ou dos dados
guarda para ativos de
tratados pelo órgão e/ou entidade para os quais os logs foram
informação do órgão;
gerados; e.
Referenciar a LGPD, Art. 16;
· Tabela de temporalidade do CONARQ1.”
Adicionou-se a seguinte diretriz para fazer referência ao Art. 16 da
LGPD conforme sugerido: “No caso de os logs armazenados
contiverem dados pessoais, deve-se observar o previsto pelo art. 16
da LGPD a fim de avaliar se os logs devem ser eliminados ou
conservados após o término do tratamento dos dados pessoais.”
Declarações da política: Uso:
3.8 Acatado Retirou-se do documento as diretrizes conforme sugerido.
Suprimir os itens 39 e 46;
Declarações da política: Uso: Adequou-se a diretriz conforme sugerido: “Quando suportado,
3.8 Acatado Inserir expressão “quando convém que o acesso a sistemas críticos por terceiros seja monitorado
suportado” na diretriz52. quanto a atividades não autorizadas ou incomuns.”

CONCLUSÃO
7. A presente nota apresentou uma avaliação acerca das contribuições da CGU sobre o Modelo
de Política de Gestão de Registros (Logs) de Auditoria, bem como as referidas contribuições
foram incorporadas ao documento em questão, à exceção da sugestão proposta para o
Processo de Gestão de registros de auditoria mencionado pelo tópico 3.6, a qual não foi
acatada.
RECOMENDAÇÃO
8. Sugere-se que o Departamento de Privacidade e Segurança da Informação (DPSI)
encaminhe uma resposta formal à CGU acerca das providências adotadas pela Coordenação-
Geral de Proteção de Dados (CGPD/DPSI/SGD/SEDGG/ME).

47