«Поставить систему логирования — легко. Построить логирование, которое выдержит расследование реального инцидента, — это другой уровень. Это не про гигабайты в SIEM, а про создание альтернативной, защищённой реальности, которая переживёт компрометацию основных систем. Её итог — не красивые графики, а полная, неопровержимая цепочка событий.»
Определите цели, прежде чем настраивать сбор
Логи — инструмент для ответа на вопросы. Запуск сбора без понимания этих вопросов приводит к хранилищу бесполезных данных. В зависимости от глубины расследования цели логирования делятся на три уровня.
Мониторинг и оповещение в реальном времени
На этом уровне логи служат источником для триггеров. Их структура должна быть машинно-читаемой, содержать ключевые поля для корреляции: количество неудачных попыток входа, хэш запущенного процесса, внешний IP-адрес. Цель — не восстановить картину, а вовремя подать сигнал.
Расследование инцидентов
Когда инцидент обнаружен, на первый план выходит связность. Логи должны позволить соединить точки: от срабатывания сигнатуры на сетевом экране до момента, когда вредоносный процесс изменил реестр. Критична возможность проследить действия одного субъекта (пользователя, IP, хэша) через разные уровни инфраструктуры.
Формирование доказательственной базы
Этот уровень выходит за рамки внутреннего расследования. Здесь логи становятся доказательством, и их значимость определяется не техническими, а процессуальными требованиями. Ключевое — обеспечение целостности и аутентичности данных от момента генерации до предъявления. На практике это означает неизменяемое хранение, синхронизацию времени по доверенным внутренним источникам и документально закреплённый регламент сбора, который исключает сомнения в подлинности записей. В контексте требований ФСТЭК и 152-ФЗ отсутствие такой системы может сделать любые логи юридически ничтожными.
Выберите источники, которые действительно расскажут историю атаки
Типичная ошибка — сбор всего подряд в надежде «что-нибудь поймать». Эффективность падает, стоимость хранения растёт. Источники должны дополнять друг друга, формируя многослойное покрытие.
| Категория | Конкретные источники | Какую часть истории атаки покажут |
|---|---|---|
| Операционная система | Журналы безопасности Windows (Security), системный журнал Linux (syslog/rsyslog), журнал аудита (auditd), история командной оболочки. | Действия внутри системы: аутентификация, запуск процессов, изменение прав доступа, доступ к файлам. |
| Сетевая инфраструктура | Межсетевые экраны, прокси-серверы, DNS-серверы, NetFlow/IPFIX-данные. | Коммуникации атаки: исходные и целевые адреса, порты, запрашиваемые домены, объём передаваемых данных. |
| Приложения и СУБД | Логи веб-серверов (Nginx, Apache), журналы транзакций БД, логи бизнес-приложений, системы централизованной аутентификации. | Цель и результат: какие конечные точки атаковались, какие команды выполнялись, какие данные были изменены или извлечены. |
| Средства защиты | Антивирусные системы, EDR, SIEM (события корреляции), системы обнаружения вторжений. | Реакцию защитных механизмов и срабатывание детекторов: блокировки, алерты, изоляция узлов. |
Разница между уровнями существенна. Лог сетевого экрана покажет факт подключения к порту 445, лог Windows Security — успешный вход по NTLM, а лог EDR — запуск утилиты Mimikatz. Только вместе они формируют цепочку атаки.
[ИЗОБРАЖЕНИЕ: Схема, иллюстрирующая, как атака, проходящая через сетевой периметр, операционную систему и приложение, оставляет следы в разных источниках логов. Стрелки показывают пересечение событий по общим полям, таким как IP-адрес, имя пользователя или временная метка.]
Структурируйте события: что должно быть в каждом логе
Событие без обязательного набора атрибутов теряет ценность для расследования. Каждая запись должна быть самодостаточной и готовой к корреляции.
- Временная метка. Дата и время с точностью как минимум до миллисекунд в формате UTC. Разница в секунды между системами может разорвать логическую связь событий при быстрой автоматизированной атаке.
- Идентификатор источника. Уникальное имя хоста, IP-адрес или идентификатор сервиса, откуда пришло событие.
- Субъект действия. Кто совершил действие: пользователь (с указанием домена), ID процесса, система.
- Объект действия. На что было направлено действие: путь к файлу, URL, ключ реестра, запись в базе данных.
- Описание. Чёткая формулировка, которая несёт смысл без дополнительного контекста. Вместо «Access denied» — «Доступ к файлу /etc/shadow для пользователя ‘www-data’ отклонён из-за недостаточных прав».
- Статус. Успех или неудача операции. Неудачные попытки часто более информативны для обнаружения зондирования.
Формат записи должен быть структурированным. JSON, например, позволяет легко парсить и обогащать данные. Избегайте дублирования информации и многословных сообщений, не несущих конкретики.
Спроектируйте жизненный цикл данных: от сбора до архива
Форвардинг и агрегация: централизованный сбор
Локальное хранение логов на конечном хосте — это их потеря при компрометации. Используйте push-модель: агенты или системные службы отправляют события на выделенные серверы сбора по защищённым каналам (например, TLS для syslog). Ключевое — буферизация на источнике при потере связи, чтобы события не пропадали.
Нормализация и обогащение: создание контекста
Сырые логи в разных форматах бесполезны для анализа. Нормализация приводит названия полей к единому стандарту. Обогащение добавляет внешний контекст: определяет организацию по IP-адресу, добавляет теги критичности актива по его имени, сверяет хэши файлов с базами репутаций. Этот этап превращает разрозненные события в связанную историю внутри SIEM.
| До обогащения (сырой лог веб-сервера) | После нормализации и обогащения в SIEM |
|---|---|
| 192.168.10.15 — — [15/Apr/2025:11:23:01 +0300] «GET /wp-admin/install.php HTTP/1.1» 404 1234 |
timestamp: 2025-04-15T08:23:01.000Z source_ip: 192.168.10.15 action: web_request url_path: /wp-admin/install.php enriched: { «asset_owner»: «Отдел маркетинга», «threat_context»: «Известная конечная точка установки уязвимого ПО» } |
Ротация и хранение: баланс между стоимостью и необходимостью
Политика хранения не может быть единой. Логи для алертинга могут храниться 30-60 дней. Данные, необходимые для расследования сложных атак или для выполнения регуляторных требований (например, по 152-ФЗ), должны сохраняться годами. Часто применяется многоуровневая модель: «горячие» данные на быстрых носителях для оперативной работы, «холодные» — на объектных хранилищах для архива. Важна автоматизация ротации и наличие отработанной процедуры восстановления.
Защитите сами логи: они — цель атаки номер один
После получения контроля над системой злоумышленник стремится стереть следы. Система логирования должна быть рассчитана на работу в условиях компрометации других компонентов.
- Неизменяемость. Настройте передачу логов таким образом, чтобы удалить или изменить запись после её попадания в систему сбора было технически невозможно. Это может быть отдельный сервер приёма с закрытыми правами на запись или использование специализированных хранилищ.
- Защита чувствительных данных. Логи не должны создавать новую утечку. Пароли, токены, персональные данные должны маскироваться или токенизироваться на этапе генерации или при первоначальной обработке.
- Разделение полномочий. Принцип разделения ответственности обязателен. Администратор, настраивающий сбор, не должен иметь прав на удаление исторических данных. Аналитик имеет доступ только на чтение. Все административные действия с системой логирования должны сами попадать в защищённый, неизменяемый аудит-трейл.
Избегайте стандартных ловушек
- Сбор ради сбора. Лавина нерелевантных данных заглушает значимые сигналы. Фокусируйтесь на источниках и событиях, связанных с конкретными сценариями угроз для вашей инфраструктуры.
- Ненадёжная синхронизация времени. Разница в минуты делает бессмысленной любую временную корреляцию. Разверните внутренние серверы точного времени и строго контролируйте их использование всеми системами.
- Непонятные сообщения. Логи типа «Ошибка #0x5A3» бесполезны. Требуйте от разработчиков информативных сообщений, которые можно интерпретировать без знания кода приложения.
- Хранение критичных логов только локально. Это первое, что будет очищено при атаке.
- Игнорирование прикладного уровня
Сетевая защита может не заметить успешную SQL-инъекцию, если она выполнена в разрешённом HTTPS-сеансе. Именно логи приложения покажут аномальные запросы с внедрёнными командами.
- Короткий срок хранения. Удаление логов через месяц может уничтожить доказательства целевой атаки, которая развивалась поэтапно в течение полугода. Сроки хранения должны быть привязаны к циклу жизни возможных инцидентов и регуляторным требованиям.
Не настраивайте и не забывайте: постоянно проверяйте
Конфигурация логирования устаревает с первого дня. Её нужно постоянно валидировать.
- Учения на основе сценариев. Регулярно моделируйте реальные атаки, например, по тактикам MITRE ATT&CK. После каждого учения проводите ретроспективу: можно ли было восстановить всю цепочку атаки по собранным логам? Каких ключевых событий не хватило?
- Аудит настроек. Внесите конфигурации логирования (агентов, правил аудита) в систему управления конфигурациями. Автоматизируйте проверку, чтобы на критичных серверах логирование не было отключено вручную.
- Анализ покрытия ATT&CK. Сопоставьте техники из актуальной матрицы угроз с вашими источниками логов. Для каждой техники должен быть хотя бы один источник, фиксирующий её проявление. Отсутствие такого источника — прямая слепая зона.
[ИЗОБРАЖЕНИЕ: Диаграмма, отображающая жизненный цикл лога: от генерации на источнике, через защищённую передачу, нормализацию и обогащение в SIEM, до попадания в «горячее», «тёплое» и «холодное» хранилище с указанием сроков хранения и целей использования на каждом этапе.]
Конечная цель — не просто собрать данные, а создать параллельную систему документирования, максимально изолированную от основной инфраструктуры. Она должна продолжать фиксировать события даже тогда, когда другие системы уже не подконтрольны. В этом её главная ценность для расследования.