Логи и аудит для расследования инцидентов: план подготовки

Зачем логи и аудит нужны именно для разбора инцидентов

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

Хороший журнал отвечает на простые вопросы: кто сделал действие, что произошло, где это было, когда и чем закончилось (успех, отказ, ошибка). Если хотя бы одного элемента не хватает, картинка разваливается.

Важно различать три слоя данных:

• Оперативные логи показывают состояние систем и ошибки здесь и сейчас.
• Аудит фиксирует значимые действия и изменения (входы, права, админские операции) и особенно важен для разборов и требований соответствия.
• Телеметрия описывает поведение (например, необычные запуски и сетевые связи) и помогает находить скрытые атаки.

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

Успех измеряется не количеством логов, а временем и повторяемостью:

• MTTD: сколько прошло до обнаружения.
• MTTR: сколько заняли подтверждение и разбор.
• Полнота: хватает ли данных, чтобы уверенно сказать, что произошло.
• Повторяемость: можно ли тем же способом разбирать следующий инцидент.

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

Что логировать: минимальный набор по источникам

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

Начните с аутентификации и управления доступом. Нужны успешные и неуспешные входы, MFA (запрос, успех, отказ), блокировки учетных записей, сбросы пароля, изменения ролей и членства в группах. Обязательно фиксируйте идентификатор пользователя, источник (IP, устройство), метод входа и причину отказа.

По сети часто «всплывает» то, что не видно на хосте. Полезны DNS (какие домены запрашивали), прокси или веб-шлюз (какие ресурсы открывали), VPN (подключения и выдача адресов), межсетевые экраны (разрешено/запрещено). Если есть NetFlow или аналог, он помогает быстро понять, куда и сколько данных уходило, даже без расшифровки трафика.

На конечных устройствах собирайте системные события ОС и безопасности, установку и удаление ПО, подключение внешних носителей, а также события EDR/антивируса (детекты, карантин, исключения). Если доступно, добавьте запуск процессов. Отдельно ценны логи важных пользовательских приложений, например VPN-клиента или криптопровайдера.

Почта и инструменты совместной работы часто становятся точкой входа. Нужны факты входов в ящик, открытия вложений и скачиваний, отправки и пересылки, а также создание правил (особенно авто-пересылки).

Для критичных систем (БД, ERP/CRM, файловые хранилища) фиксируйте аутентификацию, доступ к чувствительным таблицам и папкам, массовые выгрузки, изменения прав и админские операции.

Чтобы не утонуть в объеме, проверьте минимум по каждому источнику: кто совершил действие, когда, откуда, что именно произошло и к чему был доступ.

Пример: сотрудник «внезапно» вошел ночью через VPN. По связке VPN + вход в почту + создание правила пересылки + массовое чтение файлов на шару вы за часы увидите всю картину, даже если на ПК уже все «почистили».

Время и формат: чтобы события совпадали в одной линии

В расследовании важнее всего быстро собрать точную временную линию. Если на одном сервере время спешит на 3 минуты, на рабочей станции стоит другой часовой пояс, а в облаке лог пишется в UTC без явной метки, корреляция превращается в угадайку.

Первое правило - единая синхронизация времени. Настройте NTP на всех узлах: серверы, рабочие станции, сетевое оборудование, гипервизоры, системы безопасности. Проверьте, что синхронизация не просто включена, а реально работает (нет блокировок по сети и корректны источники времени).

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

Чтобы события из разных источников складывались в одну линию, заранее договоритесь о базовых полях:

• timestamp (UTC и точность)
• user (логин, UPN, SID или другой стабильный идентификатор)
• host (имя и роль, например workstation или server)
• src_ip (источник) и, если есть, dst_ip (назначение)
• action и result (что сделали и чем закончилось)

Дальше включайте нормализацию. Одно и то же действие должно называться одинаково, даже если разные системы пишут по-разному. Например, Windows пишет "Logon", VPN - "Authentication", а приложение - "Sign-in". В хранилище это лучше сводить к одному типу события, чтобы правила корреляции не разрастались.

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

