Неудачная атрибуция не доказывает, что нападавший был анонимом
Дело без названного виновника показывает, что могли установить доказательства, а не то, что анонимность сработала. Разделяйте рекомендации, их принятие и провал атрибуции.
Дело, которое заканчивается без названного виновника, часто описывают как анонимное, и это слово делает много тихой работы. Оно превращает утверждение о доказательствах в утверждение о мире. Это не одно и то же, и в старых инцидентах разница часто оказывается единственным, что может подтвердить сохранившаяся запись. Инцидент без атрибуции говорит вам, что можно было установить, а не что было возможно.
Пять проверок разделяют эти две вещи.
Проверка 1: отделите рекомендацию от её принятия
RFC 1281, опубликованный в ноябре 1991 года, рекомендовал хранить и проверять записи, связанные с безопасностью, поддерживать трассировку соединений и назначать контакт по безопасности для обработки инцидентов. Он также просил операторов публиковать, что они собирают и кто может это использовать. Это датированная запись о том, что было рекомендовано, а это иное утверждение, чем то, что сделала какая-либо конкретная сеть.
Рекомендация — доказательство того, что беспокойство существовало. Это не доказательство внедрения и уж точно не доказательство того, что конкретное расследование увенчалось успехом.
Проверка 2: назовите, какое звено в атрибуции разорвалось
Атрибуция — это цепочка, и каждое звено отказывает по-своему: наблюдение в сети, связанная с ним учётная запись, контроль над этой записью в тот момент и доказательства, связывающие этот контроль с человеком. Промежуточный адрес — не местоположение. Имя пользователя — не доказательство того, кто печатал на клавиатуре. Зарегистрированная сессия — не доказательство того, что владелец учётной записи присутствовал.
Запишите, какого звена не хватает, прежде чем записывать вывод.
| 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 |
Проверка 3: датируйте доказательства, на которые ссылаетесь
Старые отчёты плохо сжимают время. Записи, которые никогда не велись, записи, истёкшие по политике хранения, записи, которые существовали, но никогда не сопоставлялись между организациями, и расследования, которые просто не продолжались, все оставляют в современном резюме один и тот же след: ничего. Только первое является утверждением о технических возможностях.
Предпочитайте датированные первичные документы заученным резюме и цитируйте предложение, на которое опираетесь.
Проверка 4: сопротивляйтесь превращению истории в каталог техник
Исторический вопрос в том, что было наблюдаемо и что из этого можно было установить. Список открытых служб и учётных данных по умолчанию отвечает на другой вопрос, и это неверный тип ответа для читателя, пытающегося понять атрибуцию. Он также не нужен, потому что аргумент держится и без операционных деталей.
Если примеру нужен рецепт, чтобы быть интересным, значит, пример выполняет не ту работу.
Проверка 5: сформулируйте более узкий вывод, который вы можете защитить
Защитимый вывод звучит так: сохранившаяся запись показывает, что рекомендации существовали, что некоторые операторы собирали журналы аутентификации и что конкретное дело не дало доказательств, достаточных для установления личности. Это уже, чем утверждение, что никто не наблюдал, и полезнее, потому что это можно проверить. Отметьте и то, что изменило бы исход, поскольку отсутствие корреляции — иной провал, чем отсутствие данных. Затем остановитесь.
Широкие утверждения о целом десятилетии требуют записей из этого десятилетия, а не правдоподобной истории о том, как всё было раньше.