История о том, как я почти лишился контроля над собственной системой — и три рубежа, которые это предотвратили.
Где мы остановились
В первой и второй главах серии мы начали строить трёхуровневый SOC-пайплайн:
· L1 Triage (Claude Haiku 4.5) — разбирает поток алертов из SIEM, отсеивает шум от реальных угроз
· L2 Investigator (Claude Sonnet 4.6) — глубоко расследует конкретный инцидент, строит таймлайн событий, выносит вердикт
· SOAR Responder — на основе вердикта L2 формирует предложение о действии и ждёт «ДА» от человека
Весь этот пайплайн может управляться из Telegram-чата. Администратор пишет обычным языком — система отвечает. Никаких консолей и дашбордов: утром просматриваешь дайджест за ночь, в любой момент можешь написать команду «SOC» и получить сводку за последние 15 минут, а если нужно разобраться с конкретным инцидентом — нужно просто спросить.
В этой главе мы добавляем к системе CTI (Cyber Threat Intelligence, разведка угроз): перед вынесением вердикта L2 начинает сверяться с глобальными базами данных угроз — что весь мир уже знает про этот IP-адрес или этот файл.
Что могло пойти не так — пошло.
19 июля 2024, 5:00 UTC
8.5 миллиона Windows-машин по всему миру выпали в синий экран.
Это произошло не от вируса. Это произошло от апдейта антивируса. CrowdStrike Falcon — продукт ценой $1–50 миллионов на enterprise-лицензию, защита 60% крупнейших компаний США — выкатил sensor update с багом в драйвере. Драйвер падал ядром, ядро падало в BSOD, машина уходила в бесконечный цикл reboot → BSOD → reboot.
Аэропорты, банки, больницы, биржи — встали. Прямой ущерб только страховым подсчётам $5.4 миллиарда за первые сутки. Delta Airlines одна потеряла $500 миллионов.
CrowdStrike автоматически рассылает sensor updates без gate-stage у клиента — это фича, маркетинговое преимущество («zero-day защита через 8 минут»). После инцидента индустрия задумалась о staged rollouts на стороне клиента — и часть зрелых компаний теперь так и делает. Но реальность 2025-го: далеко не все перешли. А staged rollout сам по себе не гарантия — если баг проявляется только на боевой нагрузке, тест-среда покажет чисто.
Это современная версия Knight Capital — про которую я писал во второй главе серии. Только Knight Capital было про финансовую автоматизацию, а это про security.
Сегодня в моей лаборатории чуть не повторилось то же самое — в миниатюре. Только спасло одно — паттерн, который я заложил в основу с первого дня.
В чём суть подключения CTI к L2 Investigator
Идея простая: когда L2 видит в системе мониторинга подозрительный внешний IP-адрес, он должен уметь спросить у AbuseIPDB — «что InfoSec мир знает про этот адрес?»
Реализовал, протестировал. Работает. Запускаю end-to-end тест в Telegram: в чате SOC-боту пишу команду:
l2 185.220.101.1
Это Tor exit node — точка выхода трафика из анонимной сети Tor, отмеченная как максимально подозрительная (AbuseIPDB confidence score = 100). Подобные узлы нередко служат источником вредоносного трафика: через них могут проводиться сканирования, DDoS‑атаки или попытки несанкционированного доступа. Проверка в наших системах показала:
-
Wazuh: логов с этим IP нет;
-
CTI: оценка подозрительности — 100 (максимальная);
-
Вердикт: IP опасен в общем контексте, но не контактировал с нашей инфраструктурой.
Жду 30 секунд. Прилетает ответ от бота. И это не то, что я ожидал.
🤖 SOAR — предлагаемое действие
Тип: disable_ad_user Цель: admin Риск: 🟠 high
Учётная запись admin подтверждённо используется для pass-the-hash lateral movement (rule 92652, 25 алертов) с атакованного хоста WS25BD на оба хоста домена. Encoded PowerShell scheduled task создан под этим же пользователем. Отключение останавливает активное распространение.
Применить? Ответь ДА или НЕТ (60 сек).
Палец завис над клавиатурой.
Сообщение уверенное. Аргументация выглядит профессионально. Конкретные номера правил, конкретное количество алертов, конкретная техника из матрицы атак MITRE. Будь это сообщение от живого аналитика — я бы согласился, не задумываясь.
Но я знал две вещи.
Первое: я спросил про IP 185.220.101.1. А ответ — про admin-аккаунт и какие-то подозрительные логины недельной давности. Это вообще не мой запрос.
Второе: admin — это операционный аккаунт, через который работает вся автоматизация лаборатории. WinRM-скрипты, агент мониторинга Wazuh, сам SOAR-executor. Если я нажму ДА — система отрежет сама себя от возможности что-либо делать. Рекурсивная блокировка: SOAR не сможет даже откатить эту самую блокировку.
Я нажал НЕТ.
Что AI увидел в логах
После того как timeout закрыл карточку подтверждения, я разобрал откуда взялись «доказательства» L2:
· 25 алертов о подозрительных логонах под пользователем admin — на самом деле: мои скрипты автоматизации, которые через WinRM управляют хостами для калибровок
· Зашифрованная задача PowerShell под тем же admin — на самом деле: демо Purple Team-упражнения, которое мы проводили несколько дней назад. Задача удалена в тот же день, но алерт в системе мониторинга остался навсегда
· Движение между серверами WS25BD → WS2022 под admin — на самом деле: я и бот ходим между хостами для калибровок, это норма для нашей лабы
Это не «галлюцинация» в обычном смысле слова. L2 видел реальные данные. Он просто не знал, что эти данные — артефакты собственных тестов. И не имел дисциплины временного окна — посмотрел всё подряд за неделю, как будто это всё происходит прямо сейчас.
Четыре одновременных бага
Разбор вскрыл четыре проблемы, каждая из которых по отдельности некритична — но все вместе дают именно такой результат.
L2 посмотрел в логи за неделю, увидел накопленные тестовые следы — и связно интерпретировал их как активную атаку прямо сейчас. Каждое отдельное «доказательство» существует в реальности. Общая картина — полностью ложная.
1. Scope creep
Я попросил про конкретный IP. L2 имел полную свободу в расследовании — мог обращаться к любым источникам данных в любом порядке. Когда разведка угроз вернулась «score 100, в нашей системе 0 совпадений» — L2 не остановился на верном ответе «контакта нет, добавить в watchlist», а пошёл искать что бы ещё рассказать.
В реальном SOC это называется сверхусердный аналитик. Спрашиваешь «проверь email vasiliy@xyz.com», а он за час расскажет тебе про всю инфраструктуру компании. Иногда полезно. Часто — опасно.
2. Устаревшие данные как «живые»
Запросы к системе мониторинга по умолчанию смотрели на 24–72 часа назад. Если за это окно накопилось 50 тестовых логонов admin — для L2 это выглядит как 50 ongoing атак прямо сейчас. Никакого учёта давности событий.
3. Пропущенная калибровка для операционного аккаунта
В инструкции для L2 было прописано: «Kali = Red Team, не блокировать». Но не было: «admin = операционный аккаунт, который сам делает наши автоматические действия».
В production-среде под автоматизацию заводят отдельный служебный аккаунт — svc_soar, svc_winrm — с минимальными правами. В лаборатории для скорости я использовал admin напрямую. Это удобно, но создаёт ровно тот класс путаницы: система не может отличить «операционный трафик» от «враждебной активности под угнанным администратором».
4. Отсутствие защиты на уровне исполнителя
L2 мог предложить отключение любого аккаунта, включая admin и Administrator. Никаких фильтров на уровне исполнителя.
Это архитектурный пробел: даже если добавить в инструкцию «не предлагай отключить admin», модель может обойти это в новой сессии или просто не учесть при нестандартном контексте. Нужен жёсткий запрет в коде — защита, которая не зависит от того, что решил AI.
Defense in depth — три рубежа
Я применил три независимых fix’а, потому что один уровень защиты — это single point of failure
Рубеж 1: Инструкция агенту
Это обычный текст на русском языке — такие инструкции не требуют программирования, они пишутся как служебная записка. Вот фрагмент того, что добавилось в инструкцию L2:
## Защищённые аккаунты (НИКОГДА не предлагать disable)
— admin / Administrator на lab.local — operating account SOAR’а
— admin@ya.ru, локальный Boss на PHY-HOST — владелец лабы
## Дисциплина scope и time-window
— Спросили про X — отвечай про X, не уходи в общий обзор
— При pivot — смотри последние 1-6 часов, не 24-72
— 0 hits = верный ответ, а не повод «посмотреть что ещё»
## Калибровка noise
— rule 92652 под admin с 192.168.1.14 (Ubuntu) — это наша автоматизация
— Encoded PS scheduled tasks под admin от 12.05 — Purple Team артефакты
12 строк. Изменяет поведение L2 в нужную сторону. Но этот рубеж мягкий — инструкцию можно забыть обновить при следующем изменении, модель может интерпретировать иначе при нестандартном контексте.
Рубеж 2: Список защищённых объектов в инструкции
Явный список: «target никогда не должен быть admin». Гибче чем жёсткая техническая проверка (можно добавлять новые защищённые аккаунты без изменения кода), но слабее чем запрет на уровне исполнителя.
Рубеж 3: Жёсткий запрет в коде
Самый последний рубеж — несколько строк, которые выполняются независимо от того, что решил AI:
PROTECTEDACCOUNTS = {«admin», «administrator»,
«lab\\admin», «lab\\administrator»}
def disable_ad_user(sam_account_name: str, reason: str) -> dict:
if sam_account_name.strip().lower() in PROTECTEDACCOUNTS:
return {«status»: «error»,
«error»: «refused: protected operating account — «
«disabling it would lock the executor out»}
# … обычная логика
Даже если L2 снова предложит отключить admin, и человек по ошибке нажмёт ДА — этот слой откажется выполнять. Это гарантия за пределами AI: не зависит от промпта, не зависит от модели, не зависит от контекста сессии.
Это и есть defense in depth: каждый слой может ошибиться. Все три одновременно — крайне маловероятно.
Re-test: тот же запрос, другой результат
После применения всех трёх fix’ов я снова написал в Telegram l2 185.220.101.1.
Ответ:
🎯 Вердикт: 🟡 needs_more_data IP является крайне опасным Tor exit node (score 100/100), однако в Wazuh-логах за последние 24 часа нет ни одного алерта, связывающего этот адрес с нашими хостами.
Рекомендация:
1. Расширить временной горизонт — проверить за 7 дней
2. Проверить firewall/netflow логи
3. Добавить в watchlist
SOAR-действие не предложено: прямого контакта с нашими хостами не зафиксировано.
Это тот ответ, который я ожидал в первый раз. Сфокусированный на запрошенной сущности, честный про отсутствие данных, без выхода за рамки.
Разница в результате — 60 строк в инструкции + 5 строк кода.
Три урока при внедрении AI, которые масштабируются на любую компанию
Уверенно ошибающийся AI — это норма, а не баг
Современные языковые модели умеют звучать убедительно независимо от того, правы они или нет. Это их сильная сторона (хорошо объясняют) и одновременно главный риск в security automation. Когда AI уверенно рекомендует действие — это сигнал применить confirmation pattern, а не сигнал что аргументы валидны.
Аналитик в реальной компании не всегда знает контекст каждого алерта — особенно если он на смене две недели, документация отстаёт на полгода, а в SIEM сотни событий в день. Если AI пишет уверенный текст «25 атак, lateral movement подтверждён» — даже опытный специалист может нажать ДА в три ночи. Через 5 минут компания без домен-администратора, через 10 — без SOC, через 30 начинается разбор полётов.
Это не «невнимательный аналитик» — это прогнозируемая ошибка под когнитивной нагрузкой. Confirmation pattern не страхует от невнимательности; он страхует от обычной человеческой усталости в кризисной ситуации.
Один уровень защиты — это ноль уровней
Часть SOAR-вендоров предлагает «fully autonomous mode» как маркетинговое преимущество («AI сам решит — экономия времени»). Для блокировки трафика на сетевой границе при DDoS — возможно оправдано: решают секунды, blast radius ограничен. Но для отключения пользователей и серверов внутри инфраструктуры по вердикту AI без человека — не включай. После CrowdStrike всё больше руководителей готовы платить за подтверждение прежде чем действие.
Confirmation pattern → список защищённых объектов → жёсткий запрет в коде. Все три одновременно. Defense in depth, не in breadth.
Старые тесты живут в SIEM навсегда
Я провёл Purple Team-упражнение неделю назад и удалил тестовую задачу в тот же день. Но алерт в системе мониторинга остался. И через неделю L2 нашёл его и подал как доказательство активной атаки.
Либо настраивай временное окно при запросах к SIEM (1–6 часов вместо 24–72), либо явно тегируй тестовые события («это Purple Team, не настоящее»). Wazuh из коробки этого не делает — это ручная работа.
Calibration — это не одноразовое событие
Каждый новый этап и каждый новый сценарий открывают новые calibration gaps. В зрелом SOC аналитики тратят 40–50% времени на настройку правил — не на расследования. В менее зрелых командах calibration бывает разовым событием при внедрении, после чего система годами генерирует поток ложных срабатываний и аналитики начинают их игнорировать. Calibration — это операционная дисциплина, а не этап деплоя.
В следующей главе серии
Эта история — второй случай, когда AI уверенно ошибся и система спасла себя. Первый был про «L2 отказался блокировать Red Team» — там AI был прав против моих собственных попыток его обмануть. Сейчас — обратная ситуация: AI был уверен в неправильном решении.
Оба случая закрылись одним и тем же паттерном — human in the loop.
После того как мы убедились что L1 и L2 могут ошибаться в обе стороны, следующий вопрос естественный: что происходит, когда в систему приходит не алерт, а сотрудник? Точнее — уходит.
Следующая глава серии — про Active Directory, уволенных сотрудников и скрытые риски спящих учётных записей: история одной утечки, которую можно было предотвратить.
Этот материал — часть серии «AI Innovation Lab» про построение AI-augmented SOC. Каждая глава — реальный кейс из жизни проекта.
ссылка на оригинал статьи https://habr.com/ru/articles/1045636/