AI in Cybersecurity

AI помогает находить подозрительные события и разбирать угрозы, но им пользуются и атакующие. Рассмотрим обе стороны: от сортировки оповещений до фишинга и подделки голоса.

Коротко

AI in Cybersecurity — применение машинного обучения и языковых моделей для защиты цифровых систем. Они помогают находить необычное поведение, связывать события из разных источников и быстрее разбираться в оповещениях. Но AI не знает намерений пользователя и сам может стать целью атаки, поэтому его выводы проверяют по исходным журналам и правилам доступа.

Где AI помогает защитникам

Поиск аномалий

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

Аномалия ещё не равна атаке. Резкое изменение может быть обновлением, командировкой или новой рабочей нагрузкой. Поэтому полезный детектор показывает контекст: что изменилось, с чем это связано и какие исходные события подтверждают сигнал.

Разбор оповещений

Центр мониторинга безопасности (SOC) получает события от конечных устройств, сети, облака, почты и систем управления доступом. Модель может:

• объединить похожие оповещения в один инцидент;
• кратко пересказать цепочку событий;
• найти связанные учётные записи и устройства;
• предложить вопросы для дальнейшей проверки;
• подготовить черновик отчёта.

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

Классификация файлов и сообщений

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

Хорошая защита не пытается угадать «написал ли это AI». Она ищет признаки самой атаки: подмену домена, опасную ссылку, необычный запрос, запуск файла и изменение прав доступа.

Работа с уязвимостями

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

Как AI помогает атакующим

Генеративные модели могут ускорять подготовку материалов для атаки. Например, с их помощью злоумышленники пытаются:

• персонализировать фишинговые письма;
• переводить сообщения на язык жертвы;
• имитировать стиль знакомого человека;
• создавать поддельный голос или видео;
• объяснять код и переделывать известные техники;
• автоматизировать сбор открытой информации.

Это не превращает любую модель в автономного взломщика. Успех зависит от конкретной цели и доступных путей: это может быть техническая уязвимость, обман человека или злоупотребление уже полученными полномочиями. Меняется прежде всего скорость перебора и правдоподобие социальной инженерии.

Отдельная задача: защита самой AI-системы

Подключённый к рабочим данным ассистент добавляет новую поверхность атаки. Важные риски:

• prompt injection — вредоносная инструкция прячется в письме, документе или веб-странице;
• раскрытие данных — закрытая информация из контекста попадает в ответ или передаётся внешнему инструменту;
• небезопасные действия через инструменты — агент под влиянием постороннего текста пытается отправить письмо, выполнить команду или изменить запись;
• отравление данных — в базу знаний или обучающую выборку попадает специально подготовленный материал;
• уязвимая цепочка поставки — модель, библиотека или расширение загружены из недоверенного источника;
• утечка ключей доступа — секреты оказываются в логах, промптах или доступных файлах;
• кража модели — посторонний получает доступ к закрытым весам или копирует их из плохо защищённого хранилища.

Минимальные права, изоляция, журналирование и контроль секретов остаются полезны. В описании prompt injection от OWASP подчёркивается роль ограничения полномочий и проверки действий: одного указания модели игнорировать чужие команды недостаточно. На стороне приложения этот риск подробнее разобран в статье о prompt injection.

Источник программы важен и в творческих инструментах: сторонний пакет нод — исполняемый код, а не просто файл настроек. Для ComfyUI полезно отделить проверенную установку от экспериментов. Начать можно с материалов TimeSaver VFX по ComfyUI, а порядок работы с расширениями описан в разборе Custom Nodes.

От события к решению

источники событий
       ↓
нормализация и правила
       ↓
модели поиска и классификации
       ↓
сводка со ссылками на исходные события
       ↓
аналитик или ограниченная автоматизация
       ↓
действие и журнал результата

Языковая модель удобна в середине этой цепочки: она помогает читать и связывать сведения. Если дать ей прямой доступ к блокировке учётных записей или удалению файлов, ошибка становится действием. Поэтому полномочия разделяют по риску.

Три уровня автоматизации

1. Подсказка. AI объясняет событие, но ничего не меняет.
2. Подготовка. AI формирует команду или план, а человек подтверждает запуск.
3. Автоматическое действие. Разрешены только заранее описанные операции с узкой областью и понятным откатом.

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

Пример расследования

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

Аналитик проверяет:

• действительно ли действия принадлежат одному аккаунту;
• известны ли устройство и адрес сети;
• было ли подтверждение многофакторной аутентификации;
• какие письма и файлы затронуты;
• можно ли безопасно остановить сессию.

Модель экономит время на сборке контекста. Решение всё равно опирается на журналы, политику компании и возможный ущерб от блокировки.

Как измерять пользу

Количество найденных «подозрений» само по себе ничего не доказывает. Полезнее смотреть на набор показателей:

• сколько известных инцидентов система пропустила в контрольной проверке;
• сколько ложных тревог дошло до аналитика;
• как быстро команда понимает причину и область инцидента;
• сколько автоматических действий пришлось отменить;
• можно ли восстановить ход решения по журналам;
• как меняется качество на новых типах событий.

Метрики проверяют на данных своей инфраструктуры. Невидимые системе реальные инциденты трудно посчитать полностью, поэтому используют размеченные примеры, учебные атаки и результаты расследований. Демонстрация поставщика не заменяет такой проверки.

С чем часто путают

• AI in Cybersecurity использует AI как инструмент защиты. Cybersecurity for AI защищает модели, данные и агентов.
• SIEM собирает и связывает события. SOAR запускает процессы реагирования. AI может дополнять оба слоя.
• EDR наблюдает за конечными устройствами, NDR — за сетью, а XDR объединяет несколько источников. Название продукта не гарантирует одинаковый набор функций.
• Детектор deepfake оценивает признаки подделки, но не даёт абсолютного доказательства подлинности.

Практичная защита от синтетической социальной инженерии

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

Такой процесс защищает и от deepfake, и от обычного взломанного аккаунта. Он не зависит от того, какой генератор использовал злоумышленник.

Частые ошибки

• Автоматизировать непонятный процесс. Если никто не знает, почему команда блокирует аккаунт, добавление модели не делает это решение обоснованным. Сначала нужен понятный порядок проверки.
• Передавать в промпт лишние секреты. Контекст должен быть не шире конкретной задачи.
• Верить красивой сводке без ссылок на события. У каждого вывода должен быть проверяемый источник.
• Разрешать агенту любые команды. Полезнее короткий список допустимых операций и отдельное подтверждение для опасных действий.
• Оценивать систему только на старых атаках. Проверка должна включать новые сценарии и обычные, но редкие рабочие события.

Частые вопросы

Заменит ли AI команду SOC? Он может снять часть повторяющегося чтения и подготовки отчётов. Расследование, выбор допустимого риска и ответственность за действия остаются задачами команды.

Можно ли доверять автоматической блокировке? Она может быть оправданна для узких, проверенных сценариев с возможностью отмены. Но обратимость не исключает ущерба: ошибочное отключение даже на несколько минут способно остановить работу. Чем выше возможный ущерб от ошибки, тем важнее подтверждение и дополнительный сигнал.

Какой продукт выбрать? Сначала полезно описать свои источники событий, сценарии атак, требования к хранению данных и процесс реагирования. После этого продукты сравнивают на собственных журналах и контрольных инцидентах, а не по числу функций в рекламной таблице.

Определит ли AI письмо, написанное другой моделью? Надёжно определить автора по стилю нельзя. Проверять стоит отправителя, ссылки, вложения, контекст просьбы и последующие действия.

Главное

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