Edição de 28/09: um aviso de segurança deve permitir ao destinatário agir

Escrever para quem recebe, não para quem publica

Esta edição dirige-se a segurança de produto, documentação e suporte de fabricantes. A pergunta é se um destinatário consegue agir corretamente a partir do aviso recebido. É uma proposta editorial retrospetiva, não uma comunicação sobre um produto afetado em 28 de setembro. Não contém versões, vítimas ou ocorrências inventadas.

O artigo 14.º, n.º 8, trata a informação aos utilizadores afetados e, quando apropriado, a todos os utilizadores, sobre vulnerabilidade ativamente explorada ou incidente grave de segurança do produto. Inclui medidas corretivas ou de atenuação relevantes e, quando apropriado, formato estruturado legível por máquina. O âmbito e as qualificações importam: não descreva cada aviso como mensagem obrigatória e idêntica para todo o público.

A notificação às autoridades não é o aviso ao cliente

A ENISA descreve a SRP como ferramenta para as notificações de fabricantes e, quando aplicável, stewards. Submeter informação por esse canal não deve ser apresentado como prova de que um utilizador recebeu instruções acionáveis. Este artigo não verifica entrega de nenhuma mensagem nem funcionamento de uma conta SRP.

Proposta Velqory: manter identificadores ligados, mas registos separados para reporte e aviso. O primeiro acompanha a relação com autoridades; o segundo guarda destinatários previstos, conteúdo aprovado, canal e alterações. Evite publicar detalhes que facilitem abuso apenas para demonstrar que a equipa técnica investigou o problema.

O mínimo operacional proposto

O aviso proposto responde a quatro perguntas: como reconhecer a versão afetada, que medida está disponível, que pré-requisitos ou efeitos operacionais existem e como confirmar a conclusão. Diga também o que permanece por esclarecer. Quando a medida é temporária, indique como o utilizador receberá a substituição ou a revisão, sem prometer um prazo que ninguém aprovou.

Não confunda instrução com garantia: «aplicar esta atualização» não prova que o destinatário a aplicou. Para cada passo, a equipa deve validar compatibilidade e oferecer um caminho de suporte conhecido. A linguagem simples não justifica esconder limitações, nem acrescentar precisão que a investigação ainda não permite.

Revisão por um destinatário de ensaio

Esta matriz original é uma proposta não testada. Use um leitor que conheça a operação, mas não tenha escrito o aviso, e um cenário autorizado sem dados de clientes. Peça que explique o que faria; não lhe forneça oralmente as instruções que o documento omitiu.

O aviso só diz para atualizar

Cenário hipotético: uma equipa recebe «atualize para a versão corrigida», mas não encontra forma de identificar a versão em uso e desconhece se a medida interrompe um serviço. O aviso falha a aceitação proposta mesmo que contenha uma descrição técnica rigorosa da vulnerabilidade.

A revisão editorial deve devolver perguntas concretas a engenharia, não preencher as lacunas por imaginação. Se ainda não existe uma correção disponível, diferencie esse estado de uma mitigação validada para o âmbito relevante. Se não existe instrução confirmada, declare a limitação e um canal de acompanhamento; não invente uma configuração supostamente segura.

O destinatário também precisa de prova

O NCSC britânico recomenda verificar medidas de reconfiguração ou mitigação e continuar a acompanhar soluções temporárias. É orientação técnica, não requisito de formato português. A adaptação Velqory é dar ao destinatário um critério de observação, compatível com a documentação do produto, sem o transformar num teste ofensivo.

Guarde versões do aviso e motivos de alteração. Se mudar o âmbito afetado ou a medida, reveja a mensagem anterior e o encaminhamento. A utilidade não está no número de destinatários declarado: está em permitir que a pessoa certa reconheça o problema, decida a ação e saiba que conclusão pode, ou não, retirar.