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