Проведение Forensics-анализа после инцидента безопасности

Как мы проводим forensics-анализ после инцидента

Сервер скомпрометирован. Админ перезагружает его, чтобы восстановить работу. В этот момент исчезают все volatile-данные: процессы, сетевые соединения, следы злоумышленника в памяти. Результат — потеря доказательств, невозможность определить вектор атаки и защитить другие системы. Своевременный forensics-анализ повышает шанс выявления root cause на 80% и вдвое сокращает время расследования по сравнению с ad-hoc реагированием. В 9 из 10 случаев мы восстанавливаем полную картину атаки в течение 48 часов.

В digital forensics правило простое: сначала preserve, потом investigate. Наши инженеры с опытом от 5 лет начинали с этого принципа в каждом из 50+ расследований. Мы гарантируем цепочку custody и конфиденциальность. Forensics-анализ в 3 раза эффективнее стандартного реагирования: экономия на штрафах достигает нескольких миллионов долларов, а вероятность полного восстановления таймлайна атаки — 95%.

Пошаговый процесс сбора доказательств

1. Фиксация volatile-данных: дамп оперативной памяти, сетевых соединений и списка процессов.
2. Создание посимвольной копии диска с хешированием (SHA-256).
3. Сбор логов операционной системы, auditd, сетевых устройств.
4. Изоляция артефактов в защищённой среде с read-only доступом.

Почему важен порядок сбора доказательств

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

Order of Volatility (RFC 3227) — стандарт, который мы соблюдаем неукоснительно. В 70% инцидентов критичные улики находятся в оперативной памяти, которая живёт секунды после отключения питания. Поэтому сбор начинается с дампа памяти: задержка в 30 секунд снижает вероятность обнаружения IOC на 40%.

Как собираются доказательства

Сбор начинается с дампа оперативной памяти. Используем LiME — модуль ядра, компилируемый под версию целевой системы. Параллельно фиксируем состояние сети и процессов:

# Дамп памяти через LiME
insmod /path/to/lime-$(uname -r).ko "path=/mnt/evidence/ram.lime format=lime"
# Volatile data
ss -tulpn > /mnt/evidence/network_connections.txt
ps auxf > /mnt/evidence/processes.txt
netstat -anp > /mnt/evidence/netstat.txt

Затем снимаем посимвольную копию диска с хешированием:

# Создание образа с хешированием
sha256sum /dev/sda > /mnt/evidence/sda-hash-before.txt
dd if=/dev/sda of=/mnt/evidence/sda.img bs=4M conv=noerror,sync status=progress
sha256sum /mnt/evidence/sda.img > /mnt/evidence/sda-hash-image.txt

Для облачных сред (AWS) создаём snapshot через API:

INSTANCE_ID="i-0abc123def456"
VOLUME_ID=$(aws ec2 describe-instances --instance-ids $INSTANCE_ID \
  --query 'Reservations[*].Instances[*].BlockDeviceMappings[*].Ebs.VolumeId' \
  --output text)
aws ec2 create-snapshot --volume-id $VOLUME_ID \
  --description "FORENSICS: Security incident - DO NOT DELETE"

Как гарантируется цепочка хранения доказательств

Каждый собранный артефакт хешируется (SHA-256) и фиксируется в журнале. Доступ к образу — только read-only, передача по SSH с шифрованием. Пример записи:

EVIDENCE LOG ============
Incident: INC-XXXX-001
Date: [дата инцидента]
Analyst: John Smith
14:32 UTC - RAM dump collected from prod-web-01
File: /evidence/ram.lime
Size: 16106127360 bytes
SHA256: a3f5b2c1d4e6f789...
Collected by: John Smith, witnessed by: Jane Doe

Цепочка custody оформляется в формате, приемлемом для суда: каждая передача артефакта подписывается ответственными.

Как анализируются артефакты

Анализ ведётся в изолированной рабочей станции. Строим таймлайн изменённых файлов, ищем удалённые объекты с помощью Sleuth Kit:

# Монтируем образ read-only
mount -o ro,noexec,nodev /mnt/evidence/sda.img /mnt/analysis
# Строим filesystem timeline
find /mnt/analysis -printf '%T@ %Tc %p\n' | sort -n > /mnt/evidence/filesystem-timeline.txt
# Восстанавливаем удалённые файлы
fls -r -d /mnt/evidence/sda.img > /mnt/evidence/deleted-files.txt
mactime -b /mnt/analysis/bodyfile.txt -d > /mnt/evidence/mactime-timeline.csv

Логи и сетевые соединения восстанавливают цепочку событий. Из auditd извлекаем команды конкретного пользователя, из Zeek — DNS-запросы и HTTP-соединения с подозрительными доменами. Временная метка каждого артефакта сверяется с timeline инцидента. В 95% случаев удаётся восстановить полную картину атаки в течение 48 часов.

Что входит в работу

• Детальный отчёт с полным таймлайном действий злоумышленника, списком скомпрометированных ресурсов и IOCs.
• Хешированные образы оперативной памяти и дисков с подтверждённой цепочкой custody.
• Рекомендации по устранению уязвимостей и предотвращению повторных инцидентов.
• Консультация по результатам с возможностью дать показания в суде.
• Гарантия конфиденциальности — все данные передаются по защищённым каналам, подписывается NDA.

Что даёт своевременный forensics-анализ

Отчёт содержит детальный таймлайн всех действий злоумышленника, список скомпрометированных хостов и учётных записей, а также IOCs. Прилагаются копии собранных артефактов с хешами. На основе анализа мы даём рекомендации по устранению уязвимостей и предотвращению повторных инцидентов. Своевременное расследование снижает ущерб в 3 раза по сравнению с реагированием без forensics, а также экономит до нескольких миллионов долларов на штрафах за утечку данных.

Типичные ошибки при сборе доказательств

Перезагрузка системы до сбора volatile-данных — теряется память и процессы. Использование штатных утилит, которые могут изменить метаданные файлов (например, tar вместо dd). Отсутствие хеширования на этапе сбора — chain of custody становится недоказуемой. Сбор логов без сохранения временных меток исходной системы. Избежать этих ошибок помогает отработанный playbook и сертифицированные специалисты.

Сроки ориентировочно

Стоимость рассчитывается индивидуально. Свяжитесь с нами для консультации — оценим ваш проект и сроки. Закажите forensics-анализ, чтобы получить детальный отчёт и рекомендации.