Resumo

  • Uma restrição IODEF pode vir do elemento superior. Um filho pode substituí-la por uma condição mais rígida ou mais aberta; uma etiqueta geral não descreve todas as partes.
  • Extrair um contato sem alterar seus dados pode, ainda assim, eliminar a referência que delimitava seu compartilhamento.
  • O antigo amber de IODEF e o atual TLP:AMBER não têm exatamente o mesmo público. Uma conversão aparentemente visual pode incluir clientes no alcance da divulgação.

O melhor relatório para um parceiro nem sempre é o relatório completo. Às vezes, basta informar quem deve receber uma ligação ou confirmar que uma medida de mitigação foi tomada. Reduzir o volume compartilhado pode tornar a cooperação mais útil e menos invasiva. O problema surge quando o recorte elimina não só detalhes desnecessários, mas também a condição que explicava por que aquele trecho podia circular.

Imagine um contato incluído em um dossiê destinado a um grupo fechado de parceiros. O contato não tem uma instrução própria de divulgação; depende da orientação do dossiê. Ao levá-lo para um chamado, a ferramenta preserva nome, endereço e função. Se o contexto não acompanhar esses campos, o próximo leitor terá os fatos corretos, mas poderá não ter a regra necessária para interpretá-los. É uma hipótese sobre a estrutura do formato, não um defeito observado em um produto.

IODEF foi concebido para representar incidentes e indicadores de segurança de modo compreensível entre equipes operacionais. O RFC 7970, de novembro de 2016, define sua segunda versão e o modelo correspondente em XML. O registro oficial consultado o classifica como Proposed Standard. Padronizar a representação ajuda a trocar informações; não torna cada fragmento independente das relações que o cercam. RFC 7970, registro oficial.

A exceção pode abrir, não apenas fechar

Na seção 3.3.1, o atributo restriction transmite uma orientação do remetente sobre divulgação. Ela se aplica à classe que a contém e a seus filhos. Um filho pode sobrescrevê-la, tanto para restringir quanto para permitir um alcance maior. Quando o atributo está ausente, vale a herança do ancestral mais próximo que tenha especificado o valor. A regra geral atribui à classe Incident o padrão private.

Por isso, um Incident explicitamente private pode conter um Contact explicitamente public. A orientação local pode liberar aquele contato sem liberar o restante do dossiê. No sentido inverso, um relatório para parceiros pode conter um contato private. Esses exemplos descrevem a orientação que o remetente consegue expressar. Não comprovam que ele tenha todos os direitos necessários para divulgar a informação nem eliminam obrigações independentes. RFC 7970, seção 3.3.1.

Uma interface que mostra apenas a marca do nível superior pode esconder uma restrição interna. Já uma interface que aplica a marca mais rígida a tudo pode esconder uma exceção útil. A segunda opção pode ser uma política conservadora da organização receptora, mas não é a reprodução exata das condições de cada elemento. A escolha precisa ser reconhecida como escolha.

Isso importa para quem precisa cooperar durante uma resposta. Um contato publicável pode permitir que outro operador encontre a equipe certa sem receber detalhes reservados da investigação. Impedir automaticamente esse recorte transfere o trabalho para uma consulta manual ou faz a oportunidade se perder. Não há nesta pesquisa uma medição do atraso causado por esse mecanismo; há uma razão para não tratar a restrição máxima como uma solução sem custo.

Há dois caminhos por trás de um “padrão”

O valor explícito default merece atenção especial. Ele remete a uma política de divulgação combinada previamente entre as partes que se comunicam. Não equivale à ausência do atributo. Se o atributo falta, é preciso procurar a condição herdada na hierarquia. Se seu valor é default, é preciso saber qual acordo foi invocado. Registro Restriction da IANA.

Juntar ambos sob o rótulo “configuração padrão” de um aplicativo pode substituir essas referências por uma política local. Nenhum dado do incidente precisa ser adulterado para que isso aconteça. A mudança está na base usada para decidir quem pode receber a informação. Uma verificação que só compara os campos factuais não enxergará necessariamente o problema.

Também seria exagerado declarar resolvidas todas as descrições de valores padrão do RFC. A regra geral, algumas descrições de classes e o esquema exigem leitura conjunta cuidadosa. Este texto usa Contact e atributos explícitos, sem apoiar a explicação em omissões de EventData ou Expectation como se não houvesse dúvida. Um perfil de troca pode estabelecer valores claros e documentar uma interpretação comum; não deve se apresentar como uma correção oficial de todos os pontos do padrão.

A cor conhecida não dispensa a versão

