Собеседование на Incident Responder: почему вопрос про chain of custody заваливает кандидатов из SOC

За три года я провёл около сорока собеседований на позицию Incident Responder. Каждый второй кандидат с опытом SOC Tier-2 уверенно проходил блок про SIEM-корреляции и триаж алертов — и сыпался на вопросе «опишите процедуру chain of custody при снятии образа диска с подозрительного сервера». Не потому что не слышал термин. В SOC эта дисциплина просто не нужна: задача аналитика — обнаружить и эскалировать, а не сохранить доказательную силу улики. Разница кажется тонкой. На собеседовании incident responder она стоит оффера.

Два типа мышления: SOC-аналитик vs форензик

В SOC (Security Operations Center — центр мониторинга безопасности) аналитик работает в режиме detect-and-escalate: увидел алерт в SIEM, проверил контекст по EDR-телеметрии, подтвердил или закрыл, передал дальше по цепочке эскалации. Скорость критична. Юридическая чистота данных — нет. Никто не спросит SOC-аналитика: «Вы зафиксировали хеш этого pcap-файла перед тем, как его открыть в Wireshark?» или «Кто именно передал вам USB с логами, в какое время и при каких свидетелях?»

В DFIR (Digital Forensics & Incident Response — цифровая форензика и реагирование на инциденты) логика перевёрнута. Каждый артефакт — потенциальная улика. Если улика не сопровождается непрерывной документацией о том, кто её собрал, когда, каким инструментом и кому передал, — она теряет юридическую силу. Суд, регулятор, страховая компания просто не примут её.

По данным IBM (DFIR overview), «digital forensic investigations follow a strict chain of custody or formal process for tracking how evidence is gathered and handled. The chain of custody allows investigators to prove that evidence wasn’t tampered with». Без custody результаты расследования не годятся ни для суда, ни для страхового требования, ни для регуляторного аудита.

А теперь — как этот конфликт мышления выглядит на практике. Кандидат описывает реагирование: «Я подключился к серверу по SSH, скопировал /var/log/auth.log на свою рабочую станцию и начал анализ». С точки зрения SOC — адекватный ответ: быстро добрался до данных, приступил к работе. С точки зрения форензики — три грубых нарушения:

1. Подключение по SSH изменяет метаданные сервера — timestamp последнего входа, записи в wtmp/utmp, новая строка в auth.log от самого аналитика
2. Копирование файла без предварительного хеширования не позволяет доказать, что содержимое не было изменено при передаче
3. Нет записи о том, кто именно, когда и с какого IP выполнил копирование — нет первой строки в custody-логе

Формально этот лог уже нельзя использовать как доказательство. Цепочка хранения доказательств разорвана до того, как анализ вообще начался.

Chain of custody в цифровой форензике: что это и зачем

Chain of custody (цепочка хранения доказательств) — непрерывная документированная последовательность: кто собрал улику, когда, каким методом, кому передал, где она хранилась на каждом этапе. Любой разрыв делает улику оспоримой. Не «недостоверной» — именно «оспоримой»: противоположная сторона в суде или регуляторной проверке может потребовать исключить её из рассмотрения.

NIST (Национальный институт стандартов и технологий, США) описывает четыре этапа цифрового форензического расследования: Identification (выявление источников данных) → Preservation/Acquisition (сохранение и снятие образов) → Analysis/Examination (анализ) → Presentation/Reporting (отчёт и представление результатов). Chain of custody — не отдельный пятый этап, а сквозная дисциплина, которая проходит через все четыре.

Для российских организаций, подпадающих под ФЗ-187 «О безопасности критической информационной инфраструктуры», это особенно актуально: инциденты на значимых объектах КИИ (критической информационной инфраструктуры) требуют уведомления НКЦКИ (Национального координационного центра по компьютерным инцидентам, входит в ФСБ) в сроки от 3 до 24 часов. Сопроводительные материалы должны быть юридически корректны — без документированной custody они таковыми не будут.

Минимальный custody-лог: что фиксировать на каждом этапе

Каждая передача артефакта между людьми — новая строка в логе. Образ забрали из серверной, привезли в лабораторию, передали старшему аналитику — минимум три записи. Избыточно? В обычном режиме — да. Когда дело доходит до суда — это единственное, что отделяет доказательство от мусора.

