Кибербезопасность и информационная безопасность

Как построить Timeline для расследования киберинцидента

6 мин чтенияОпубликовано: 5 августа 2026 г.

Профессиональная визуальная иллюстрация по построению Timeline для расследования инцидентов в сфере SOC и операций

Быстрый ответ

Timeline для расследования инцидента — это хронологическая таблица, которая объединяет события из разных источников в единое время и связывает их с помощью пользователей, рабочих станций, IP-адресов, процессов и сессий. Правильное построение включает сохранение исходного времени, преобразование в UTC, указание источника и достоверности, выявление пробелов и разделение фактов, интерпретаций и предположений.

Киберинцидент почти никогда не фиксируется в одном журнале. Подключение находится в системе идентификации, запуск процесса — в EDR или Windows, запрос домена — в DNS, а исходящее соединение — в Firewall. Каждый источник описывает свою часть, в разном формате времени и с разными идентификаторами. Без Timeline следователь видит набор признаков; с Timeline он может увидеть возможную причинно-следственную связь.

Временная шкала — это не просто упорядочивание по времени. Это процесс нормализации, связывания и оценки достоверности. Сбившиеся часы, неправильный часовой пояс или задержка приема данных могут исказить порядок и привести к ошибочным выводам. NIST определяет управление журналами как процесс, включающий создание, передачу, хранение и доступ; каждый этап влияет на способность восстановить событие.

В этой статье мы построим Timeline на основе сценария, включающего Windows, DNS, Firewall и EDR. Примеры не зависят от конкретного продукта и могут быть реализованы в таблице, SIEM, Notebook или инструментах DFIR.

Почему Timeline — это сердце расследования

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

Он также выявляет пробелы. Если EDR показывает запуск файла, но нет события создания процесса в Windows, возможно, аудит не включен, журнал был удален, событие было отфильтровано или временные идентификаторы не синхронизированы. Сам пробел является результатом.

При сложном расследовании рекомендуется иметь две временные шкалы: Master Timeline, включающую основные события, и подробную Timeline для каждого актива или источника. Таким образом, отчет остается читабельным, не теряя данных.

Нормализация времени и источников

Всегда сохраняйте два поля: Original Timestamp, как оно появилось в источнике, и Normalized Timestamp в UTC. Укажите исходный часовой пояс, известное отклонение часов и время получения в SIEM. Не перезаписывайте исходное время, так как оно требуется для аудита и разрешения противоречий.

Различайте время события и время Ingestion. Firewall может отправлять логи с задержкой, Agent может быть Offline и загружать данные позже, а облачный продукт может рассчитывать Detection после события. Сортировка только по времени получения может быть ошибочной.

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

Связывание пользователей, хостов, IP и процессов

События из разных источников связываются с помощью Pivot Keys. Идентификация: UPN, SID, Object ID, Session ID. Рабочая станция: hostname, Device ID, Agent ID, MAC-адрес. Сеть: IP, NAT translation, port, protocol. Процесс: PID, Parent PID, Process GUID, hash и командная строка.

Один только PID не является стабильным идентификатором в течение длительного времени, поскольку операционная система может его повторно использовать. В Windows Process GUID Sysmon или комбинация Host + PID + время помогают больше. Внутренний IP-адрес может перемещаться между станциями в DHCP, поэтому его необходимо перепроверить с Lease или дополнительной телеметрией.

В каждой строке добавьте поле «Entity Link»: как событие связано с предыдущим. Например: «DNS-запрос был создан PID 4120, который является дочерним элементом powershell.exe из предыдущей строки». Явная ссылка не позволяет читателю предполагать связь, которая не была доказана.

Разделение фактов, интерпретаций и предположений

Факт: «В 10:14:22 EDR зафиксировал powershell.exe с родительским winword.exe». Интерпретация: «Последовательность соответствует возможности выполнения кода из документа». Предположение: «Возможно, пользователь открыл фишинговый файл». Разделение критически важно для того, чтобы отчет не представлял предположение как доказательство.

Можно добавить столбец Confidence: высокий, когда несколько независимых источников подтверждают; средний, когда один качественный источник подтверждает; низкий, когда данные неполны или зависят от предположения. Уровень достоверности не является обязательной математической оценкой, а способом сообщить о неопределенности.

MITRE ATT&CK можно добавить после понимания инцидента для описания методов, но не следует использовать сопоставление для заполнения пробелов. Факт существования PowerShell не доказывает Initial Access или Persistence.