O registro IANA mantém os antigos aliases de IODEF: white corresponde a public, green a partner, amber a need-to-know e red a private. Nesse vocabulário, need-to-know permite compartilhar dentro da organização com quem precisa saber. São as definições encontradas no registro durante a pesquisa. IANA.

O TLP 2.0 de FIRST, versão atual em vigor desde agosto de 2022, traça uma fronteira relevante diferente. TLP:AMBER admite o compartilhamento necessário para proteger a organização receptora e seus clientes, dentro desses dois grupos. TLP:AMBER+STRICT restringe o alcance à organização. A fonte pode acrescentar condições, e ampliar a circulação além do limite recebido requer autorização explícita dela. As etiquetas permanecem em sua forma original, mesmo em português. FIRST TLP 2.0.

Uma troca automática de amber por TLP:AMBER, sem qualificação, pode assim acrescentar clientes a uma audiência originalmente interna. A conclusão vem da comparação das definições; não demonstra vazamento, adoção de uma ferramenta ou falha já explorada. Tampouco estabelece uma tabela de conversão universalmente aprovada. Restrições adicionais e a definição da fronteira organizacional continuam relevantes.

É nesse ponto que uma tabela técnica ganha importância gerencial. Quem modifica a correspondência pode alterar o público permitido pela saída, mesmo sem editar um destinatário nominal. Classificar a tarefa como compatibilidade de formato não retira seu efeito sobre a divulgação. O responsável pela política precisa enxergar a mudança que o responsável pela integração está propondo.

Aceitar o arquivo não é entender toda a condição

O RFC 7970 não reduz validade semântica a um XML que passa no esquema. A seção 4.3 exige que o documento seja bem formado, recomenda conformidade com o esquema e manda considerar também as restrições adicionais do modelo de informação. Uma importação bem-sucedida não é, portanto, prova de que todas as condições operacionais foram compreendidas.

A errata técnica 5543, verificada em novembro de 2018, oferece um exemplo limitado dessa diferença. Ela corrige o esquema de Confidence para permitir o conteúdo numérico previsto no texto. A correção resolve uma inconsistência da representação, não o significado compartilhado de um número. A interpretação da confiança numérica permanece fora da definição do RFC. E essa errata não decide os padrões do atributo restriction. Errata 5543, RFC 7970.

Essa separação ajuda a distribuir o trabalho. Um erro de sintaxe pode pedir reparo técnico. Uma convenção desconhecida pede contato com quem definiu a política. Uma ambiguidade do texto normativo pede uma interpretação documentada e cautelosa. Reunir tudo em “dados inválidos” facilita a contagem, mas dificulta a solução.

O transporte termina antes da responsabilidade

IODEF exige confidencialidade, integridade e autenticidade no mecanismo de troca subjacente. Ao mesmo tempo, reconhece que a orientação de divulgação não possui uma garantia técnica de cumprimento pelo receptor. A análise de privacidade alcança relatórios armazenados, análises derivadas e informações sobre terceiros. Identificadores podem se tornar mais reveladores quando correlacionados ao longo de intercâmbios sucessivos. RFC 7970, seção 9.

O RFC 6545, sobre RID, discute acordos de privacidade e perfis de compartilhamento: que dados circulam, como são protegidos, até onde seguem e quais aprovações entram no processo. Também admite comunicar uma medida de mitigação sem revelar a identidade da origem do ataque. Nem sempre cooperar melhor exige revelar mais. Sua discussão da proteção por salto lembra ainda que cada conexão protegida não determina, sozinha, quem vê o conteúdo no trajeto completo. São considerações de projeto, não uma autorização jurídica atual para qualquer compartilhamento. RFC 6545, seções 9.5–9.6.

Uma consequência prática, proposta aqui como orientação editorial de operação, é revisar o recorte como saída. Deve ser possível explicar a restrição efetiva, sua origem e o acordo ou a versão de vocabulário utilizados. Não se atribui ao RFC um mecanismo obrigatório de auditoria que ele não define, nem se recomenda espalhar cópias integrais de material sensível. O objetivo é guardar o contexto suficiente para justificar a decisão.

A distinção de Lu Heng entre descrição simbólica e poder que produz efeitos ajuda a localizar essa decisão. A etiqueta representa a fronteira; o processo de extração, a aprovação do público e as práticas do receptor ajudam a fazê-la valer. O ensaio não analisa IODEF. Sua aplicação aqui é uma lente limitada para procurar o trabalho que a etiqueta, sozinha, não executa. Lu Heng sobre camadas da realidade.

Um bom recorte reduz o que não é necessário sem apagar o que permite usar o restante. A informação pode deixar o dossiê. A justificativa de seu compartilhamento precisa continuar alcançável.