Разбор провального ответа на собеседовании incident responder

Типичный вопрос: «Вам передали ноутбук сотрудника, подозреваемый в компрометации. Ноутбук включён. Опишите первые действия».

Ответ кандидата из SOC (реконструкция по реальным собеседованиям): «Я бы подключил ноутбук к изолированному VLAN, запустил EDR-агент для сбора телеметрии, проверил наличие IoC по нашим фидам и выгрузил логи для анализа».

Что слышит интервьюер-форензик — четыре критических ошибки:

«Подключил к сети» — даже изолированный VLAN не гарантирует, что малварь не начнёт коммуникацию с C2-сервером (Command and Control — инфраструктура управления вредоносным ПО). Если на ноутбуке шифровальщик с таймером, сетевое подключение может спровоцировать его активацию.

«Запустил EDR-агент» — установка любого ПО записывает данные на диск ноутбука. Новые файлы, записи реестра, обновление журналов — всё это затирает потенциальные улики в неразмеченном пространстве диска (unallocated space — область, где хранятся фрагменты удалённых файлов).

«Проверил IoC» — анализ до фиксации состояния. Любые изменения, внесённые в систему при «просмотре», уже необратимы и не задокументированы.

Нет упоминания документации — ни слова о custody-логе, хешировании, фиксации состояния устройства.

Как должен звучать ответ: «Первое — не подключать к сети и не выключать. Зафиксировать в журнале: кто передал устройство, когда, серийный номер, текущее состояние — экран включён, что на нём отображается, какие индикаторы горят. Сфотографировать экран с таймштампом. Далее — снять дамп оперативной памяти, потому что RAM-данные пропадут при выключении: сессионные ключи, активные процессы, сетевые соединения. Зафиксировать хеш дампа сразу после снятия. Затем — образ диска через write-blocker. Хеш образа сверить с хешем оригинала. Весь дальнейший анализ — только на копии. Оригинал — в опечатанное хранилище с записью в custody-лог».

Разница не в наборе инструментов. Кандидат из SOC вполне может знать и FTK Imager, и Volatility. Разница в порядке мышления. SOC-логика: «найди угрозу быстро». Форензическая логика: «сохрани доказательство неизменным, потом ищи».

Практический блок: chain of custody от дампа RAM до хранилища

Пошаговая последовательность для самостоятельной отработки. На каждом шаге — что делать, что произойдёт и как убедиться, что получилось.

Предпосылки: загрузочный USB с форензическим дистрибутивом (CAINE или SIFT Workstation), аппаратный или программный write-blocker, утилита для снятия RAM-дампа (WinPmem для Windows, LiME для Linux), доступ к SHA-256-утилите на внешнем носителе.

Шаг 1. Зафиксируй состояние до любого прикосновения

Сфотографируй экран устройства (если включено). Запиши в журнал: дату и время по UTC, серийный номер, кто передал устройство и при каких обстоятельствах, состояние индикаторов (питание, сеть, активность диска). Это первая запись в custody-логе.

Зачем: если через полгода на судебном заседании спросят «а ноутбук был включён на момент изъятия?» — у тебя есть фото с таймштампом и подпись передавшего.

Как понять, что получилось: в журнале — конкретная запись с датой, временем и подписью. Не «примерно после обеда», а «2025-07-12 14:23 UTC, передал Сидоров А.А., ноутбук Dell Latitude 5540 S/N: XXXXXX, экран активен, отображается рабочий стол Windows 11».

Шаг 2. Сними дамп оперативной памяти

Порядок сбора определяется принципом Order of Volatility (порядок летучести данных): сначала то, что исчезнет первым. Последовательность: CPU-регистры и кэш → оперативная память (RAM) → сетевые соединения → запущенные процессы → диск → съёмные носители → резервные копии. RAM — самый ценный и самый хрупкий источник. Ключи шифрования, активные сетевые сессии, процессы малвари, которая может не оставлять следов на диске (fileless malware) — всё пропадёт при выключении.

Запускай утилиту с внешнего USB, чтобы минимально затронуть диск исследуемой машины. После получения дампа — немедленно вычисли его хеш:

sha256sum /mnt/usb/evidence/memory_dump.raw > /mnt/usb/evidence/memory_dump.raw.sha256

