Resumo

  • O plano de segurança do RIPE NCC para o terceiro trimestre de 2026 agrupa quatro itens “Em andamento”: auditorias e normas, risco e GRC, segurança de aplicações e testes de intrusão, monitoramento e serviços gerenciados.
  • Cada item produz uma espécie de evidência. Um parecer de auditoria não aceita risco; uma correção não prova sua própria eficácia; um alerta não equivale a um incidente confirmado.
  • A transparência adequada seria um registro versionado de repasses, com afirmação limitada, escopo, prova recebida, funções de entrega e aceite, exceção sem detalhe explorável e prazo de nova verificação.

O status “Em andamento” tem uma virtude: não promete um resultado antes da hora. Também tem um defeito: cabe nele praticamente qualquer coisa entre o primeiro e-mail e a decisão final.

No planejamento de Information Security, Risk and Compliance do RIPE NCC, atualizado em 11 de junho de 2026, quatro trabalhos recebem esse mesmo rótulo. O primeiro cobre atividades de auditoria externa no terceiro e no quarto trimestre para o relatório SOC 2 Type II do serviço RPKI, além da continuidade de ISO 27001, do tratamento de recomendações da auditoria interna e da preparação da auditoria de certificação. O segundo reúne a avaliação anual de riscos e a entrada de uma plataforma de governança, risco e conformidade. O terceiro amplia recursos de segurança de aplicações e cria a base de um programa de testes de intrusão.

O quarto expande ferramentas de monitoramento e prevê a contratação de serviços de segurança gerenciados.

Essa página declara sua finalidade: dar transparência ao trabalho, receber contribuições, registrar sugestões que alterem o planejamento e sustentar conversa com membros e comunidade. Ela não é um relatório de asseguração. Tampouco deveria virar um inventário de controles ou uma lista de riscos. O fato de não trazer dados sensíveis é uma característica sensata, não uma falha.

Há, porém, uma informação que pode ser pública sem abrir o cofre: quando a evidência produzida em uma frente passa a ser insumo aceito por outra?

O relatório tem período; a marca parece não ter

O caso do RPKI mostra o problema. O relatório anual de 2025 diz que o RIPE NCC recebeu em dezembro daquele ano um relatório SOC 2 Type II para o serviço, após um Type I em 2024. O plano de 2026 informa que a atividade Type II será anual. A página do terceiro trimestre anuncia trabalho externo ao longo de Q3 e Q4. São etapas compatíveis: há um relatório concluído para um período anterior e um novo ciclo em execução.

Uma expressão como “SOC 2 Type II” perde precisão quando viaja sem a data e o escopo. O relatório não é uma garantia permanente de todos os serviços. Por outro lado, o início do ciclo seguinte não invalida o trabalho anterior. O repasse a registrar é temporal: período examinado, categorias de observações ou melhorias levadas adiante, função que trata e aceita exceções, evento que permite atualizar a afirmação pública e data em que ela precisará ser renovada.

ISO 27001 obedece a outro relógio. Em junho, o RIPE NCC dizia trabalhar nas recomendações de auditoria interna e planejar a auditoria de certificação. O plano anual estabelece a meta de obter a certificação. Uma recomendação pode estar aberta, atribuída, executada ou verificada. Uma organização pode estar pronta para a auditoria sem que o organismo certificador tenha decidido. “Em andamento” não prova atraso e não significa reprovação. Só não diz qual desses estados está valendo.

Não é preciso revelar uma recomendação para melhorar a informação. O registro público pode indicar “tratamento de recomendações em verificação”, “auditoria de certificação agendada”, “auditoria realizada” ou “decisão recebida”, junto do escopo declarado. A segurança mora no conteúdo técnico; a responsabilização mora na autoridade e na data da mudança.

GRC organiza a memória, não escolhe o risco

A segunda linha associa a avaliação anual à implantação de uma plataforma GRC. A plataforma pode reunir responsáveis, evidências, versões, vencimentos e aprovações. Esse é um ganho real: decisões deixam de depender da caixa postal de alguém. Mas o software não tem apetite a risco. Ele não escolhe qual exposição residual uma associação de membros deve suportar.

As atas do Conselho dão uma visão limitada, porém útil, dessa autoridade. Na reunião 189, a gestão informou que 80% dos planos de tratamento de risco haviam sido executados no prazo e que nenhum incidente material de segurança fora reportado. O Conselho aprovou declarações revisadas de apetite a risco. Na reunião 194, em junho de 2026, recebeu atualização sobre riscos altos, tratamentos e o desdobramento do apetite aprovado em dezembro de 2025.

