Минимально достаточный набор журналов для расследований: что собирать, где хранить и как проверять доступность

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

В статье старший аналитик УЦСБ SOC Вадим Штырев рассматривает фундаментальные аспекты ее построения: выбор стратегии хранения, приоритизацию источников и мониторинг доступности.

Ключевые форматы и особенности журналов событий

Журнал в контексте расследования инцидентов информационной безопасности – это, как правило, файл, который хранит в себе записи (они же логи) об определенных изменениях или действиях, произошедших в рассматриваемой системе. Но в некоторых случаях журнал может представлять собой и таблицу в базе данных. Подобные логи же в свою очередь хранятся в определенном формате: строка, xml, json, бинарный файл.

Если приводить примеры для перечисленных выше форматов, то в формате xml хранят записи журналы с расширением .evtx операционных систем Windows, расположенные на системном диске по стандартному пути ‘WindowsSystem32winevtLogs’, а строка – это история для большинства журналов в семействе ОС Unix. В качестве примера бинарного формата можно привести логи journald, которые он же и собирает, и без его использования их просто так не прочитать.

Где хранить: сравнительный анализ локального и удаленного хранения логов

Для хранения логов есть два основных варианта: непосредственно в памяти устройства, которое и сгенерировало журнал, или на удаленном лог-коллекторе или SIEM, если дополнительно требуется в режиме реального времени детектировать возможные атаки. У каждого подхода есть свои преимущества и недостатки.

Плюсы при хранении логов непосредственно в исходной системе следующие:

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

На этом плюсы данного подхода заканчиваются. Перейдем к минусам:

1. При описании преимуществ мы упоминали такой процесс, как ротация логов. Он предназначен для контроля размера хранимых локально на устройстве файлов логов и их архивации. Если ротация не настроена, то определенный файл журнала может достигнуть такого размера, что хранимая глубина его событий будет нести больше вреда, нежели пользы, занимая все свободное место на устройстве. Для этих целей в Unix-системах можно использовать утилиту logrotate, а в Windows может пригодиться утилита wevtutil или оснастка eventvwr.msc (она же «Просмотр событий», или «Event Viewer»), с помощью которой можно задать максимальный размер журнала.
2. При получении доступа к устройству злоумышленник нередко стремится отключить хранение событий, удалить логи или зашифровать устройства. В таком случае с большой вероятностью записи о произошедшем будут утеряны, забрав у исследователя львиную долю полезных при расследовании артефактов, заставляя довольствоваться не менее важными, но не заменяющими журналы артефактами.
3. Логи могут быть тяжело читаемыми в своем исходном виде и потому их анализ может занять длительное время.
4. Изучение логов отдельно взятого устройства вне контекста происходящего в остальной инфраструктуре. Из-за этого можно упустить продолжение вектора либо предшествующую ему активность в других системах.

Перейдем к централизованному хранению на лог-коллекторах или SIEM. Такие решения включают в себя стек ELK (ElasticSearch, Logstash and Kibana), и имеют следующие преимущества:

1. Удобство просмотра логов со всей инфраструктуры в одном едином интерфейсе. В этом случае не требуется ходить с учетными данными от одной машины к другой в поисках необходимых записей, что сохраняет время при расследовании.
2. Второе: решения данного класса позволяют приводить события в удобный для чтения человеком вид, разбивая их по полям, что в свою очередь также позволяет настраивать фильтры, сортировки, выполнять запросы, выставлять интересующие диапазоны дат и времени.
3. В случае инцидента не страшна зачистка журналов или шифрование устройства, ведь при формировании лога он тут же отправляется на удаленное хранилище.
4. В случае использования SIEM — детектирование атак в контексте всей инфраструктуры, находящейся на мониторинге, а не отдельно взятого устройства, к тому же с возможностью производить корреляцию событий с разных устройств.

Минусы при таком подходе также существуют:

1. Требуется развернуть отдельное устройство или множество устройств с очень большим выделяемым дисковым пространством. И его потребуется тем больше, чем больше источников сбора вы подключаете и чем дольше хотите хранить полученные данные, добавляя сюда необходимость выделения достаточно быстрых дисков, чтобы без больших задержек обрабатывать запросы к наиболее свежим данным, которые также можно прозвать «горячей» зоной.
2. Централизованное хранение, являющееся плюсом, является и минусом такого подхода. При сбое есть высокий риск потери всех имеющихся данных, если отсутствуют резервные копии, наличие которых может также стать весьма затруднительным, особенно если с трудом был принят предыдущий минус, связанный с объемами хранения самих данных.

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

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

Необходимо также не забывать о проверке доступности источников событий при сборе логов в централизованное хранилище. Это возможно реализовать с помощью специальных скриптов или встроенных механизмов проверки. Например, некоторые из упомянутых ранее SIEM способны отслеживать поступление событий от какого-либо определенного хоста или определенного журнала с этого устройства. При обнаружении, что с узла или его журнала продолжительное время не поступают новые записи – система сигнализирует об этом, побуждая проверить доступность устройства, существование журнала, корректность работы задачи сбора и агента сбора, если таковой используется.

Определение перечня собираемых данных – также может вызвать затруднения. Типы и практическая ценность логов существенно различаются в зависимости от источника, как и сложность их сбора. Потому каждый частный случай стоит рассматривать отдельно, но можно выделить основы, взяв в пример ОС семейства Windows.

В Windows большинство журналов пишутся по ранее упомянутому пути ‘WindowsSystem32winevtLogs’ и имеют расширение .evtx. Здесь стоит отметить такие журналы, как Security, System, Application (собирает логи разного используемого ПО, например, MS SQL при использовании оного), журналы средств антивирусной защиты, журналы различных подключений, например, по таким протоколам, как RDP, SSH, SMB, журналы PowerShell и иные, некоторые из которых могут быть только на устройствах с конкретным назначением. Например, только у серверов MS Exchange будет одноименный журнал — MSExchange Management, который является весьма полезным, а если поднять веб-сервер, то это могут быть журналы IIS. И это, перечисляя лишь сами журналы, не погружаясь в настройки аудита системы и используемого ПО.

При расследованиях инцидентов информационной безопасности не стоит сводить всё исследование к одним журналам. Есть не менее важные по полезности и информативности цифровые артефакты, такие как оперативная память устройства, объекты файловой системы, для Windows: ветки реестра, Prefetch-файлы, кэш RDP и целая россыпь иных полезных данных. А также не стоит забывать про сетевой трафик, ходящий внутри вашей сети, который вы можете отлавливать и анализировать с помощью решений класса NTA (Network Traffic Analysis).