Ожидаемый результат: файл .sha256 с одной строкой вида a3f8c1d2e5b7... memory_dump.raw. Этот хеш — криптографический «отпечаток» дампа. Если позже кто-то заявит, что файл изменён — пересчитываешь хеш и сравниваешь. Совпал — файл не менялся.

Запись в custody-лог: «Дамп RAM, инструмент WinPmem 4.0, SHA-256: [хеш], снят 2025-07-12 14:31 UTC, оператор Иванов А.П.»

Шаг 3. Создай образ диска через write-blocker

Write-blocker — устройство (аппаратное или программное), которое физически блокирует запись на исследуемый носитель. Согласно Cyber Forensic Academy (2026 Edition), «its legal purpose is to prove the investigator did not tamper with the original evidence». Без write-blocker операционная система при подключении диска может обновить журнал файловой системы, изменить timestamps или запустить индексацию — и образ перестанет быть точной копией.

Подключи диск через write-blocker и сними побитовую копию. dc3dd — форензическая версия стандартной dd, она автоматически считает хеш в процессе:

dc3dd if=/dev/sda of=/mnt/usb/evidence/disk.dd hash=sha256 log=/mnt/usb/evidence/dc3dd.log

Ожидаемый результат: файл образа + лог с двумя хешами — исходного диска и полученной копии. Хеши совпадают — копия точная. Не совпадают — по рекомендации Cyber Forensic Academy: «Document the discrepancy immediately, stop the current analysis, and attempt a re-acquisition using a different drive/cable/tool».

Отдельная история с SSD: на твердотельных накопителях команда TRIM, механизм wear leveling и garbage collection агрессивно удаляют данные. Удалённые файлы на SSD могут исчезнуть бесследно за минуты — в отличие от HDD, где они лежат в unallocated space до перезаписи. Учитывай это при планировании сбора.

Шаг 4. Опечатай оригинал

Оригинальный носитель — в антистатический пакет, пакет — в опечатанный контейнер (с номером печати), контейнер — в сейф с контролем доступа. Документируй: кто опечатал, когда, номер печати, куда поместил.

Весь дальнейший анализ — исключительно на копии. Оригинал может понадобиться для повторной экспертизы, для суда, для независимой верификации. Если он изменён — верификация невозможна.

Шаг 5. Анализируй копию, документируй каждое действие

Открывай образ в Autopsy, Volatility, X-Ways Forensics — зависит от задачи. Ключевое правило: каждое значимое действие (обнаружен артефакт, извлечён файл, построена хронология) фиксируется в рабочем журнале расследования. Это не custody-лог, а его дополнение — он показывает, что именно делал аналитик с копией и в каком порядке.

Антифорензика: почему chain of custody критичнее при активном противодействии

Злоумышленники знают про форензику и целенаправленно уничтожают следы. В классификации MITRE ATT&CK (открытая база тактик и техник атак; T-коды — идентификаторы конкретных техник) это целая группа под названием Indicator Removal:

• T1070.001 — Clear Windows Event Logs — удаление журналов событий Windows, чтобы скрыть следы входа и выполнения команд
• T1070.002 — Clear Linux or Mac System Logs — очистка /var/log/auth.log, syslog и других журналов на Linux/macOS
• T1070.003 — Clear Command History — удаление .bash_history, логов PowerShell, чтобы скрыть выполненные команды
• T1070.004 — File Deletion — удаление инструментов, скриптов, малвари после использования
• T1070.006 — Timestomp — подделка временных меток файлов (created/modified/accessed), чтобы замаскировать момент атаки

Все эти техники относятся к тактике Defense Evasion (уход от обнаружения). И вот ключевой момент для chain of custody: если злоумышленник подделал timestamps (T1070.006), единственный способ доказать подделку — сравнить метаданные файловой системы (записи MFT в NTFS или inode-таймстемпы в ext4) с custody-логом, где зафиксировано, когда именно был снят образ. Без custody-лога адвокат ответчика спросит: «Откуда мы знаем, что timestamps не изменил сам следователь?» И формально будет прав.