Выявление пробелов и противоречий

Ищите временные провалы, события, которые появляются только в одном источнике, адреса, не соответствующие NAT, пользователей в разных форматах и противоположные результаты. Пятиминутный промежуток до первого соединения может содержать самое важное действие.

Когда два источника показывают разное время, проверьте Clock Skew, Time Zone, время записи по сравнению со временем приема, округление и кеш. Сохраните обе версии и укажите, какая из них использовалась для сортировки и почему.

Создайте «список недостающих данных»: логи Proxy не были сохранены, Process Creation не был включен, EDR был Offline или нет доступа к Mailbox Audit. Список помогает понять ограничения выводов и улучшить логирование в будущем.

Представление Timeline в отчете

Timeline в отчете для руководителей должен включать только события, которые меняют понимание инцидента: первоначальный доступ, выполнение, устойчивость, горизонтальное перемещение, доступ к информации, сдерживание и восстановление. Техническое приложение может включать полные записи.

Для каждой строки рекомендуется отображать: UTC, исходное время, источник, сущность, событие, доказательство/идентификатор, интерпретацию и уровень достоверности. Используйте последовательный язык и точные глаголы: «создано», «заблокировано», «неудачно», «замечено» — не «взломано» без доказательств.

Приложите сокращенную Timeline также к Ticket, чтобы следующий аналитик мог продолжить, не читая все примечания.

Сценарий: Windows, DNS, Firewall и EDR

UTC	Источник	Сущность	Событие	Связь и интерпретация
08:41:03	Windows Security	WS-17 / user1	Успешный интерактивный вход	Начало сессии; необходимо проверить источник и Logon ID
08:43:18	EDR	WINWORD.EXE	Создание powershell.exe	Дерево процессов указывает на запуск из документа
08:43:20	EDR	powershell.exe	Зашифрованная командная строка	Требуется расшифровать в безопасной среде и сохранить источник
08:43:22	DNS	WS-17	Запрос к new-example-domain.tld	Тот же хост, через две секунды после запуска
08:43:23	Firewall	10.0.4.17	TLS-соединение с внешним IP	IP соответствует ответу DNS; NAT подтвержден
08:44:01	EDR	powershell.exe	Создание файла в папке Temp	Хэш сохранен; пока не определено, является ли вредоносным
08:47:55	Microsoft Sentinel	user1 / WS-17	Инцидент создан	Время обнаружения позже времени событий
09:02:11	EDR	WS-17	Изоляция рабочей станции успешно завершена	Точка сдерживания; проверить соединения после этого

Практический Checklist

Я сохранил исходное время и время UTC.
Я различал время события и время Ingestion.
Я задокументировал источник и поле идентификатора.
Я связал сущности с помощью надежных идентификаторов.
Я отделил факт от интерпретации.
Я указал пробелы и противоречия.
Я добавил Confidence.
Я создал сокращенную Timeline и подробное приложение.

Распространенные ошибки

Сортировать только по времени приема.
Преобразовывать время без сохранения исходного значения.
Связывать события только на основе динамического IP.
Писать предположение так, будто это факт.
Перегружать Master Timeline тысячами событий без фильтрации.

Заключение и CTA

Возьмите один лабораторный сценарий и постройте для него вручную Timeline из четырех источников. Затем сравните его с процессом расследования в первой статье и проверьте, какие поля следует добавить в Playbook вашей команды. В курсе Cybersecurity & AI от HPI навыки работы с логами, сетями и SIEM изучаются в рамках практической отработки расследования инцидентов.

Вопросы и ответы

Всегда ли используется UTC?

Рекомендуется нормализовать до UTC для объединения источников, но также сохранять исходное время и смещение и отображать местное время по мере необходимости для бизнеса.

Что делать, если нет синхронизации часов?

Оцените Clock Skew с помощью общего события или надежного источника, задокументируйте разницу и сохраните исходное время. Не изменяйте доказательства без документации.

В каком инструменте строится Timeline?

Можно начать с таблицы или SIEM. В крупных расследованиях используются инструменты DFIR или Notebook. Инструмент менее важен, чем поля, нормализация и связывание.

Сколько событий включать?

В Master Timeline включаются существенные события. Все записи хранятся в приложении или в хранилище доказательств.

Доказывает ли Timeline причинно-следственную связь?

Не обязательно. Близость по времени усиливает возможность связи, но для определения того, что один процесс вызвал другой, требуется дополнительный идентификатор или доказательство.