КИБЕРБЕЗОПАСНОСТЬ

ИИ удешевил киберобман: защите не хватает скорости проверки

59% SOC-аналитиков жалуются на избыток алертов: ИИ ускорил киберобман, а бизнесу теперь нужно масштабировать проверку, а не только детектирование.

✍️ Редакция iTech News | 16.06.2026 | ⏱ 4 мин | Источник: VentureBeat
🔒

ИИ резко удешевил и ускорил киберобман с ИИ: злоумышленник может сгенерировать тысячи правдоподобных фишинговых писем, фальшивых личностей и сценариев социальной инженерии быстрее, чем служба безопасности согласует одно изменение в инфраструктуре. Для русскоязычных ИТ-команд это неприятная, но полезная новость: в 2025 году узкое место в защите уже не только детектирование, а способность быстро подтвердить, что именно произошло и каким данным вообще можно верить.

Об этом сообщает VentureBeat со ссылкой на спонсорскую колонку Splunk. Главный тезис там сформулирован без лишней поэзии: в эпоху ИИ оборона упирается в данные раньше, чем в модели обнаружения. Если логи лежат в пяти системах, хранятся разное время, вытаскиваются через три команды и при этом лишены бизнес-контекста, никакой умный помощник не превращает хаос в истину. Он просто начинает ошибаться быстрее.

Авторы разбирают типовой сценарий: подозрительный вход в систему с аккаунта подрядчика. Сам по себе это просто еще одна аномалия авторизации, которых у SOC и так достаточно. Чтобы понять, инцидент это или шум, нужны история идентичности, активность на эндпоинте, облачные журналы доступа, тикеты, сведения о владельце актива, изменения конфигурации, сетевая телеметрия и бизнес-контекст. Если все это разнесено по разным инструментам и срокам хранения, команда не расследует инцидент, а торгуется с собственной инфраструктурой данных. Формулировка злая, но слишком узнаваемая, чтобы спорить.

На этом фоне интересен сдвиг акцента. Последние пару лет разговор про ИИ в кибербезопасности обычно сводился к тому, насколько хорошо модель находит аномалии, пишет корреляционные правила или сортирует алерты. VentureBeat пересказывает другую мысль: детектирование важно, но оно не спасает, если следом нельзя быстро собрать доказательную цепочку. Защитнику нужно не просто увидеть странное событие, а ответить на довольно приземленные вопросы: что случилось, когда именно, какой идентификатор был задействован, какие активы затронуты, что изменилось и какой бизнес-процесс мог попасть под риск. Без этого автоматизация превращается в конвейер сомнительных решений.

Отсюда и более жесткое требование к платформам безопасности. Старый подход, при котором SIEM, озеро данных или журналирование считались в основном хранилищем для будущего поиска, больше не тянет. В статье это называют defensive control plane, то есть управляющим слоем, который связывает факты, смысл и допустимые действия. Идея в том, что система должна не только хранить свидетельства, но и делать их пригодными для решений, которые потом можно объяснить аудитору, руководителю и собственному юристу. Особенно если часть действий будет выполнять агент: обогащать алерты, открывать кейсы, запускать workflow, изолировать активы или менять политики.

Практически это сводится к четырем задачам. Первая: сохранять доказательства, причем не только логи, но и метрики, трейсы, события, записи об идентичностях, изменениях конфигурации, тикетах и состоянии активов. Вторая: доставать данные там, где они уже живут, а не мечтать, что все когда-нибудь аккуратно переедет в один идеальный контур. Третья: добавлять бизнес-контекст, чтобы аномалия на хосте X превращалась в понятное для бизнеса сообщение вроде «кто-то прощупывает систему, которая обслуживает платежи ключевых клиентов». Четвертая: управлять действием, то есть понимать, на каких данных агент принял решение, какой политике следовал, не вышел ли за пределы полномочий и можно ли потом восстановить ход этой логики.

Здесь же появляется и самая приземленная цифра во всей истории. По данным отчета Splunk State of Security 2025, 59% аналитиков SOC жалуются на слишком большое число алертов, 55% — на избыток ложных срабатываний, 46% — на нехватку контекста в оповещениях. Это полезное уточнение: проблема не в том, что у команд мало данных. Данных как раз слишком много. Не хватает связности, доступности и доверия к ним в момент, когда решение нужно принимать сейчас, а не после трех созвонов и двух выгрузок в CSV.

Для разработчиков, платформенных команд и ИТ-руководителей из этого следует довольно неприятный вывод. Киберобман с ИИ ломает не только защиту периметра, но и привычную организационную модель, где SecOps, ITOps и NetOps живут каждый в своем отсеке и встречаются в лучшем случае на разборе инцидента. Если ИИ-ассистенты и агенты действительно становятся рабочим инструментом SOC, то архитектура данных внезапно превращается из скучной внутренней темы в полноценный элемент защиты. Важны не только правила детекта, но и сроки хранения телеметрии, права доступа к журналам, связь активов с владельцами и способность быстро подтянуть деловой контекст. Иначе компания получает дорогую автоматику, которая уверенно ускоряет неопределенность.

Не случайно Splunk продвигает здесь подход data fabric как слой над источниками SecOps, ITOps и NetOps, а не как очередной призыв все централизовать любой ценой. Это, конечно, еще и продуктовый заход, а материал у VentureBeat прямо помечен как спонсорский. Но сама постановка проблемы выглядит трезво: атакующие будут и дальше удешевлять обман, персонализировать его и масштабировать через ИИ. Значит, устойчивое преимущество обороны смещается в другую сторону — к скорости верификации, качеству доказательств и способности связать данные, решение и действие в одну проверяемую цепочку. Вопрос уже не в том, сможет ли бизнес внедрить ИИ в SOC. Вопрос в том, успеет ли он навести порядок в данных раньше, чем следующий правдоподобный фейк пройдет у него как обычный рабочий процесс.

Поделиться: Telegram X LinkedIn