Логирование событий UEFI: минимальный перечень для расследований

Зачем вообще логировать UEFI события

Загрузка компьютера - момент, когда можно обойти многие защитные меры ОС. Если злоумышленник меняет настройки UEFI или пытается стартовать с внешнего носителя, в Windows уже может не быть ни следов, ни привычных логов. Поэтому события на уровне UEFI полезны не только для ИБ, но и для расследований, где важна хронология: что происходило до запуска системы.

На уровне прошивки обычно заметны действия, связанные с попытками изменить доверенную цепочку загрузки или способ старта устройства: включение или отключение Secure Boot и изменения ключей, смена порядка загрузки (Boot Order), попытки загрузки с USB, внешних дисков или по сети (PXE), сброс настроек UEFI, обновление прошивки и ошибки проверки подписи.

Эти записи отвечают на вопросы, с которых обычно начинают ИБ и аудиторы: что именно поменялось, когда, и на каких устройствах. Даже если прямого имени пользователя нет, событие можно связать с конкретным ПК, временем, сменой и физическим доступом (проходная, видеонаблюдение, заявки в ITSM).

Пример из практики: на рабочем месте в бухгалтерии пытались запустить утилиту с флешки, чтобы обойти пароль ОС. В журнале видно несколько попыток загрузки с USB и изменение Boot Order на съемное устройство. Это дает понятный старт для проверки: какие ПК затронуты, когда началось, и был ли успешный запуск.

Ограничения тоже есть. Не все платформы хранят журнал прямо в прошивке, а объем таких логов бывает маленьким и быстро перезаписывается. Поэтому события UEFI обычно дополняют сбором из ОС (например, события Secure Boot) и централизованной отправкой в SIEM.

Откуда берутся события: что может дать UEFI и связанная инфраструктура

UEFI редко выглядит как привычный «журнал событий», где есть все действия пользователя. Часть данных живет в настройках прошивки, часть - в TPM, часть - в журналах ОС после загрузки. На практике контроль строят как сбор нескольких источников, которые дополняют друг друга.

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

Secure Boot обычно дает более формализованные сигналы: включен ли он, какие ключи и базы доверия используются (PK/KEK и db/dbx), и были ли нарушения политики (например, попытка загрузить неподписанный загрузчик). Отдельно полезно отслеживать изменения dbx (черного списка): они часто приходят вместе с обновлениями и могут ломать совместимость.

TPM добавляет «измерения загрузки» (Measured Boot). Это не просто факт загрузки, а цепочка контрольных значений, которая меняется при подмене компонентов. Если измерения внезапно отличаются от ожидаемых для этой модели и образа ОС, есть повод проверить, не меняли ли загрузчик, драйверы ранней загрузки или настройки прошивки.

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

Обычно набор источников выглядит так:

• UEFI/BIOS Setup: текущие параметры и изменения критичных настроек
• Secure Boot: статус, ключи и базы db/dbx, нарушения политики
• TPM: измерения (Measured Boot) и отклонения от ожидаемых значений
• BMC (для серверов): удаленные действия, виртуальные носители, управление питанием

Пример: в ОС нет явных следов, но BMC зафиксировал подключение виртуального ISO, а TPM показал новую цепочку измерений. Вместе это дает понятную линию проверки: кто имел доступ к управлению, что менялось, и с какого момента устройство стало «другим».

Минимальный набор: события Secure Boot

Secure Boot часто дает самый ранний и самый полезный сигнал о том, что с загрузкой пытались что-то сделать. Для расследований важно не только знать, включен ли он, но и видеть любые изменения состояния и доверенных данных. Начните с событий, которые отвечают на три вопроса: режим был активен, доверие меняли, загрузку блокировали.

Минимум, который стоит фиксировать (с датой, устройством и учетной записью администратора, если она видна из ОС или инструмента управления):

• изменение статуса Secure Boot: включили, выключили, сменили режим проверки
• переход в Setup Mode, выход из него, сброс ключей до заводских
• операции с базами доверия: добавление, удаление, обновление или откат PK, KEK, db, dbx
• срабатывания проверки подписи: попытка загрузить неподписанный или измененный загрузчик
• блокировки по dbx: компонент попал в список запрещенных

Практический пример: у сотрудника «внезапно» перестала грузиться ОС после обслуживания. Если в событиях видно, что dbx обновили, а затем пошли блокировки по подписи, это похоже на штатное ужесточение (или ошибочное обновление). Если же перед этим был переход в Setup Mode и сброс ключей, это уже сильный признак вмешательства и попытки снять контроль доверия.

Сразу договоритесь о формате. Полезно фиксировать значение до и после (например, Secure Boot On -> Off), идентификатор события, версию прошивки и источник (UEFI/ОС/консоль управления). Так проще сравнивать хосты и искать массовые изменения.

Минимальный набор: порядок загрузки и его изменения

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

Что стоит собирать в минимальном наборе:

• изменения BootOrder (что было и что стало) и факт добавления новой Boot Entry
• смену приоритета между внутренним диском, сетью (PXE) и внешними устройствами
• включение или отключение источников загрузки (Network Boot/PXE, USB boot, оптика, Thunderbolt - если актуально для платформы)
• однократную загрузку через Boot Override (временный выбор другого устройства без сохранения порядка)
• факт входа в настройки UEFI/BIOS и попытки менять параметры (если платформа это пишет)

Почему это важно: злоумышленник часто не ломает ОС сразу, а сначала добивается загрузки с другого носителя. Типовой сценарий - на рабочем месте меняют приоритет на USB, пробуют загрузиться с флешки, не получается из-за Secure Boot, а затем возвращают порядок обратно. Если вы видите короткий промежуток между сменой BootOrder и возвратом, это повод поднимать физический доступ, камеры, заявки на обслуживание и учетные записи.

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

Минимальный набор: попытки загрузки с USB и внешних устройств

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

Собирайте события так, чтобы по ним было понятно: кто инициировал загрузку, с какого устройства, и почему загрузка не состоялась (если не состоялась). Минимум, который обычно дает пользу:

• попытка загрузки с внешнего носителя (USB-накопитель, внешний SSD/HDD, USB-CD/DVD, SD-ридер) с указанием типа устройства и, если доступно, идентификаторов
• результат попытки: загрузка началась, отменена, устройство не найдено, выбранный загрузчик отсутствует
• одноразовый выбор устройства через Boot Menu (boot override): факт вызова меню и выбранный пункт
• причина блокировки: Secure Boot отказал, подпись не прошла проверку, запрещенный тип носителя, политика запрета внешней загрузки
• повторные попытки загрузки или циклы перезагрузок, если они связаны с поиском внешнего загрузочного устройства

Важно различать два похожих случая: (1) человек реально пытался загрузиться с флешки, и (2) система по очереди проверила внешние устройства из-за настроенного порядка загрузки. Если лог не разделяет эти сценарии, рядом должны быть события о вызове Boot Menu и изменении разового выбора загрузки - тогда картина становится понятнее.

Пример: на рабочем ПК ночью фиксируется вызов Boot Menu и выбор USB-устройства, после чего идут записи об отказе Secure Boot. Даже без успешной загрузки это повод проверить физический доступ, учетную запись, и сопоставить время с проходной и видеонаблюдением.

Что добавить сразу: прошивка, сбросы и критичные настройки

Если вы уже собираете Secure Boot и изменения порядка загрузки, следующий шаг - события, которые часто идут рядом с попыткой обхода защиты. Они происходят реже, но почти всегда важны для расследования.

Прошивка (BIOS/UEFI): обновления и откаты

Обновление прошивки может быть легитимным (плановое обслуживание), а может быть способом закрепиться на устройстве. Поэтому полезно фиксировать не только факт, но и контекст.

Минимум, который стоит записывать:

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

Сбросы, пароли и TPM

Сброс настроек UEFI к заводским и очистка параметров часто убирают ранее включенные ограничения. Это стоит поднимать как тревогу, особенно на рабочих местах и в критичных сегментах.

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

По TPM полезно фиксировать любые заметные события: очистку, отключение, смену режима работы (если платформа это отражает в журналах). После «очистки TPM» нередко возникают проблемы с BitLocker или корпоративными сертификатами, и это бывает ключевой уликой, что действия были не случайными.

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

Как это внедрить пошагово без перегруза

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

Дальше лучше идти короткими итерациями:

1. Выберите минимальные события и проверьте, где они вообще доступны в вашем парке. На части моделей это будут записи прошивки, на части - события ОС (например, про Secure Boot), где-то - только данные из управления (BMC/IPMI) на серверах.
2. Закрепите базовую защиту, иначе логи будут только констатировать проблему. Обычно хватает пароля на вход в настройки UEFI, запрета загрузки с внешних носителей там, где это возможно, и фиксации политики Secure Boot (чтобы ее нельзя было тихо отключить).
3. Настройте сбор так, чтобы он не зависел от ручных действий. Для серверов удобнее тянуть события через BMC, для рабочих мест - через корпоративные средства управления и отчеты, которые собирают события ОС и изменения конфигурации.
4. Определите, как это будет выглядеть в SIEM: единый формат полей (устройство, пользователь/учетка, время, тип изменения) и простые корреляции. Минимум - кто менял порядок загрузки, кто отключал Secure Boot, и были ли попытки загрузки с USB перед входом в ОС.
5. Введите регулярную проверку поступления событий. Обновления прошивки, замена материнской платы, новые партии ПК или серверов часто меняют поведение журналов - это нужно ловить заранее, а не в момент инцидента.

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

Варианты централизованного сбора и что выбрать

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

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

Для рабочих мест и там, где прямых UEFI-логов мало, хорошо работает регулярная инвентаризация конфигурации прошивки. Делайте снимки параметров (Secure Boot, порядок загрузки, запрет внешних устройств) по расписанию и ищите изменения между снимками. Так ловятся «тихие» правки, даже если отдельного события не было.

Где возможно, добавьте измерения TPM: они подтверждают целостность цепочки загрузки и помогают отличить реальную подмену от ложного срабатывания. Это особенно полезно для критичных узлов.

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