Где хранить логи: практичные варианты размещения

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

Самый практичный старт - выделенный сервер (или пара серверов) под сборщик и хранилище в защищенном сегменте сети. В идеале это зона, куда отправляют события многие системы, но откуда нельзя «тихо» удалять или править записи обычным администраторам.

Он-прем, гибрид или отдельно в облаке

Он-прем оправдан, если есть требования хранить данные внутри организации или важно держать полный контроль над доступом. Гибрид часто удобнее: «горячие» логи (последние дни) хранятся локально для быстрых поисков, а архив уходит во второе хранилище с более дешевой емкостью. Полностью в облаке имеет смысл, когда нет команды для поддержки железа и нужно быстро масштабироваться, но ограничения по данным и доступам стоит проверить заранее.

Производительность и устойчивость

Мощность лучше считать не от «сколько терабайт купить», а от потока: сколько источников, как часто они пишут события, каков средний размер записи и какая нужна ретенция. Добавьте запас на пики во время инцидента.

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

Сроки хранения, доступ и защита от подделки

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

Ретенцию удобно задавать в трех горизонтах. Короткая - для быстрых разборов (детальные логи приложений и сетевые события). Средняя - когда инцидент заметили не сразу (аудит ОС, AD, почта, VPN). Длинная - для редких, но тяжелых случаев и проверок (критичные журналы безопасности, изменения прав, ключевые бизнес-системы). Частая ошибка - хранить все одинаково долго: дорого и мало полезно.

Неизменяемость логов критична. Если атакующий получил админ-доступ, он часто начинает с попытки «почистить» следы. Минимальный набор мер:

• запись в централизованное хранилище с запретом удаления и перезаписи (WORM/immutable-политики)
• отдельная учетная запись для приема логов без прав на их чтение
• контроль целостности (хэши, подпись, регулярная сверка)
• резервное копирование журналов по расписанию, отдельно от основной системы

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

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

Правила ретенции и доступа фиксируйте письменно: в политике ИБ или регламенте эксплуатации. Там же укажите сроки, ответственных, порядок выдачи доступа и формат выгрузок для расследований.

Как настроить сбор логов: пошаговый план на 2-4 недели

Чтобы журналы реально помогали, важнее всего не «поставить сборщик», а договориться об источниках, ответственности и проверках. Ниже - план, который обычно укладывается в 2-4 недели даже в разнородной инфраструктуре.

План работ по неделям

Неделя 1. Составьте список систем, которые почти всегда участвуют в инцидентах: AD/IAM, почта, VPN, межсетевые экраны, серверы, критичные приложения. Назначьте владельца на каждый источник: кто включает аудит, кто меняет настройки, кто подтверждает, что данные корректны.

Неделя 2. Включите нужные политики аудита и уровни логирования. Начните с обязательного минимума: входы, ошибки доступа, изменения прав, создание новых учеток, действия администраторов. Так вы получите пользу без лавины шума.

Неделя 3. Настройте отправку в центральное хранилище. Где возможно, используйте агент (обычно это надежнее), где нет - syslog. Зафиксируйте формат полей (время, хост, пользователь, IP, событие) и единый часовой пояс.

Неделя 4. Проведите тестовый период и подготовьте регламент реагирования. Для систем с повышенными требованиями сразу добавьте защиту от изменения логов и раздельный доступ.

Перед тем как считать работу завершенной, сделайте проверку качества на реальном сценарии: один сотрудник входит в VPN, меняет пароль, получает отказ в доступе, администратор создает тестовую учетную запись. По этим действиям вы должны увидеть сквозную цепочку событий за минуты.

Закрепите процесс в одном документе: кто смотрит алерты, как быстро отвечает, куда эскалирует и что считается инцидентом.

Корреляция событий и алерты: что настроить в первую очередь

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

Начните с корреляций, которые почти всегда полезны и легко объясняются бизнесу:

• множественные неудачные входы с одного адреса или по одной учетке
• успешный вход после серии неудачных, особенно если дальше идет доступ к почте или файлам
• вход с нового устройства или из нетипичного места для конкретного пользователя
• повышение привилегий (добавление в админ-группы, выдача прав на критичные системы)
• отключение защиты или очистка журналов на рабочей станции или сервере

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

Чтобы алерты были точнее, добавьте обогащение: справочник активов (что за сервер и где стоит), критичность систем, список админских учеток, принадлежность устройства отделу. Одно и то же событие на бухгалтерском ПК и на тестовой машине должно иметь разный приоритет.

Пороговые значения настраивайте постепенно. Сначала ставьте мягкие пороги и собирайте статистику 1-2 недели, затем ужесточайте. Если алертов слишком много, снижайте шум исключениями (известные сканеры, админские серверы, окна обслуживания), а не отключением правил.

Когда срабатывает правило, алерт должен сразу нести контекст: кто и где, что именно сработало, цепочку ключевых событий до и после (примерно 5-20 строк), важность актива и владельцев системы, а также понятное первое действие (проверить MFA, сбросить пароль, изолировать хост).

Как проводить разбор: простой алгоритм расследования

Разбор проще всего делать как последовательную проверку фактов. Цель - быстро понять, что произошло, когда началось, что затронуто и какие данные подтверждают выводы.

Сначала соберите «якорные» поля, по которым вы будете склеивать события: пользователь (логин, UPN, почта), устройство (hostname, ID агента), IP и география, процесс (имя, путь, командная строка), URL или домен, а если есть - хеш файла. Эти поля удобно выписать в заметку и дополнять по ходу.

Алгоритм на 60-90 минут

Дальше двигайтесь по одному маршруту:

• зафиксируйте первый признак (алерт, жалоба, аномалия) и точное время с часовым поясом
• постройте таймлайн: события до и после, пока не увидите последнее действие атакующего или момент блокировки
• сравните с «нормой» пользователя и устройства (обычные часы входа, привычные IP, стандартные приложения)
• выделите подтвержденные факты и отметьте, где данных не хватает
• сохраните артефакты: события, скриншоты, хеши, список затронутых учеток и устройств

Пример: вы видите подозрительный вход в почту сотрудника ночью. В таймлайне находите письмо со ссылкой, переход на URL, вход с нового IP, создание правила пересылки, скачивание вложений. «Норма» показывает, что сотрудник обычно работает днем и из другого города.

Что фиксировать в итогах

В итогах разделяйте факты и гипотезы. Факты подкрепляйте конкретными полями (время, пользователь, IP, действие). Отдельно запишите пробелы: какие журналы отсутствуют и что это помешало доказать. Если возможны юридические вопросы, заранее подготовьте пакет: таймлайн, перечень артефактов, кто и когда выгружал логи и где они хранились без изменений.

Пример инцидента: фишинг, подозрительный вход и утечка данных

Сотрудник получил письмо со «счетом» и открыл вложение. Через 10-15 минут в почту этой же учетной записи зашли с нового устройства, а затем кто-то начал просматривать и скачивать файлы из корпоративного хранилища. Через час коллеги заметили странные письма, отправленные «от имени сотрудника».

Чтобы такие случаи разбирались быстро, важно, чтобы события из разных источников складывались в одну временную линию. Здесь обычно решают четыре группы данных: почта, прокси и DNS, события на рабочем ПК, а также журналы входов и доступов к файлам.

Как подтверждают компрометацию

Картина становится ясной, когда совпадают несколько сигналов:

• почта: открытие вложения или переход по ссылке, затем создание правила пересылки или изменение настроек
• DNS/прокси: обращение к домену из письма и последующие соединения с редкими внешними адресами
• ПК: запуск процесса из папки загрузок, появление нового задания планировщика или необычная активность PowerShell
• входы: успешная аутентификация из нетипичного места, с нового устройства или в необычное время

Как сузить круг и сделать выводы