По данным CrowdStrike (Global Threat Report 2025), среднее время lateral movement (горизонтального перемещения по сети) после первичного доступа — 62 минуты, рекорд — 51 секунда. Mandiant (M-Trends 2025) фиксирует медианное время обнаружения злоумышленника в 11 дней. За это время атакующий успевает зачистить логи (T1070.001/002), удалить файлы (T1070.004), подделать timestamps (T1070.006). К моменту, когда форензик получает устройство, часть следов уже уничтожена. Чем меньше артефактов осталось, тем выше ценность каждого уцелевшего — и тем критичнее, чтобы его цепочка хранения доказательств была безупречной.

Вопросы на собеседовании incident responder: что спросят и как отвечать

На основе типичных вопросов из DFIR-интервью (по данным Cyber Forensic Academy, 2026 Edition) и собственного опыта проведения собеседований — набор вопросов, на которые нужно отвечать без запинки.

«Что такое chain of custody и зачем она нужна?» — интервьюер ждёт не определение из учебника, а понимание последствий разрыва. Сильный ответ: «Без custody улика оспорима. Суд, регулятор или страховая могут отказать в её приёме. Custody — не бюрократия, а гарантия, что доказательство не было изменено ни на одном этапе».

«Опишите порядок сбора данных с работающей машины» — проверяют знание Order of Volatility. Правильная последовательность: RAM → сетевые соединения → запущенные процессы → диск. Кандидат, который начинает с диска, теряет volatile data.

«Хеш образа не совпал с хешем оригинала — ваши действия?» — правильный ответ: задокументировать несоответствие в журнале, остановить текущий анализ, провести повторное снятие образа с другим кабелем или инструментом, чтобы исключить аппаратную ошибку.

«Зачем нужен write-blocker, если можно монтировать диск read-only?» — аппаратный write-blocker защищает на физическом уровне. Программный read-only может быть обойдён ошибкой ОС, автомонтированием или багом драйвера. В суде аппаратный write-blocker — более весомый аргумент.

«Чем физический образ отличается от логического?» — физический (побитовый) копирует все секторы носителя, включая удалённые файлы и unallocated space. Логический — только видимую файловую систему. Для форензики нужен физический.

Чек-лист подготовки к собеседованию

1. Order of Volatility — выучить последовательность и уметь обосновать каждый приоритет
2. Физический vs логический образ — понимать разницу и объяснять, когда нужен каждый
3. Write-blocker — знать, зачем нужен аппаратный и почему программный read-only недостаточен
4. Практика с инструментами — снять образ тестового диска через dc3dd или FTK Imager, вычислить и сверить хеши, заполнить учебный custody-лог от первой строки до последней
5. SSD-специфика — TRIM, wear leveling, garbage collection и их влияние на сохранность удалённых данных
6. MITRE ATT&CK T1070 — знать основные антифорензические техники. Это покажет интервьюеру, что ты понимаешь не только процедуру, но и контекст, в котором она применяется
7. Отчётность — уметь объяснить, как результаты расследования оформляются для суда, регулятора или страховой компании

Последний пункт часто недооценивают. По данным Cyber Forensic Academy, вопросы про оформление отчёта задают на собеседованиях всех уровней — от junior до senior. Умение написать понятный отчёт отделяет аналитика от технаря, который «разобрался, но объяснить не может».

Я наблюдаю парадокс последние пару лет: кандидаты из SOC технически сильнее, чем были раньше. Они пишут Sigma-правила, разбираются в EDR-телеметрии, строят detection-логику на уровне, который пять лет назад был уделом Tier-3. Но разрыв с форензикой только вырос. SOC-инструменты стали настолько удобными, что аналитику не нужно думать о целостности данных — SIEM сам собирает логи, EDR сам снимает артефакты, SOAR сам раскладывает по тикетам. В SOC нет момента, когда ты физически берёшь носитель в руки и отвечаешь за каждый байт.

Проблема не в людях. SOC формирует привычку работать с потоком данных в реальном времени, а форензика требует работать с застывшим моментом, где каждое прикосновение к данным необратимо и должно быть задокументировано. Это не разные инструменты — это разные модели мышления. И пока онбординг junior Incident Responder не включает явный переключатель с одной модели на другую, кандидаты будут проваливаться на одном и том же вопросе. Если переход из SOC в IR — ближайший план, а форензическую базу нужно собрать системно — IB Basics на codeby.school закрывает именно этот фундамент, который SOC-бэкграунд не даёт.