• Серверы: BMC журнал + снимки UEFI, затем TPM при необходимости
• Рабочие места: события ОС (старт/перезагрузки, результаты проверок Secure Boot, ошибки загрузки) + снимки UEFI
• Критичные сегменты: все выше плюс более частая проверка

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

• узел (серийный номер/инвентарный ID/hostname)
• источник (UEFI/BMC/TPM/ОС)
• кто инициировал (пользователь/админ/удаленная сессия/неизвестно)
• действие (изменение, попытка загрузки, включение/отключение)
• результат (успех/отказ/заблокировано политикой)

Если выбирать один «первый шаг», чаще всего это сбор на стороне ОС для корреляции по времени плюс регулярные снимки ключевых UEFI-настроек. Это дает быстрый эффект и понятные доказательства при проверке.

Типичные ошибки при логировании UEFI

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

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

Что обычно ломает картину:

• сбор «статуса» вместо «событий»: Secure Boot включен, но нет данных, когда и кем менялись настройки
• нет контроля BootOrder и разовых BootOverride, а также попыток загрузки с USB или других внешних устройств
• не сохраняется версия прошивки и история обновлений, из-за чего непонятно, это новое поведение или результат апдейта
• время на устройствах расходится, и записи невозможно нормально склеить в общий таймлайн
• логи хранятся слишком мало, и нет базовой линии настроек для сравнения

Простой пример: в офисе кто-то попробовал загрузиться с USB, потом вернул порядок загрузки «как было». Если вы собираете только «Secure Boot: enabled», все выглядит чисто. Если же у вас есть базовая линия (ожидаемый BootOrder), события попыток внешней загрузки и корректное время, вы увидите отклонение и сможете собрать понятный таймлайн.

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

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

Этот список помогает быстро понять, закрыты ли базовые риски на уровне прошивки и есть ли следы для расследований. Если на любой пункт ответ «не уверен», это повод проверить настройки и подтвердить их логами, а не скриншотом.

• Secure Boot включен, а база ключей не в состоянии «сброшено/Setup Mode». Любые операции с ключами (сброс, добавление, перевод в режим настройки) должны быть видны в журналах.
• Загрузка с USB и других внешних носителей запрещена по умолчанию. Если есть исключения (например, сервисные бригады), они оформлены как процесс, и каждая попытка загрузки с внешнего устройства фиксируется.
• BootOrder соответствует политике: нет неожиданных записей, сетевой загрузки без необходимости и «временных» загрузчиков. Изменения порядка загрузки должны попадать в аудит.
• Известна точная версия прошивки (UEFI/BIOS) и дата последнего обновления. Должно быть понятно, кто и когда обновлял, и был ли откат или сброс настроек.
• Аудит не живет на одном ПК: события прошивки и связанные события ОС собираются централизованно (SIEM или лог-хранилище), с понятным сроком хранения и поиском по устройству и пользователю.

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

Пример расследования: попытка загрузки с USB на рабочем месте

Ситуация: на рабочем ПК сотрудник при старте нажимает клавишу Boot Menu (например, F12) и выбирает USB-накопитель. Компьютер не загружается с флешки из-за Secure Boot или потому что загрузка с внешних устройств запрещена. Даже если попытка не удалась, она должна оставить следы, иначе вы не отличите случайную ошибку от подготовки к обходу контроля.

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

Как понять: ошибка или намерение

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

Признаки, которые настораживают:

• несколько попыток загрузки подряд с разных внешних устройств
• изменение BootOrder или включение опции загрузки с USB в настройках
• отключение или перевод Secure Boot в режим Setup/Custom (если это вообще возможно)
• перезагрузки с коротким интервалом и вход в настройки UEFI/BIOS
• попытки загрузки вне рабочего времени или на группе ПК

Какие данные собрать и как быстро оценить масштаб

Для доказательной базы нужны минимум: точное время (желательно с корректной синхронизацией), идентификатор ПК (серийный номер, имя, инвентарный ID), пользователь или консольный вход, состояние Secure Boot, факт изменения BootOrder и сведения о подключенном USB (VID/PID, серийный номер носителя - если доступно).

Чтобы оценить масштаб, начните с вопроса «это единичный случай или шаблон». Сравните последние 24-72 часа по аналогичным событиям: сначала по одному ПК, затем по подразделению, затем по всей площадке. Если видите одинаковые попытки на нескольких устройствах, ищите общий фактор: общий кабинет, общий ответственный, одинаковая модель ПК или одинаковая политика UEFI. На рабочих местах это удобно проверять в SIEM фильтром по попыткам загрузки с внешних устройств и изменениям параметров загрузки.

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

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

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

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

Практичный план внедрения:

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

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

Если инфраструктура относится к госсектору, финансам, медицине или образованию, часто требуется не только настройка политик, но и поддержка на уровне железа и интеграции мониторинга. В таких проектах GSE.kz (gse.kz) может поставить рабочие станции и серверы и помочь с системной интеграцией, чтобы контроль загрузки и сбор событий были единообразными по всей организации.