КАК ПОЯВЛЯЕТСЯ СЛЕПАЯ ЗОНА

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

Срабатывания прекращаются. Очередь становится чище. Проблема выглядит решённой.

А потом проходит время.

Скрипт переносят на другие серверы. Права учётной записи расширяют. Меняется владелец системы. Первоначальная причина исключения остаётся где-то в старой заявке, которую уже никто не помнит.

Но само исключение продолжает работать.

Если учётные данные будут скомпрометированы, атакующий получит не только их привилегии. Он унаследует доверие, которое когда-то выдал SOC.
Теперь PowerShell запускает уже не администратор. Поведение изменилось, контекст изменился, риск изменился.
А SIEM продолжает молчать.

Он не сломан. Он точно выполняет просьбу команды не смотреть в эту сторону.

КОГДА ИСКЛЮЧЕНИЕ СТАНОВИТСЯ ОПАСНЫМ

Исключение не означает, что активность безопасна.
Оно означает, что мы решили её не анализировать.

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

Опасность начинается тогда, когда временное решение становится бессрочным.

У исключения нет владельца. Срок пересмотра не указан. Условие сформулировано слишком широко. Никто не проверяет, соответствует ли оно текущей инфраструктуре.

Так белый список постепенно превращается в архив старого доверия.

В нём остаются сервисные учётные записи, которые давно используются иначе. IP-адреса переходят другим системам. Каталоги меняют назначение. Административные инструменты обновляются, а исключения продолжают действовать так, словно вокруг ничего не произошло.

ДОВЕРИЕ К ОДНОМУ ПРИЗНАКУ

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

Представьте два похожих исключения.

В первом случае SOC подавляет алерт для конкретного подписанного скрипта, который запускается определённой учётной записью на известном сервере в рамках ожидаемого задания.

Во втором — игнорирует любой запуск PowerShell от имени этой учётной записи.

Оба варианта уменьшают шум.
Но первый описывает нормальное поведение. Второй создаёт территорию, на которой почти любое поведение заранее считается нормальным.

Чем шире исключение, тем удобнее в нём спрятаться.

БЕЛЫЙ СПИСОК — ЭТО ИЗМЕНЕНИЕ ЗАЩИТЫ

Относиться к исключению нужно не как к технической настройке, а как к изменению логики обнаружения.

Команда должна понимать, какую активность она перестаёт видеть и почему считает это допустимым. У такого решения должен быть владелец, способный подтвердить его необходимость.

Должна существовать дата, после которой доверие будет пересмотрено, а не продолжено автоматически.

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

Убрать конкретный шум — нормально.

Отказаться от видимости поведения целиком — уже нет.

С ЧЕГО НАЧАТЬ ПРОВЕРКУ

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

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

Если никто не помнит причину, владельца невозможно найти, а срок действия нигде не указан — перед вами не управляемое исключение.

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

Иногда результат оказывается неприятным.
EDR ничего не блокирует. SIEM не создаёт алерт. Аналитик не видит активности.

Атакующий мог бы продолжать работу в зоне, которую команда сама сделала невидимой.

БЕЛЫЙ СПИСОК ТОЖЕ НУЖНО КОНТРОЛИРОВАТЬ

Каждое исключение — это обмен.
Мы уменьшаем шум, но принимаем риск что-то пропустить.
Этот обмен должен быть осознанным, ограниченным и обратимым.

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

НеДобрый SOC

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

#SOC #SIEM #EDR #DetectionEngineering #BlueTeam #Кибербезопасность