Архив закрытых инцидентов может оказаться не только внутренней базой знаний компании, но и материалом для внешней ИИ-модели. Обучение ИИ на инцидентах, которые сотрудники передают в инструменты безопасности и поддержки, превращает рабочие записи в отдельный риск: в них нередко есть технические детали атак, конфигурации, логи и сведения о клиентах. Об этой проблеме сообщает Dark Reading.
Речь не обязательно идёт о намеренной публикации данных или взломе поставщика. Риск появляется в момент, когда организация подключает ИИ-функции к привычным сервисам: платформам управления инцидентами, средствам аналитики, системам поиска по документации, продуктам для автоматизации SOC или корпоративным помощникам. Пользователь рассчитывает быстрее получить сводку и рекомендации, а вендор может использовать переданный контент для улучшения модели — если это разрешено условиями сервиса, настройками клиента или не запрещено договором достаточно явно.
Для службы безопасности архив инцидентов — особенно чувствительный набор данных. В нём могут быть IP-адреса, домены, фрагменты журналов, идентификаторы учётных записей, описание уязвимостей, порядок действий команды и внутренние исключения из защитных правил. Даже если отдельная запись выглядит безобидно, совокупность тикетов способна показать архитектуру компании, используемые средства защиты и типичные слабые места. Для злоумышленника это почти готовая карта местности; для конкурента или другого клиента поставщика — информация, которой у него не должно быть.
Проблема шире классической утечки. При обычном инциденте компания понимает, что данные покинули периметр, и начинает расследование: какие файлы ушли, кто получил доступ, нужно ли уведомлять клиентов и регулятора. При использовании записей для обучения модели граница размывается. Данные могут находиться у легитимного подрядчика, но при этом участвовать в процессах, которые заказчик не считал частью основной услуги. А удалить их из обученного поведения модели, если это вообще требуется и технически возможно, гораздо сложнее, чем стереть вложение из облачного хранилища.
Рост генеративных функций делает этот сценарий вполне практичным. Вендоры обещают автоматически резюмировать расследования, сопоставлять похожие случаи, предлагать шаги реагирования и отвечать на вопросы аналитиков на естественном языке. Эти возможности полезны: команда быстрее разбирает поток уведомлений и не ищет вручную похожий кейс двухлетней давности. Но качество ответа зависит от контекста, поэтому сервисы подталкивают клиента передавать всё больше исходных материалов. Именно здесь обучение ИИ на инцидентах перестаёт быть абстрактной юридической оговоркой и становится вопросом контроля над данными.
Разработчикам и инженерам безопасности стоит проверять не рекламное описание функции, а режим обработки конкретного тарифа и конкретной настройки. В документах важны ответы на несколько прямых вопросов: используются ли входные данные для обучения или улучшения моделей; действует ли запрет по умолчанию или его надо включать отдельно; распространяется ли он на логи, вложения и метаданные; кто выступает обработчиком данных; каков срок хранения; можно ли запросить удаление. Формулировки вроде «для улучшения сервиса» требуют расшифровки: за ними может скрываться и диагностика качества, и использование контента в более широком контуре разработки.
Практичная защита начинается с разделения данных по чувствительности. Не каждый запрос к ИИ-помощнику должен содержать полный дамп журналов, имя клиента или снимок конфигурации. Полезно заранее подготовить правила редактирования тикетов и шаблоны для передачи материалов внешнему сервису: заменять персональные данные и секреты, сокращать логи до необходимого фрагмента, не отправлять токены, ключи, внутренние адреса и полные схемы инфраструктуры. Для критичных расследований разумнее использовать изолированный контур или инструмент, в котором договорно и технически зафиксирован запрет на повторное использование данных.
Задача для CISO, юристов и закупок тоже меняется. Оценивать нужно не только соответствие поставщика требованиям к хранению данных, но и весь жизненный цикл информации внутри ИИ-функций. В контракте стоит отдельно описать цель обработки, запрет или допустимые рамки обучения, порядок уведомления об изменении политики и механизм возврата либо удаления данных. Если такую проверку проводить уже после подключения ассистента, команда безопасности окажется в знакомой, но неприятной роли: расследовать риск, созданный ради ускорения расследований.
ИИ в SOC и корпоративных системах будет становиться глубже встроенным в рабочие процессы, а не отдельным экспериментом в боковой панели. Поэтому главный вопрос не в том, полезны ли такие функции, а в том, кто получает право превращать чужой опыт реагирования в материал для собственной модели. Чем раньше компании сформулируют правила для обучения ИИ на инцидентах, тем меньше шансов, что их самый честный архив станет чужим источником знаний без осознанного согласия.