Сужайте расследование по четырем осям: время (первые минуты после открытия), узел (конкретный ПК), учетная запись (кто вошел и откуда), объекты доступа (какие файлы читали и скачивали). Если не хватает данных, это тоже результат: часто отсутствуют логи DNS, аудит доступа к файлам или отметки об изменениях в почтовых правилах. Добавьте эти источники, настройте единый часовой пояс и сохранение сырых событий, и похожий инцидент в следующий раз займет часы, а не недели.

Частые ошибки и ловушки при логировании

Самая частая проблема - вы тратите деньги, но не получаете ответа на главный вопрос: что произошло и когда. Ошибки обычно простые и повторяются из проекта в проект.

Первая ловушка - собирать слишком много без цели. Когда в систему летит все подряд, важные события тонут в шуме, а расходы на хранение и обработку растут. Заранее определите, какие типы событий нужны для расследований (входы, изменения прав, запуск админских утилит, доступ к данным), и отфильтруйте остальное.

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

Третья ловушка - плохая синхронизация времени (NTP). Если на разных серверах время разъехалось хотя бы на пару минут, цепочка атаки не складывается: сложно уверенно связать письмо, запуск файла, вход и доступ к ресурсу.

Четвертая ошибка - хранить логи там же, где может случиться инцидент. Получив доступ к серверу, злоумышленник часто пытается удалить журналы первым делом. Критичные логи нужно отправлять в отдельное хранилище или контур с ограниченным доступом.

Еще одна типовая проблема - нет ответственных. Алерты настроены, но непонятно, кто их смотрит, кто подтверждает инцидент, кто собирает доказательства и какие сроки реакции. Минимум, который стоит закрепить: владелец каждого источника логов, дежурный по алертам и порядок эскалации.

Короткий чеклист готовности к расследованиям

Когда случается инцидент, время часто уходит не на поиск атаки, а на попытки понять, где вообще есть следы. Этот чеклист помогает быстро оценить готовность.

Покрытие источников. События стабильно приходят со всех критичных систем: контроллеры домена и IAM, почта, VPN, EDR/антивирус, сетевые устройства (фаервол, прокси), серверы приложений, базы данных, облачные сервисы (если они есть). Если инфраструктура локальная, проверьте, что сбор не «обрывается» после обновлений и смены агентов.

Качество времени и связность. Временные метки совпадают (синхронизация, единый подход к часовым поясам), у событий есть идентификаторы для склейки: пользователь, хост, IP, ID сессии или запроса.

Поиск и доступ. Следователь за минуту находит «кто, откуда, куда и когда»: есть поиск по пользователю, IP, хосту и диапазону времени; результаты быстро сужаются фильтрами; доступ к логам выдан заранее, а не «в момент пожара».

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

Корреляции и эскалация. Есть 5-10 рабочих правил с понятными алертами и ясный маршрут: кто смотрит, в какие сроки, кому передает дальше.

Следующие шаги: как закрепить процесс и поддерживать инфраструктуру

Рабочий контур логирования - это процесс, а не разовый проект. Надежный путь - начать с пилота на 1-2 критичных сервисах, где цена простоя выше всего (например, почта и VPN, или домен и файловый сервер). На пилоте быстро видно, каких событий не хватает, где ломается сбор и как выглядит «нормальная» цепочка расследования.

Дальше закрепите правила в регламенте: не только что собирать, но и кто за это отвечает. Иначе аудит будет включаться от случая к случаю.

Минимальный регламент, который экономит время

В документе должны быть ответы на пять вопросов:

• кто включает и проверяет аудит на источниках
• кто отвечает за хранение, ретенцию и резервные копии
• кто и как получает доступ к логам (роли, заявки, сроки)
• что считается инцидентом и когда поднимается приоритет
• как часто проверяется, что сбор работает (ежедневно или еженедельно)

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

Если вы строите или обновляете локальную инфраструктуру под сбор и анализ событий, иногда проще опереться на готовые серверные платформы и интеграцию. Например, GSE.kz (gse.kz) как производитель и системный интегратор в Казахстане поставляет серверы S200 Series и помогает с проектированием и поддержкой ИТ-контуров, включая режим 24/7.

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