«Машинная скорость» — миф: почему не стоит пытаться бороться с ИИ с помощью ИИ
В 2017 году мне удалось остановить WannaCry — автономного червя-вымогателя, заразившего миллионы систем. В том же году произошло несколько самораспространяющихся кибератак, организованных государственными группировками, а число IoT-червей резко выросло. Спустя несколько лет я участвовал в ликвидации нескольких крупных ботнетов — и все они использовали самораспространяющееся вредоносное ПО.И всё же сегодня поставщики средств кибербезопасности утверждают, что из-за ИИ злоумышленники начинают действовать с «машинной скоростью» и что остановить их может только ИИ. Ни то, ни другое не соответствует действительности.
Пора отказаться от маркетинговой шумихи и сосредоточиться на том, что действительно существует, происходит прямо сейчас и позволяет противостоять даже самым быстрым кибератакам. Ни одно из этих решений не является особенно новым, и абсолютно ни одно из них не требует ИИ.
Автономные и полуавтономные кибератаки — это норма, а не исключение
В 1988 году студент факультета компьютерных наук Корнеллского университета Роберт Таппан Моррис выпустил одну из самых известных вредоносных программ в истории — червя Morris Worm.1 Менее чем за 24 часа он заразил 10% всего Интернета.2 Это стало переломным моментом, продемонстрировавшим всему миру, насколько быстро может распространяться самораспространяющийся код.В 2003 году появился SQL Slammer — вредоносная программа, распространявшаяся настолько быстро, что количество заражённых систем удваивалось каждые 8,5 секунды. Менее чем за 10 минут червь заразил почти все уязвимые системы.3
К моменту ликвидации ботнета в январе 2021 года Emotet заразил 1,6 млн систем, причём значительную долю жертв составляли корпоративные рабочие станции. Ботнет не полагался на уязвимости программного обеспечения для самораспространения. Он превращал заражённые системы в спам-ботов и использовал их собственные почтовые клиенты против владельцев.
Вредоносная программа извлекала почтовый ящик жертвы, список контактов и учётные данные SMTP. Затем эти данные использовались для отправки вредоносных писем от имени жертвы — как её контактам, так и случайным адресам из списков, предоставленных злоумышленниками.
Спам-кампании Emotet были чрезвычайно эффективны. Используя уже существующие отношения доверия между людьми, злоумышленники значительно повышали вероятность того, что жертва откроет письмо с вредоносным вложением или ссылкой.
В более поздних версиях Emotet пошёл ещё дальше: он искал в почтовом ящике жертвы цепочки писем, на которые она ещё не ответила, и отправлял ответ от её имени.5
Самым быстро распространявшимся вымогателем в истории стал WannaCry. По оценкам, из-за активации механизма аварийной остановки он успел зашифровать лишь несколько сотен тысяч систем,6 однако всего червь распространился примерно на 3–16 млн компьютеров.7
WannaCry использовал уязвимость в SMB — наиболее распространённом протоколе сетевого обмена файлами. Благодаря этому он мог полностью автономно распространяться как между компьютерами внутри одной сети, так и из одной сети в другую.
Если поднять веб-сервер без какого-либо содержимого и просто открыть на нём популярные атакуемые порты — например, 22 (SSH), 23 (Telnet), 80 (HTTP), 445 (SMB) и 3389 (RDP), — скорее всего, уже в течение суток вы увидите сотни тысяч автоматизированных попыток взлома.
Это будут самые разные атаки: от активности ботнетов Mirai и перебора учётных данных до сканеров уязвимостей n-day. И, что забавно, вы до сих пор можете увидеть там WannaCry. Механизм аварийной остановки остановил работу программы-вымогателя, но не остановил сам червь, который продолжил бесконечно распространяться.
Небольшое отступление. Если вы когда-нибудь слышали, как CISO рассказывает о миллионах, миллиардах или даже триллионах кибератак, с которыми его организация сталкивается каждый день, обычно речь идёт именно об этом. О фоновом шуме Интернета — остатках автоматизированных атак, которые продолжают собирать самые лёгкие цели.
Люди склонны сильно переоценивать влияние атак с использованием ИИ
Очень немногие специалисты имеют возможность наблюдать за внутренней работой и инфраструктурой злоумышленников. В результате возникает огромное количество предположений о том, как ИИ может помочь им автоматизировать различные задачи, при практически полном отсутствии информации о том, что они уже автоматизировали.Это редкая перспектива. Однако более десяти лет работы аналитиком угроз позволили мне изучить внутреннее устройство инфраструктуры множества группировок. Я даже получал доступ к исходному коду и серверным конфигурациям некоторых крупнейших киберпреступных операций в истории.
Поэтому я не опасаюсь, что злоумышленники внезапно начнут забрасывать Интернет автоматизированными попытками взлома. Они делают это уже несколько десятилетий.
Вместо этого я смотрю на существующие механизмы автоматизации, нахожу их слабые места и задаюсь вопросом: можно ли улучшить их с помощью генеративного ИИ и если да, то каким образом?
Общая картина выглядит гораздо менее мрачно, чем предсказывают многие сторонние наблюдатели. Мы не стоим на пороге киберапокалипсиса. Мы наблюдаем продолжение многолетней тенденции, в рамках которой методы атак год за годом развиваются, совершенствуются и ускоряются.
Думаю, на восприятие ландшафта угроз сильно влияет и нормализация происходящего. Любая атака, в которой используется ИИ, становится новостью. А миллионный человек, получивший фишинговое письмо с момента, когда вы начали читать эту статью, новостью уже не является.
Технологические СМИ и поставщики средств кибербезопасности несколько недель обсуждали PromptLock, названный «первым ИИ-вымогателем». Позже выяснилось, что это исследовательский проект одного из университетов Нью-Йорка и он никогда не использовался ни в одной реальной атаке.
Индустрия кибербезопасности в целом отчаянно стремится заработать на идее кибератак с использованием ИИ. Поставщики буквально наперегонки публикуют материалы обо всём, что хотя бы отдалённо связано с ИИ.
В результате и у широкой публики, и даже у ведущих специалистов по кибербезопасности формируется крайне нереалистичное представление о том, насколько распространены атаки с использованием ИИ на самом деле.
Большинство злоумышленников пока не используют генеративный ИИ
Генеративный ИИ действительно может выполнять многие задачи быстрее человека. Но одновременно это одна из самых медленных форм автоматизации.LLM чрезвычайно медленны по сравнению с нативным кодом и даже с большинством скриптовых языков. За то время, которое понадобится ChatGPT, чтобы ответить на простое «привет», WannaCry мог бы заразить сотни систем.
Большинство злоумышленников также не заинтересованы в передовых технологиях. За стиль им никто дополнительных очков не начисляет. Они выбирают путь наименьшего сопротивления: то, что достаточно хорошо работает, не требует чрезмерных усилий, не стоит дорого и не создаёт проблем с обслуживанием.
Возможно, для многих это покажется неожиданным, но чаще всего ответом оказывается SaaS: просто купить готовый сервис.
Зачем создавать собственные решения на базе ИИ, если кто-то уже разработал гораздо более эффективный продукт без него? ИИ имеет тенденцию стремиться к среднему результату, тогда как высококлассные SaaS-продукты позволяют приблизиться к верхней границе возможного.
На модель Everything-as-a-Service перешла не только легальная экономика — криминальный подпольный рынок последовал за ней. Сегодня можно купить malware-as-a-service, crypter-as-a-service, spam-as-a-service, phishing-as-a-service, polymorphism-as-a-service, developers-as-a-service, infostealers-as-a-service и corporate-network-access-as-a-service.
И практически всё это обходится дешевле, чем самостоятельная разработка и поддержка решений на базе ИИ, а зачастую ещё и работает значительно эффективнее.
«Машинная скорость» относится лишь к небольшой части кибератак
Несмотря на то что большинство атак автоматизировано, существует значительная часть операций, которые либо не автоматизированы, либо автоматизированы лишь частично.При этом именно они часто оказываются наиболее разрушительными для организаций-жертв, если не учитывать такие редкие события, как WannaCry, NotPetya, BadRabbit и им подобные.
Основные категории здесь — государственный кибершпионаж и целевые атаки программ-вымогателей на корпоративные сети.
Я сосредоточусь на атаках вымогателей, начинающихся с конечных устройств. Не потому, что описанное здесь неприменимо к атакам государственных группировок — применимо, — а потому, что деятельность операторов вымогателей лучше документирована и изучена.
Обычно оператор вымогателя компрометирует одну конечную точку или одну учётную запись внутри организации. Это обычно называют первичным доступом (initial access) или первоначальным плацдармом (initial foothold).
После этого цель злоумышленника — получить привилегированный доступ.
Получение привилегий, например учётных данных администратора домена, либо компрометация контроллера домена позволяет нанести значительно больший ущерб. Вместо одной рабочей станции злоумышленник может развернуть вымогатель на всей сети. Чем больше систем и данных удаётся взять под контроль, тем больший выкуп можно потребовать.
Первичный доступ часто становится результатом автоматизированных атак. Однако повышение привилегий и горизонтальное перемещение по сети в основном выполняются операторами вручную.
Именно это обычно имеют в виду поставщики средств кибербезопасности, когда говорят о том, что «злоумышленники начинают действовать с машинной скоростью»: потенциальную возможность автоматизировать несколько этапов кибератаки, которые сейчас выполняются вручную, — подразумевая, что генеративный ИИ позволит это сделать.
Как заражение одной конечной точки превращается в захват всей сети
Один из способов, которым злоумышленник может перейти от первоначального доступа на одной рабочей станции к компрометации всей сети, — поиск сохранённых привилегированных учётных данных.Один из примеров — дамп памяти lsass.exe (LSASS). Когда пользователь удалённо входит в систему определённым способом, хеш его пароля сохраняется в памяти lsass.exe на время сеанса входа. В некоторых случаях он может оставаться там до перезагрузки системы, если сеанс не был корректно завершён.
Получив хеш пароля из LSASS, злоумышленник может использовать его в атаке Pass-the-Hash. Поскольку многие системы используют этот хеш для проверки пользователя, сам хеш можно использовать вместо пароля. Восстанавливать исходный пароль для этого не требуется, хотя некоторые современные атаки могут предполагать его подбор.
Сохраняя плацдарм на одной системе внутри сети, злоумышленник может перехватывать хеши паролей учётных записей, которые удалённо подключаются к этой системе.
Распространённая проблема — сотрудники ИТ-отделов, которые используют привилегированные учётные записи для удалённого подключения к пользовательским рабочим станциям при оказании технической поддержки.
Многие сетевые инфраструктуры буквально переполнены чрезмерно привилегированными учётными записями, которые используются на самых разных системах, сервисными учётными записями с паролями, сохранёнными в реестре или конфигурационных файлах, локальными паролями администратора, повторно используемыми на всех компьютерах, и множеством других проблем с гигиеной учётных данных.
Всё это значительно упрощает работу операторов вымогателей.
Этот пример также станет основой для защитной части статьи.
Злоумышленники действительно становятся быстрее, но доказательств связи с генеративным ИИ мало
Типовые пути от первоначального доступа к компрометации всей сети не слишком сильно различаются от одной инфраструктуры к другой.Вероятно, злоумышленник мог бы автоматизировать весь процесс с помощью чего-нибудь настолько простого, как Python-скрипт. Для большинства сетей дерево принятия решений при повышении привилегий не настолько сложное, чтобы для него требовался какой-либо ИИ.
Я считаю, что большинство злоумышленников просто не занимались автоматизацией подобных атак, выполняемых вручную, потому что им это не было необходимо. Они и так успешно шифруют сети с достаточно высокой вероятностью успеха, поэтому инвестиции времени и денег в разработку автоматизированных инструментов не выглядят оправданными.
Мне показался показательным график из 2026 Global Threat Report компании CrowdStrike.9 На нём показано среднее время прорыва (breakout time) — среднее время, необходимое злоумышленнику для перехода от первоначального плацдарма к другой конечной точке или получения более высоких привилегий.
График CrowdStrike со средним временем прорыва в период с 2021 по 2025 год.
Этот график стал основой моего доклада на Zero Trust World 2026 под названием Rethinking Cyber Defense in an Era of High Velocity Attacks. В докладе я затронул многие из тех же вопросов, о которых говорю в этой статье.
Хотя график CrowdStrike был опубликован в пресс-релизе, призванном подчеркнуть угрозу атак с использованием ИИ, на самом деле он содержит два аргумента против их значимости.
Во-первых, время прорыва стабильно сокращается уже много лет — задолго до появления ИИ.
Первой массовой генеративной моделью ИИ стал ChatGPT, запущенный 30 ноября 2022 года. Хотя GPT-3 получил ограниченный публичный доступ ещё в 2020 году, он распространялся по спискам ожидания и был доступен только проверенным пользователям.
Можно утверждать, что продолжение этой тенденции с 2023 года связано с ИИ, как, по-видимому, подразумевает CrowdStrike. Однако убедительных доказательств этого не представлено.
В отчёте упоминается несколько злоумышленников, использующих ИИ, и заявляется об увеличении числа атак со стороны злоумышленников, применяющих ИИ, на 89%. Однако это само по себе не доказывает, что широкое распространение ИИ стало причиной ускорения времени прорыва.
Во-вторых, независимо от причин сокращения времени прорыва, эти данные дают нам конкретные показатели, с которыми можно сравнивать скорость реагирования средств защиты.
В 2025 году среднее время прорыва составляло 29 минут и, вероятно, с тех пор продолжило сокращаться.
Если предположить, что предупреждение появляется сразу после проникновения злоумышленника в сеть, то время реагирования свыше 29 минут уже недостаточно против среднестатистического атакующего.
Некоторые атаки могут проходить значительно быстрее. Самый короткий зафиксированный CrowdStrike случай занял 27 секунд: переход к извлечению данных произошёл уже через четыре минуты.
Допустим, ради аргумента, что утверждения CrowdStrike об атаках с использованием ИИ верны, ИИ действительно ускоряет сокращение времени прорыва и эта тенденция продолжится.
Основной аргумент этой статьи всё равно остаётся в силе — независимо от того, что именно является причиной сокращения времени прорыва.
Злоумышленники успешно атаковали организации ещё до появления ИИ, успешно делают это сейчас и будут продолжать добиваться успеха по мере сокращения времени прорыва, пока реактивные средства защиты остаются основной линией обороны.
Даже лучшие наступательные модели ИИ часто не справлялись с незащищённой сетью
К сожалению, мне не удалось найти надёжных исследований, позволяющих сравнить время прорыва при атаках с использованием ИИ и при атаках, выполняемых людьми.Были опубликованы несколько маркетинговых материалов ИИ-компаний, но в них отсутствовало описание методологии. Ничего более конкретного я не нашёл.
Независимое исследование AI Security Institute (AISI)10 подробно описывало результаты Mythos Preview на имитированной корпоративной сети.
Исследование показало, что Mythos удалось полностью скомпрометировать сеть только в 3 из 10 попыток. При этом временные показатели не приводились.
Особенно примечательно, что сеть AISI была намеренно уязвимой и незащищённой. На ней не использовались средства защиты конечных точек, сетевые средства безопасности, а активного защитника вообще не было.
Несмотря на отсутствие какой-либо реальной защиты, Mythos потерпел неудачу в 70% случаев, имея бюджет в 100 млн токенов на одну попытку.
В пересчёте на реальные расходы это составляет от $2500 до $12 500 за попытку — точная сумма зависит от соотношения входных и выходных токенов, поскольку выходные токены стоят дороже. Таким образом, успешная компрометация обходилась примерно в $8000–42 000.
AISI также отмечал, что в среднем Mythos выполнял 22 из 32 шагов. При увеличении бюджета с 10 до 100 млн токенов вероятность успеха продолжала расти и не достигла плато, что указывает на возможность дальнейшего повышения показателей при увеличении бюджета.
Но при такой стоимости успешной атаки злоумышленник вполне мог бы нанять нескольких операторов-людей.
Mythos Preview широко считался одной из наиболее продвинутых моделей для наступательных киберопераций. Поэтому её 70-процентная неудача на специально уязвимой и полностью незащищённой сети должна была серьёзно охладить энтузиазм вокруг идеи о том, что злоумышленнику достаточно взять LLM и мгновенно усилить свои возможности.
Тем не менее этот нарратив продолжил существовать.
Примечательно и то, что выводы самого исследования были гораздо более приземлёнными. Никаких AI SOC и магических ИИ-продуктов — только базовые меры защиты:
Проблема не в том, что SOC работает слишком медленно, а в том, что его используют как временную замену полноценной защите
SOC должен быть последней линией обороны организации. Когда всё остальное уже не сработало и злоумышленник проник в сеть, SOC должен вступать в действие.Однако на практике его часто используют совсем не так. SOC нередко становится заменой качественной базовой защите.
В худших случаях организации просто приобретают SOC или SOC-as-a-Service, чтобы поставить соответствующую галочку в документах для киберстрахования и гарантировать страховую выплату после компрометации сети.
Такие компании, выполняющие лишь минимальные требования соответствия, могут при этом создавать значительную нагрузку на службы безопасности бесконечным потоком уведомлений и постоянными попытками проникновения.
Проактивное укрепление инфраструктуры ограничивает возможности злоумышленника. Однако его часто считают затратным по времени, дорогим и мешающим бизнес-процессам. В результате руководители начинают искать альтернативы.
Один из распространённых подходов — просто приобрести множество средств безопасности, включить все возможные уведомления, а затем направить их в SOC, завалив команду потоком информационного шума.
В результате безопасность организации становится полностью реактивной и начинает зависеть от эффективности SOC.
Так мы и пришли к концепции Agentic AI SOC.
Современные средства защиты пока не справляются с атаками людей
Средства Endpoint Detection and Response (EDR) обладают широкими возможностями обнаружения способов извлечения учётных данных злоумышленниками. Несмотря на это, атаки программ-вымогателей по-прежнему часто оказываются успешными даже в защищённых сетях.Многие администраторы разворачивают средства защиты, оставляя только правила, заданные по умолчанию, и отказываются от более полного набора механизмов обнаружения, способного выявлять даже относительно простые вторжения.
Но атаки вымогателей удаются даже тогда, когда необходимые правила обнаружения включены.
Я бы сказал, что наиболее распространённая проблема возникает в ситуации, когда EDR действительно обнаруживает подозрительную активность и отправляет предупреждение, но организация не успевает отреагировать до того, как происходит серьёзный инцидент безопасности.
Другой распространённый фактор — противоположная проблема: чрезмерно настроенные механизмы обнаружения. Стратегия «давайте просто будем сообщать обо всём» приводит к тому, что SOC тонет в уведомлениях с низкой точностью и ложными срабатываниями.
Возникают очереди необработанных предупреждений, а злоумышленник получает более чем достаточно времени для достижения своей цели.
Если злоумышленник успешно похитил ценные учётные данные, их необходимо немедленно заблокировать и заменить. Однако это часто откладывается из-за возможных нарушений работы пользователей или сервисов, использующих эти учётные данные.
Пока украденные данные остаются действительными, злоумышленник может использовать их для перемещения между конечными точками, значительно снижая вероятность обнаружения и блокирования.
SOC может увидеть предупреждение и переустановить систему, на которой оно возникло, не понимая, что злоумышленник уже переместился на другой компьютер и, возможно, успел получить там новые учётные данные.
Даже если злоумышленника удалось выгнать из сети, незаменённые учётные данные можно использовать для повторного проникновения, ускорения дальнейшего повышения привилегий — или и того и другого одновременно.
В результате SOC часто оказывается втянутым в игру в кошки-мышки: команда пытается преследовать злоумышленника по сети, одновременно разбираясь с потоком предупреждений.
Хотя успешные компрометации часто объясняют плохой работой SOC, это почти никогда не является их основной причиной.
Почему время реагирования SOC — лишь небольшая часть гораздо более серьёзной проблемы
Активность, которая вызывает предупреждения EDR при извлечении учётных данных, почти всегда явно вредоносна. Это не тот тип уведомлений, который случайно возникает во время обычной работы пользователя.Но организации обращаются с такими событиями именно так. Предупреждение поступает в SOC, его анализируют, чтобы исключить ложное срабатывание, а затем инцидент переводится в критическую категорию.
Проблема в том, что инцидент не заканчивается на SOC.
При активном взломе с горизонтальным перемещением и повышением привилегий требуется немедленное устранение последствий: злоумышленника необходимо удалить из сети и перекрыть все возможные пути повторного проникновения.
Однако во многих организациях SOC не контролирует устранение последствий — по крайней мере напрямую. Для принятия решения о дальнейших действиях подключаются другие подразделения.
Поэтому время реакции SOC — лишь небольшая часть общей картины.
Даже если SOC способен сформировать предупреждение за несколько секунд, организации всё равно необходимо успеть выполнить достаточный объём действий по устранению последствий и локализации атаки.
Цепочка
предупреждение → анализ предупреждения → регистрация инцидента → рассмотрение инцидента → устранение последствий
может занимать очень много времени — вплоть до нескольких дней.
Среднестатистическому оператору вымогателя более чем достаточно этого времени, чтобы опередить защиту.
Среднее время прорыва в 29 минут не означает, что у SOC есть 29 минут на анализ предупреждения и регистрацию инцидента.
Это означает, что у всей организации есть меньше 29 минут от первого предупреждения до локализации атаки.
Во многих случаях шифрование происходит именно в промежутке между объявлением SOC критического инцидента и фактическим началом организацией работ по устранению последствий. Это проблема, которую большинство поставщиков решений на базе ИИ просто игнорирует.
AI SOC — это пластырь поверх уже существующего пластыря
AI SOC продаётся как универсальное решение против атак «машинной скорости», но в лучшем случае это всего лишь пластырь.Первая проблема заключается в том, что большинство организаций используют SOC как замену эффективной проактивной защите.
Вторая — генеративный ИИ часто жертвует точностью ради скорости.
Вместо устранения фундаментальных проблем компании продолжают наслаивать временные решения одно на другое, накапливая при этом огромный объём технического долга.
Важно также помнить, что SOC и индустрия кибербезопасности в целом уже более десяти лет используют алгоритмы машинного обучения (ML) для автоматизации различных задач. Генеративный ИИ является подмножеством ML и также активно внедряется в средства кибербезопасности.
Вся концепция «AI SOC» основана на ложной дихотомии, созданной маркетинговыми отделами компаний, называющих себя «AI-native».
Они пытаются отстроиться от существующих поставщиков, создавая впечатление, будто только они используют автоматизацию.
Однако мне неизвестен ни один поставщик SOC, который полностью работает вручную или вообще не использует генеративный ИИ в той или иной форме.
Для целей этой статьи под AI SOC я подразумеваю поставщиков SOC, которые используют ИИ-агентов на базе генеративного ИИ вместо аналитиков-людей либо настолько сильно зависят от генеративного ИИ, что не способны функционировать без него.
Более быстрое рассмотрение предупреждений не меняет фундаментальной математики
Основной аргумент в пользу AI SOC звучит так: злоумышленники становятся быстрее благодаря ИИ, поэтому защитникам нужен ИИ, чтобы успевать за ними.Я с этим утверждением не согласен. Атаки и раньше были автоматизированы, а по моим наблюдениям, злоумышленники пока не начали массово использовать ИИ в атаках, выполняемых вручную.
Но даже если это утверждение неверно, те, кто его продвигает, всё равно получают от него выгоду.
Любое повышение скорости работы SOC должно снижать вероятность успеха злоумышленника — независимо от того, автоматизирована его атака или нет, — при условии сохранения точности.
Хотя я не считаю генеративный ИИ лучшим инструментом для этой задачи, само утверждение о пользе сокращения времени реакции остаётся справедливым независимо от используемого решения.
Ранее я упоминал, что между объявлением SOC критического инцидента и завершением устранения последствий часто проходит значительное время.
Многие решения AI SOC вообще не решают проблему устранения последствий.
Если на это требуется 30 минут, а среднее время прорыва составляет 29 минут, человек-злоумышленник всё равно сможет опередить AI SOC даже при времени реакции последнего в несколько миллисекунд.
И, конечно, генеративный ИИ на самом деле не настолько быстр.
Скорость современных передовых LLM составляет примерно 30–400 токенов в секунду. Чтобы обработать эту статью как набор данных об атаке, такой модели потребовалось бы от 20 секунд до 4,5 минут.
В связке с человеком генеративный ИИ действительно способен ускорить анализ. Но даже полностью автоматизированные решения на базе ИИ не работают мгновенно, а многие из них к тому же весьма ненадёжны.
Но существует куда более серьёзная проблема.
Злоумышленники вовсе не стремятся массово внедрять ИИ.
Несмотря на заявления маркетинговых отделов, автоматизированные атаки с использованием ИИ пока крайне редки. Поэтому ещё даже не установлено, сможет ли реактивное решение на базе ИИ реально опередить злоумышленника, который сам использует ИИ.
До тех пор пока агентные системы ИИ не получат широкого распространения среди злоумышленников, вся эта концепция остаётся гипотезой.
Пока SOC, работающие с людьми, регулярно не справляются с атаками, выполняемыми людьми, я не уверен, что расчёты в пользу идеи «AI SOC остановит AI-злоумышленника» вообще сходятся.
SOC — критически важная функция безопасности организации. Однако использовать его как замену проактивным мерам защиты — путь к серьёзным проблемам.
Текущая волна интереса к ИИ лишь усугубляет ситуацию. Она продаёт руководителям ложное обещание, будто можно и дальше отказываться от проактивной защиты и просто реагировать на атаки ИИ с помощью ИИ.
Нельзя. В конечном итоге такая стратегия приведёт к поражению.
Защитным ИИ-агентам приходится решать значительно более сложную задачу, чем наступательным
Защитные ИИ-системы должны обрабатывать на порядки больше сигналов, чем атакующие.ИИ злоумышленника интересует только одно: как можно быстрее достичь цели. Результат при этом в основном бинарен — этап атаки либо завершён успешно, либо нет.
Защитная система находится в гораздо более сложном положении. Ей необходимо анализировать предупреждения, сопоставлять данные из разных источников, определять местоположение злоумышленника в сети, выяснять, какие данные уже были получены, выбирать меры защиты и устранения последствий и проверять, удалось ли локализовать атаку.
Кроме того, защитной стороне приходится учитывать ложные срабатывания, доступность сервисов, законодательные требования и соответствие нормативам.
Учитывая, что практически каждая ведущая лаборатория сейчас параллельно занимается разработкой моделей, способных находить уязвимости нулевого дня, я подозреваю, что наступательные возможности ИИ сейчас просто развиваются быстрее.
Если ИИ-лаборатории начнут уделять больше внимания защитным задачам, за пределами управления уязвимостями ситуация может измениться.
Однако этого, скорее всего, будет недостаточно, чтобы компенсировать разницу в объёме данных и сигналов, с которыми приходится работать атакующей и защищающейся сторонам.
Честно говоря, сама идея «бороться с огнём огнём» в лучшем случае сомнительна.
Она не доказана, а её главный рекламный аргумент одновременно является её слабостью. Реактивная защита на базе ИИ обещает результаты, которые вовсе не гарантированы, и выяснить это мы сможем только тогда, когда будет слишком поздно.
Злоумышленники пока не внедряют ИИ в массовом масштабе. Создавая видимость обратного, мы рискуем преждевременно объявить победу ещё до того, как состоялось настоящее противостояние.
Если злоумышленники действительно начнут массово использовать сложные ИИ-фреймворки для атак, я бы не стал делать никаких предположений о том, насколько эффективными окажутся AI SOC.
В конечном счёте настоящее решение не менялось годами
Как бы ни развивалась кибербезопасность, ответ остаётся прежним: делайте базовые вещи — и делайте их хорошо.После того как базовые меры обеспечены, можно переходить к более продвинутой проактивной защите.
Начинать с беспокойства об эксплойтах нулевого дня и злоумышленниках, использующих ИИ, не отвечает интересам организации.
ИИ — не магия. Он просто автоматизирует существующие и хорошо изученные методы атак.
Способность ИИ-моделей находить уязвимости нулевого дня также во многом является производной от этого. Они ищут варианты небезопасных шаблонов кода, которые тысячи исследователей уязвимостей изучают уже около 50 лет.
Даже если злоумышленник использует уязвимость нулевого дня, в конечном счёте он всё равно оказывается на инфраструктуре, которую контролируете вы.
Чтобы достичь своей цели, ему придётся совершать определённые действия — а эти действия можно обнаруживать.
Даже если он использует уязвимость нулевого дня для проникновения на конечную точку, а затем пытается применить ещё одну для достижения конечной цели, само выполнение этой цепочки можно обнаружить.
Эксплойты нулевого дня и злоумышленники с ИИ — это отвлекающий фактор.
Они отвлекают внимание от тех самых защитных механизмов, которые способны защитить вас от эксплойтов нулевого дня, атак с использованием ИИ и вообще от всего остального, что может оказаться на вашем пути.
Даже реактивная защита не требует ИИ, чтобы работать эффективно
Многие категории предупреждений системы безопасности, например связанные с извлечением учётных данных, характеризуются низким уровнем ложных срабатываний.Для большинства таких событий можно и нужно настроить немедленную изоляцию конечной точки и блокировку учётных данных.
Конечное устройство следует изолировать не только от остальной сети, но и от Интернета.
Для этого не требуются генеративный ИИ или сложные ML-модели. Такая возможность по умолчанию присутствует практически в каждом EDR.
Существует множество типов предупреждений, для которых оправдан подход «сначала блокировать, потом разбираться».
Вы всегда сможете вернуть конечную точку в сеть и разблокировать учётную запись пользователя. Но вы не сможете «разрасшифровать» сеть после атаки вымогателя.
Исторически организации предпочитали доступность и непрерывность бизнеса безопасности. По мере того как атаки и злоумышленники становятся быстрее, такой подход становится всё менее жизнеспособным.
Если злоумышленник способен перейти от первоначального доступа к шифрованию всей сети за несколько минут, стоит спросить: что конкретно успеет сделать отдельный сотрудник за эти несколько минут, чтобы компенсировать стоимость инцидента?
Возможно, киберстрахование действительно покроет часть ущерба. Но оно редко покрывает реальную стоимость серьёзной кибератаки.
И всё это будет повторяться снова и снова.
ИИ здесь ничего не меняет: атаки становятся быстрее и происходят чаще.
Ставить доступность бизнес-процессов значительно выше безопасности — стратегия, которая в долгосрочной перспективе перестанет работать.
Надо признать, что маркетинговый шум вокруг «машинной скорости» отлично скрывает уже существующие мгновенные средства автоматизации безопасности, которые давно проверены на практике и широко доступны.
Но в долгосрочной перспективе это никому не помогает.
Представляя кибербезопасность исключительно как реактивную дисциплину и продавая медленные автоматизированные решения на базе LLM в качестве универсального средства защиты, поставщики рискуют ослабить кибербезопасность в целом.
Полностью проактивные меры — отличная первая линия обороны
Уже существуют проверенные временем способы предотвращать атаки ещё до их начала.В качестве примера я выбрал извлечение учётных данных.
Проактивные средства защиты будут неизмеримо быстрее самого быстрого предупреждения EDR и, следовательно, намного быстрее любого решения на базе генеративного ИИ.
Такие функции, как Credential Guard,11 защищают учётные данные и другие секреты, которые ранее хранились lsass.exe, перемещая их в защищённую виртуальную область.
Система использует виртуализацию для создания отдельного процесса, работающего за пределами операционной системы и хранящего учётные данные вне досягаемости злоумышленника.
При этом EDR по-прежнему может обнаружить попытку атаки и автоматически изолировать систему, но злоумышленник не получит ничего полезного.
Никакой ИИ не сможет опередить ситуацию, в которой необходимые учётные данные просто недоступны.
Другой эффективный проактивный механизм — LAPS (Windows Local Administrator Password Solution).12 Он устраняет серьёзный и часто игнорируемый риск: массовое развёртывание систем с одинаковым паролем локального администратора.
Если для локальных учётных записей администратора разрешён удалённый вход — а это характерно для многих схем автоматического развёртывания, — злоумышленник может извлечь хеш пароля и использовать его для входа на любой компьютер в сети, где используется тот же хеш.
Это позволяет перемещаться между компьютерами до тех пор, пока злоумышленник не доберётся до привилегированной рабочей станции или сервера.
Однако даже такие технологии, как LAPS, не решают ещё одну проблему: большинству конечных устройств внутри сети вообще редко требуется напрямую взаимодействовать друг с другом.
Здесь в игру вступают сегментация сети и правила межсетевого экранирования.
Остальное сводится к базовой гигиене безопасности.
Учётным записям следует предоставлять только те привилегии, которые им действительно необходимы.
Учётные записи администраторов домена нельзя использовать для удалённого входа на пользовательские рабочие станции или другие системы, доступные злоумышленнику.
Все учётные данные должны поддерживать автоматическую смену по команде.
И это касается не только горизонтального перемещения.
Проактивные средства защиты существуют практически для каждого возможного вектора атаки. Вместо попыток реагировать на автоматизированные атаки организациям следует заранее устранять базовые уязвимости своей поверхности атаки.
Чем больше атак удаётся остановить на ранних этапах с помощью проактивной защиты и автоматических политик реагирования, тем больше времени остаётся у SOC для работы с теми немногими злоумышленниками, которым всё же удалось пройти через защиту.
Что организации могут сделать для подготовки
Независимо от того, насколько распространены или, скорее, пока не распространены атаки с использованием Agentic AI, лучшее, что организация может сделать для подготовки, — укрепить базовые системы, политики и процедуры.Скорее всего, вам придётся иметь дело не с принципиально новыми кибератаками, а с более быстрыми версиями уже известных.
Сокращение поверхности атаки уменьшает последствия любых атак — ручных, автоматизированных, использующих уязвимости нулевого дня или любую их комбинацию.
Одна из лучших практик для команд безопасности — проводить сценарии assumed breach, исходя из предположения, что злоумышленник уже проник в сеть.
Неважно, произошло это через фишинг, вредоносное ПО или уязвимость нулевого дня. Реальность такова, что рано или поздно злоумышленник, вероятно, окажется внутри вашей сети.
Именно тогда начинает работать преимущество защищающейся стороны.
Защита периметра важна, но лучшей линией обороны всегда будут механизмы, работающие внутри сети.
Цель пентестера может заключаться в проникновении в сеть. Злоумышленнику же обычно нужно что-то конкретное: закрепиться, украсть данные, зашифровать сеть или уничтожить информацию.
Для достижения любой из этих целей требуется значительно больше действий, чем просто проникновение в сеть.
Предоставьте red team доступ к рабочей станции, внешнему серверу или устройству, учётным данным сотрудников и другим точкам, на которые потенциально может попасть злоумышленник.
Затем отрабатывайте предотвращение наиболее распространённых целей атакующих.
При этом необходимо внимательно следить за тем, чтобы red team имитировала реальные угрозы.
Нередко специалисты по red team пытаются добиться результата любыми доступными способами. В итоге организация оказывается хорошо подготовлена к маловероятным и нереалистичным атакам, в то время как реальные злоумышленники продолжают проходить через защиту.
Цель должна заключаться в том, чтобы атаки останавливались проактивными механизмами защиты или автоматизированными правилами обнаружения, а не только SOC.
SOC выполняет критически важную функцию безопасности, но он не должен быть единственной линией обороны. Он должен быть последней линией обороны.
Если проактивная защита реализована правильно, она способна перекрыть практически все пути, которыми воспользуется злоумышленник.
В этот момент уже не так важно, насколько быстро он действует: противостояние перестаёт быть гонкой между атакующим и реактивными средствами защиты.
Именно здесь большинство злоумышленников просто прекращают попытку и переходят к следующей цели.
В заключение
Атаки продолжают становиться быстрее и происходить чаще — независимо от ИИ.Угроза того, что автономные атаки «машинной скорости» внезапно начнут бесконтрольно распространяться по Интернету, — не более чем маркетинговый нарратив.
Он строится на предположении, что люди не понимают современный и исторический ландшафт угроз.
В кибербезопасности особенно трудно отделить действительно полезные рекомендации от маркетингового шума.
Мало какие публикации, подготовленные внутри компаний — поставщиков средств кибербезопасности, — доходят до читателя, не пройдя через маркетинговый отдел.
В результате даже вполне качественные материалы по анализу угроз могут становиться носителями слабых маркетинговых утверждений, не подтверждённых доказательствами и подрывающих доверие к самому исследованию.
Я уже сбился со счёта, сколько раз слышал что-нибудь вроде:
После этого я связываюсь с исследователем, написавшим исходный материал, и тот, тяжело вздохнув, объясняет, что именно маркетинговый отдел сделал с его статьёй — и что с её итоговыми выводами он вообще не согласен.
Если и когда масштабные атаки с использованием ИИ действительно начнутся, можете быть уверены: я буду одним из первых, кто поднимет тревогу.
Но прямо сейчас я вижу огромное количество ИИ-мусора, лишь изредка прерываемого более-менее удачной, но довольно вялой попыткой провести кибератаку с использованием ИИ.
Лучшее, что можно сделать сейчас, — игнорировать шум, исходящий из ИИ-лабораторий и маркетинговых отделов, и сосредоточиться на архитектуре secure by design.
Последнее, что организациям следует делать, — возвращаться к исключительно реактивной модели безопасности.
Делайте базовые вещи. И делайте их хорошо.
Источник