As atas não mostram o registro de riscos nem os controles. Isso não prova que o material inexista, muito menos que algo tenha sido escondido. Mostra uma fronteira: é possível publicar quem supervisiona e qual autoridade aprovou a regra sem publicar a fraqueza que está sendo tratada.

O teste para a GRC é preservar a procedência das decisões. Quando uma observação de auditoria vira tratamento, o vínculo continua visível? Quando uma aplicação recebe exceção, a aceitação vem com autoridade e vencimento? Quando o monitoramento encontra uma lacuna, ela entra na avaliação anual ou fica apenas como tarefa técnica? Uma plataforma pode ter dados completos e ainda assim perder o sentido se cada área atualizar seu próprio campo sem registrar o aceite do destinatário.

Fechar o tíquete não fecha a exposição

Na segurança de aplicações, a diferença entre etapas é operacional. Uma ferramenta encontra um possível defeito. Uma pessoa o qualifica no contexto do serviço. Um time produz uma correção. A correção entra numa versão e é implantada. Outra verificação demonstra se o comportamento indesejado desapareceu. Qualquer risco restante exige aceitação com prazo.

O scanner não é dono do risco. O desenvolvedor não se torna verificador independente só porque mudou o código. O pentest pode revelar uma falha, mas não tem autoridade para aceitar a consequência operacional. Por isso, faz sentido que o plano mencione tanto identificar e remediar quanto estabelecer um programa de testes de intrusão.

O repasse público pode ser descrito por classes. Qual função recebe o achado? Qual regra de severidade é aplicada? Qual fronteira de versão contém a correção? A verificação é separada da implementação? Quem aceita a exceção e até quando? Nenhuma resposta exige publicar o componente, o endpoint, a exploração ou a configuração compensatória.

Há ainda um repasse para o risco institucional. Exceções de aplicativos não podem permanecer para sempre em uma fila técnica sem alimentar a visão anual. Um processo de desenvolvimento bem desenhado e um registro de riscos bem desenhado podem coexistir sem conversar. O mapa público deve apenas demonstrar que existe a ponte e nomear a função que recebe; o conteúdo da travessia continua protegido.

Um fornecedor monitora; a instituição responde

A quarta linha também junta duas coisas. Expandir cobertura é observar mais do ambiente relevante. Contratar um serviço gerenciado é decidir quem ajudará a observar, correlacionar ou escalar. O fornecedor pode operar ferramentas e turnos. Não pode retirar do RIPE NCC a responsabilidade por confirmar um incidente, comunicar o estado do serviço e encerrar o tratamento.

A página da linha de emergência técnica já oferece um contorno público. O RIPE NCC diz monitorar 24 horas por dia serviços críticos: RIPE Database, K-root, DNS e DNS reverso, LIR Portal, RPKI e seus sites. Depois de confirmar um incidente, atualiza a página de anúncios de serviço. O termo “confirmar” mostra que o alerta não se publica sozinho.

O mapa de repasses poderia esclarecer quem recebe o alerta de um prestador, qual função decide pela confirmação, como uma lição de incidente se transforma em ação de aplicação e quando uma falha de cobertura vira tratamento de risco. As regras de detecção, os ativos internos e a rota detalhada de escalonamento devem ficar fora da versão pública.

A política de divulgação responsável é outra porta. O RIPE NCC afirma que buscará avaliar o relato e dar uma data esperada de solução em até três dias úteis. Depois de um problema importante resolvido, poderá publicar um relatório caso a caso. Isso é um compromisso de acolhimento e comunicação com o pesquisador, não uma opinião de auditoria e não uma promessa de publicar tudo. O achado validado precisa seguir para o dono do serviço, a decisão de tratamento e a evidência de fechamento.

Não há uma única vitrine de segurança

O ecossistema público já é composto de várias superfícies. O planejamento trimestral mostra trabalho e convida a comentários. O plano anual apresenta compromissos, equipes e orçamento. Atas registram supervisão e decisões. O Trust Portal reúne informações de conformidade e asseguração. A página de status trata de eventos operacionais confirmados. A divulgação responsável protege a entrada de uma descoberta.

Os termos do serviço de certificação RPKI deixam essa divisão explícita. Informações sobre políticas e medidas de segurança devem aparecer no Trust Portal; relatórios disponíveis de verificações ou auditorias podem ser compartilhados com titulares de certificados, mediante solicitação e acordo de confidencialidade. A escolha não é entre contar tudo e contar nada. É possível publicar uma afirmação limitada e manter sua prova detalhada sob acesso adequado.

