После первичного взлома веб-сервера нарушителю нужно быстро понять окружение, найти ценные данные и выбрать следующий шаг. AI ускоряет этот этап: помогает разбирать ошибки, подбирать команды и связывать разрозненные сведения в план действий.
Главный риск для SOC — продолжать искать только известный инструмент или один индикатор. AI-ускоренная посткомпрометация выглядит как быстрые серии действий, где оператор меняет подход почти сразу после ответа системы.
Как это выглядит в атаке
В защитном разборе цепочка выглядит так: нарушитель получает первичный доступ, собирает сведения о сервере, использует AI для анализа результата команд, выбирает путь к данным или повышению прав и быстро проверяет несколько гипотез.
- получить первичный доступ к веб-серверу;
- собрать сведения о системе, пользователях и сетевых связях;
- передать вывод команд в AI для краткого анализа;
- получить варианты дальнейших действий;
- проверить доступ к внутренним ресурсам;
- попытаться закрепиться или вывести данные.
Какие следы искать
- необычные последовательности команд оболочки;
- короткие интервалы между разведкой и новыми действиями;
- запуск нестандартных файлов из временных каталогов;
- исходящие соединения к неизвестным адресам;
- обращения к внутренним узлам после анализа сервера;
- события EDR по разведке и повышению прав.
Защитные действия
- связывать команды оболочки в цепочки по времени;
- ограничить исходящие соединения с веб-сервера;
- включить контроль запуска из временных каталогов;
- собирать журналы процессов и сетевых соединений;
- настроить тревогу на быстрый переход от разведки к доступу к данным;
- изолировать сервер при совпадении нескольких признаков.
Практический кейс
Кейс: после эксплуатации уязвимости веб-сервера SOC видит серию команд разведки, затем быстрые обращения к внутренним адресам и запуск неизвестного файла. AI в защите собирает цепочку в краткую карточку, показывает временные интервалы и предлагает проверить исходящие соединения, но блокировку подтверждает аналитик.
Минимальный набор проверок
- проверить журналы веб-сервера за час до первых команд;
- найти новые процессы и дочерние оболочки;
- сопоставить сетевые соединения с командами;
- проверить изменение файлов в рабочем каталоге;
- посмотреть обращения к внутренним сервисам;
- создать правило для похожей последовательности.
Настройка контроля
Чтобы материал был применимым, сценарий нужно перевести в набор настроек. Команда должна заранее определить, какие события собираются, кто принимает решение и где AI может только помогать аналитику.
- выделить источник данных и владельца процесса;
- описать допустимые действия AI-помощника;
- запретить автоматическое выполнение опасных решений;
- включить журнал запросов, ответов и решений;
- маскировать секреты и персональные данные;
- проверять вывод на контрольных примерах.
Поля для SIEM
- время события и источник;
- учётная запись, роль или сервис;
- тип действия: чтение, запуск, изменение, загрузка или вход;
- объект действия: файл, сайт, устройство, приложение или данные;
- признаки риска и причина повышения приоритета;
- решение аналитика и итог проверки.
Если AI используется для обогащения карточки, он должен ссылаться на конкретные события. Неподтверждённые предположения нужно явно отделять от фактов.
Проверка качества
- сравнить вывод AI с ручной проверкой;
- проверить ложные срабатывания на штатных событиях;
- добавить отрицательные примеры;
- проверить маскирование чувствительных данных;
- запретить автоматическое изменение прав и настроек;
- обновлять правила после каждого разбора.
Разбор после пилота
Через две недели пилота нужно оценить не только скорость, но и качество решений. Если AI ускорил разбор, но добавил неподтверждённые выводы, сценарий нужно сузить и добавить новые ограничения.
- сколько карточек разобрано быстрее;
- сколько выводов подтвердилось;
- какие поля журнала чаще всего отсутствовали;
- какие правила дали шум;
- какие действия нельзя автоматизировать;
- какие контрольные примеры добавить.
AI делает посткомпрометацию быстрее, поэтому SOC должен видеть темп, связность и смену действий. Чем раньше цепочка собрана в один инцидент, тем меньше времени остаётся у нарушителя.
Пример настройки правила
Правило не должно зависеть от одного признака. Надёжнее считать риск по сумме небольших отклонений, чтобы тревога появлялась только при связанной цепочке действий.
- первый признак: новое действие или новый источник;
- второй признак: короткий интервал между связанными событиями;
- третий признак: доступ к чувствительному объекту;
- четвёртый признак: нетипичная роль или устройство;
- пятый признак: повторение похожих попыток;
- итог: повышение приоритета и отправка аналитику.
Как использовать AI безопасно
AI можно подключать к разбору только после нормализации событий. Он должен получать уже очищенные данные и возвращать объяснение, которое аналитик может проверить по журналам.
- передавать только нужное окно времени;
- заменять секреты и токены на маркеры;
- указывать источник каждого события;
- запрещать вывод без ссылки на факт;
- сохранять запрос и ответ в карточке инцидента;
- не давать AI права менять настройки или доступы.
Рабочая процедура для команды
Процедура должна быть понятна дежурному аналитику. Если правило сработало ночью, человек должен увидеть краткую цепочку, список доказательств и следующий безопасный шаг.
- открыть карточку с полной цепочкой;
- проверить самые ранние события;
- сравнить действия с обычным поведением владельца;
- посмотреть связанные сетевые и файловые события;
- принять решение об изоляции или наблюдении;
- записать причину решения в журнал.
Типовые ошибки внедрения
Частая ошибка — доверять красивому резюме и не проверять исходные события. Другая ошибка — сразу включать автоматическую блокировку. В начале лучше использовать режим наблюдения и постепенно уточнять пороги.
- нет списка разрешённых источников данных;
- не настроено маскирование секретов;
- AI получает слишком большой контекст;
- правило не показывает причину срабатывания;
- нет отдельного теста на ложные срабатывания;
- опасное действие выполняется без подтверждения.
Критерии завершения внедрения
Сценарий можно расширять только после проверки качества. Команда должна видеть, что правило ловит нужные цепочки, AI не придумывает факты, а аналитик может повторить вывод вручную.
- есть набор контрольных событий;
- есть описание ложных срабатываний;
- понятно, какие поля обязательны;
- есть порядок отключения AI-обогащения;
- есть владелец правила и срок пересмотра;
- есть отчёт о пользе после пилота.
