КАК РАССЛЕДОВАТЬ УТЕЧКИ ИНФОРМАЦИИ.

#расследования

Для начала давайте попробуем уложить все наши действия в простой алгоритм из трех шагов:

ШАГ 1. Поскольку чаще всего об утечке мы узнаем постфактум, когда она уже появляется на чёрном рынке, начнём с простого - исследования того, в каком виде она попала в публичное поле. На что стоит обратить внимание:

📡 Канал распространения:

- Место публикации утечки

- Дата и время публикации

- Кто опубликовал

- Кошелёк для покупки (если платно)

Для чего это? Для поиска места первоначального размещения и идентификации того, кто является потенциальным выгодоприобретателем.

💾 Файл, в который упакована утечка:

- Формат файла

- Метаданные полученного файла.

- Даты создания и изменения.

- Хэш сумма файла.

Для чего? Для идентификации файлов в различных источниках, возможные паттерны изменения в зависимости от миграции и сравнения разных версий.

🗂 Содержимое файла:

- Используемые поля

- Формат их записи

- Полнота присутствующих полей

- Дата/время первой записи

- Дата/время последней записи

Для чего? Для получения информации о "срезе" данных их полноте и возможно времени получения "среза". На этом этапе мы стараемся понять, когда фактически произошла утечка, не является ли она компиляцией и кто гипотетически мог иметь доступ исходя из формата записей.

ШАГ 2. Исследуем легитимный источник данных, находящийся в утечке. Со следующими точками интереса:

• Основной формат хранения данных

• Возможные форматы получения данных при условии различных условиях их копирования (бэкап, экспорт, парсинг и т.д.)

Для чего? Для поиска возможного способа и формы полученной утечки.

Далее мы должны посмотреть на нашу систему, из которой могла произойти утечка данных и выявить следующие:

• Перечень уровней доступа.

• Перечень доступных полей для каждого уровня доступа.

• Перечень пользователей с доступом к утекшим данных.

Целью этих действий для нас будет фиксации возможных причастных учетных записей пользователей и способов доступа к данным, которые могут находится в «срезе» опубликованной утечки.

• Фиксация временного отрезка по полноте данных в утечке.

Для чего? Для формирования временных рамок поискового ландшафта. Как правило, отсчёт ведётся в обратном порядке от момента первичного размещения в публичном поле до (примерно) минус 60 суток от даты последних внесённых данных в "срезе"

• Логи доступа к целевым данным пользователей

• Логи изменений в целевом источнике данных.

Это нужно для реконструкции истории обращений к источнику целевых данных пользователей системы.

ШАГ 3. Ну и в заключительном шаге нам предстоит самое интересное – выявление и фиксация аномалий в поведенческих паттернах пользователей.