Cada canal atende uma necessidade. O pesquisador quer sigilo e resposta rápida. O operador em pane quer uma atualização atual. O membro que avalia a instituição quer escopo, período e base da garantia. O Conselho precisa ver riscos e tratamentos que seriam perigosos fora da sala. A solução não é fundir as superfícies, mas fazê-las apontar umas para as outras.

“Relatório Type II recebido em dezembro de 2025” deve levar ao período correspondente. “Novo ciclo anual em andamento” deve carregar o novo intervalo. “ISO 27001 em andamento” deve dizer se a etapa é recomendação, auditoria ou decisão. “Monitoramento ampliado” deve informar a família de serviços e a data de aceite. “GRC operacionalizada” deve se limitar às classes de risco, controle, tratamento e evidência efetivamente migradas e recebidas.

Um orçamento distribuído exige evidência distribuída

O Plano de Atividades de 2026 prevê nove equivalentes de tempo integral e 2,8 milhões de euros para Information Security, Risk and Compliance. Entre as principais despesas estão 1,03 milhão de euros em tecnologia e 470 mil em consultoria. Esses números são planejamento, não prova de gasto realizado ou de resultado.

O mesmo documento distribui trabalho de segurança e normas por RPKI, RIPE Database, DNS e K-root, LIR Portal e suporte de TI. A área central pode definir o método e consolidar a visão; equipes de serviço implementam boa parte dos controles e produzem a evidência. Um projeto pode terminar em um orçamento e continuar aberto na interface com outra equipe.

É por isso que a entrega importa mais que a atividade. A auditoria depende da operação. O tratamento de risco depende do dono do serviço. O pentest depende de uma versão implantada. O monitoramento depende de uma autoridade de confirmação. O Conselho depende de uma agregação correta das exposições restantes. A evidência só vira valor organizacional quando o destinatário a aceita ou registra por que não pode aceitá-la.

Dez campos, sem um novo painel

Um quadro versionado pode resolver o problema. Cada linha conteria:

  1. programa ou fluxo de trabalho;
  2. afirmação limitada que ele sustenta;
  3. serviço ou âmbito organizacional;
  4. função responsável;
  5. classe e data-base da evidência recebida;
  6. função que entrega;
  7. ato e autoridade de aceite;
  8. classe de exceção, sem detalhe explorável;
  9. data de expiração, renovação ou reteste;
  10. superfície pública onde a afirmação será atualizada.

Os substantivos grandes devem ser evitados. “Conformidade” não fecha nada. “Asseguração Type II do RPKI para o período e escopo declarados” pode ser testada. “Aplicação segura” não é uma conclusão sustentável. “Correções implantadas e verificadas por etapa separada, com exceções aceitas e datadas” possui condição de fechamento. “Monitoramento 24/7” precisa de fronteira de serviço e aceite.

O quadro público não levaria vulnerabilidades, configurações, documentos de trabalho, ativos internos, dados pessoais, cláusulas comerciais ou caminhos sensíveis de escalonamento. Ele se pareceria com um quadro de conexões de viagem, não com a planta da sinalização: mostra que há uma transferência, quem a confirma e quando ela precisa ocorrer novamente.

A objeção que deve moldar o desenho

Transparência de segurança em excesso pode ajudar atacantes e transformar remediação em teatro. A objeção é forte e deve limitar o quadro. Campos que só possam ser preenchidos com a explicação de um controle não pertencem à versão pública. Classes, escopos, datas e funções bastam.

Também é justo dizer que a página trimestral deve continuar curta. O registro detalhado pode residir no Trust Portal ou em anexo do relatório anual; a página de planejamento apenas aponta para a versão vigente. Assim, o leitor comum mantém a síntese e o profissional encontra a trilha.

Por fim, os repasses podem já existir internamente. A GRC, os arquivos de auditoria, o desenvolvimento seguro, a gestão de serviços e a supervisão do Conselho talvez estejam conectados com rigor. As fontes públicas examinadas não autorizam dizer o contrário. A proposta trata do que um membro consegue verificar entre afirmações públicas, não da qualidade presumida de controles privados.

Quatro estados “Em andamento” não revelam falha. Revelam que o trabalho de segurança cruza asseguração, governança, engenharia e operação. O avanço que importa acontece quando uma prova sai de uma frente, é recebida por outra, ganha uma decisão responsável e conserva sua data.

Fontes