Uma atribuição falhada não prova que o atacante era anónimo
Um caso sem culpado identificado mostra o que as provas podiam estabelecer, não que o anonimato funcionou. Separe a orientação, a sua adoção e o fracasso da atribuição.
Um caso que termina sem um culpado identificado tende a ser descrito como anónimo, e essa palavra faz muito trabalho silencioso. Converte uma afirmação sobre provas numa afirmação sobre o mundo. As duas não são a mesma coisa, e em incidentes antigos a diferença é muitas vezes a única coisa que o registo sobrevivente pode sustentar. Um incidente não atribuído diz-lhe o que podia ser estabelecido, não o que era possível.
Cinco verificações mantêm as duas coisas separadas.
Verificação 1: separe a orientação da sua adoção
O RFC 1281, publicado em novembro de 1991, recomendava conservar e auditar registos relevantes para a segurança, apoiar o rastreio de ligações e nomear um contacto de segurança para tratar incidentes. Pedia também aos operadores que publicassem o que recolhiam e quem o podia usar. É um registo datado do que era recomendado, o que é uma afirmação diferente do que fez qualquer rede concreta.
Uma recomendação é prova de que a preocupação existia. Não é prova de implementação e certamente não é prova de que uma investigação concreta tenha tido sucesso.
Verificação 2: nomeie qual elo da atribuição se quebrou
A atribuição é uma cadeia, e cada elo falha à sua maneira: uma observação de rede, a conta associada, o controlo dessa conta naquele momento e as provas que ligam esse controlo a uma pessoa. Um endereço intermédio não é uma localização. Um nome de utilizador não é prova de quem escreveu no teclado. Uma sessão registada não é prova de que o titular da conta estivesse presente.
Anote qual elo falta antes de anotar uma conclusão.
| Evidence | What it actually establishes |
|---|---|
| Source address in a log | An address at that moment, not a person |
| Account name | A credential was used, not who held it |
| Session window | When activity happened, not intent |
| Cross-network correlation | A path, not an identity |
Verificação 3: date as provas que cita
Os relatórios antigos comprimem mal o tempo. Os registos que nunca foram mantidos, os que caducaram por uma política de retenção, os que existiam mas nunca foram correlacionados entre organizações e as investigações que simplesmente não foram seguidas deixam a mesma marca num resumo moderno: nada. Só o primeiro é uma afirmação sobre a capacidade técnica.
Prefira documentos primários com data a resumos recordados, e cite a frase em que se baseia.
Verificação 4: resista à tentação de transformar a história num catálogo de técnicas
A pergunta histórica é o que era observável e o que se podia estabelecer a partir disso. Uma lista de serviços expostos e credenciais predefinidas responde a outra pergunta, e é o tipo errado de resposta para um leitor que tenta compreender a atribuição. Também é desnecessária, porque o argumento se sustenta sem detalhes operacionais.
Se um exemplo precisa de uma receita para ser interessante, o exemplo está a fazer o trabalho errado.
Verificação 5: enuncie a conclusão mais estreita que pode defender
Uma conclusão defensável lê-se assim: o registo sobrevivente mostra que existia orientação, que alguns operadores recolhiam registos de autenticação e que o caso concreto não produziu provas suficientes para identificar uma pessoa. Isto é mais estreito do que dizer que ninguém vigiava, e é mais útil porque pode ser verificado. Anote também o que teria mudado o desfecho, pois a falta de correlação é uma falha diferente da falta de dados. Depois pare.
As afirmações amplas sobre uma década inteira exigem registos dessa década, não uma história plausível sobre como as coisas costumavam ser.