Une attribution manquée ne prouve pas que l'attaquant était anonyme
Une affaire sans auteur identifié montre ce que les preuves pouvaient établir, non que l'anonymat ait fonctionné. Distinguez la recommandation, son adoption et l'échec de l'attribution.
Une affaire qui se termine sans auteur identifié est volontiers décrite comme anonyme, et ce mot fait beaucoup de travail discret. Il transforme une affirmation sur les preuves en affirmation sur le monde. Les deux ne sont pas la même chose, et pour les incidents anciens, la différence est souvent la seule chose que le dossier survivant puisse étayer. Un incident non attribué vous dit ce qui pouvait être établi, non ce qui était possible.
Cinq vérifications séparent les deux.
Vérification 1 : séparez la recommandation de son adoption
Le RFC 1281, publié en novembre 1991, recommandait de conserver et d'auditer les enregistrements pertinents pour la sécurité, de soutenir le traçage des connexions et de désigner un contact sécurité pour le traitement des incidents. Il demandait aussi aux opérateurs de publier ce qu'ils collectaient et qui pouvait l'utiliser. C'est un document daté de ce qui était recommandé, ce qui est une affirmation différente de ce qu'a fait un réseau particulier.
Une recommandation prouve que la préoccupation existait. Elle ne prouve pas la mise en œuvre, et certainement pas qu'une enquête précise a réussi.
Vérification 2 : nommez le maillon rompu de l'attribution
L'attribution est une chaîne, et chaque maillon échoue à sa manière : une observation réseau, le compte qui y est associé, la maîtrise de ce compte à ce moment-là et les preuves reliant cette maîtrise à une personne. Une adresse intermédiaire n'est pas un lieu. Un nom d'utilisateur ne prouve pas qui a tapé sur le clavier. Une session enregistrée ne prouve pas que le titulaire du compte était présent.
Notez quel maillon manque avant de noter une conclusion.
| 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 |
Vérification 3 : datez les preuves que vous citez
Les vieux rapports compressent mal le temps. Les enregistrements jamais tenus, ceux expirés selon une politique de conservation, ceux qui existaient mais n'ont jamais été corrélés entre organisations et les enquêtes simplement non poursuivies laissent tous la même trace dans un résumé moderne : rien. Seul le premier est une affirmation sur la capacité technique.
Préférez les documents primaires datés aux résumés mémorisés, et citez la phrase sur laquelle vous vous appuyez.
Vérification 4 : résistez à la tentation de transformer l'histoire en catalogue de techniques
La question historique est ce qui était observable et ce qui pouvait en être établi. Une liste de services exposés et d'identifiants par défaut répond à une autre question, et c'est le mauvais type de réponse pour un lecteur qui cherche à comprendre l'attribution. Elle est aussi inutile, car l'argument tient sans détails opérationnels.
Si un exemple a besoin d'une recette pour être intéressant, l'exemple fait le mauvais travail.
Vérification 5 : énoncez la conclusion plus étroite que vous pouvez défendre
Une conclusion défendable se lit ainsi : le dossier survivant montre qu'une recommandation existait, que certains opérateurs collectaient des journaux d'authentification et que l'affaire précise n'a produit aucune preuve suffisante pour identifier une personne. C'est plus étroit que de dire que personne ne regardait, et c'est plus utile parce que c'est vérifiable. Notez aussi ce qui aurait changé l'issue, car une corrélation manquante est un échec différent de données manquantes. Puis arrêtez-vous.
Les affirmations larges sur une décennie entière exigent des archives de cette décennie, pas une histoire plausible sur la façon dont les choses se passaient avant.