Привет, Хабр! Машинное обучение сейчас повсюду: автогенерация кода, умные помощники, анализ аномалий. Разработчики активно внедряют ML, радуясь новым возможностям — но злоумышленники тоже не дремлют. Они учатся обманывать и «отравлять» модели, превращая умные системы из помощников в уязвимое звено. Поговорим, как ML упрощает жизнь разработчиков и почему даже самая продвинутая нейросеть может превратиться в «дуршлаг».

Меня зовут Павел Попов, я руководитель группы инфраструктурной безопасности в Positive Technologies.

Расскажу, как сами применяем ИИ и каких результатов нам удалось достичь с внедрением ML-моделей в MaxPatrol VM. А также попробуем ответить на вопрос, заменит ли ИИ разработчиков и есть ли вероятность, что мы все останемся без работы. Если вам тоже интересно, как технологии меняют ИБ-ландшафт и какие решения уже работают сегодня — добро пожаловать.

Вы узнаете:

• Как разработчики используют ML и можно ли от него отказаться

• Какие уязвимости свойственны LLM-моделям

• Как изменились трендовые уязвимости в 2024 году и что нас ждет в будущем

• Как патчить уязвимости так, чтобы ничего не сломалось

• Куда будет двигаться рынок управления уязвимостями и ML-технологий

Зачем нам машинное обучение в разработке

Кто бы мог подумать еще пару лет назад, что нейросети станут таким же обыденным инструментом разработчика, как, скажем, Git или Stack Overflow? Сегодня машинное обучение (ML) проникло во все сферы разработки: от умных ассистентов в IDE до систем кибербезопасности, обещающих сами находить взломщиков. Мы восхищаемся тем, как ML упрощает нам жизнь, но при этом рискуем упустить из виду одно «но»: там, где разработчик видит магию, злоумышленник видит новую поверхность для атак.

Сейчас вокруг ИИ — хайп, и термины вроде ИИ, ML и LLM часто летают в воздухе как будто это одно и то же. Давайте разберемся:

ИИ — это общее название для всего, что пытается имитировать интеллект: распознавание лиц, чат-боты, рекомендательные системы — всё это под ИИ. Это скорее концепт, чем конкретная технология.

ML — это уже конкретный подход внутри ИИ. Модели учатся на данных, а не работают по жёстко заданным правилам. Например, если система учится отличать фишинг от нормального письма — это ML.

LLM — это подвид ML, заточенный под работу с текстом. Это те самые модели, которые могут писать тексты, отвечать на вопросы, анализировать документы и т.д. LLM (или Large Language Models) — большие языковые модели, которые обучаются на огромных объемах текста. К LLM относится ChatGPT, Claude и другие сервисы.

Для начала стоит сразу признаться, что мы сами активно применяем ИИ, или как часто уточняют — LLM, в разработке. Например, в MaxPatrol VM машинное обучение уже стало частью функционала: ИИ помогает фильтровать уязвимости, анализировать информацию об активах в инфраструктуре и автоматизировать рутинные задачи. Мы внедрили функцию умного поиска по активам при помощи ИИ: пользователи могут создавать распространенные текстовые запросы без использования языка PDQL. В прошлом году мы даже стали первой системой управления уязвимостями с ИИ в каталоге совместимости российского ПО.

То же самое и в разработке. Когда ежедневно приходят десятки запросов на доработку продуктов или нужно обогащать экспертизу, без автоматизации не обойтись. Мы, как и многие, используем LLM-решения. Например у нас есть:

1. Своя LLM-ка — не ChatGPT, конечно, но для внутренних задач вполне тянет. Кинул запрос — получил ответ, без лишних танцев с бубном.

2. Автодополнение кода — многие разработчики уже привыкли, что VS Code с ИИ-плагинами дописывает код за них. Удобно, когда нейросетка подкидывает готовые куски или даже исправляет косяки на лету.

В сфере безопасности ML тоже на коне. Помимо нашего решения для построения процесса по управлению уязвимостями, есть и другие примеры. Например, современные системы обнаружения и предотвращения вторжений (IDS/IPS), антифрод-системы (системы обнаружения мошенничества) в банках, средства мониторинга активности пользователей (UEBA) — все чаще основаны на алгоритмах обучения. Они изучают нормальное поведение и сигнализируют, если происходит что-то аномальное. Разработчики интегрируют такие модели, чтобы отловить злоумышленника среди миллиарда событий там, где традиционные правила уже не справляются.

Лично я пользуюсь разными ИИ-инструментами практически каждый день. Например, недавно анализировал регуляторные требования по управлению уязвимостями из разных стран за последние годы — ML-модель здорово выручила с переводом, сохраняя технический контекст, тогда как обычные переводчики так не умеют. Другой пример: мы загружали синтаксис PDQL (это наш язык для написания запросов в процессе обработки событий, инцидентов, динамических групп активов, уязвимостей и т. д.) в один из GPT, и он генерировал нам запросы. Главное — правильно подать структуру, чтобы модель не начала выдумывать лишнего. Получается такой быстрый помощник прямо в чате. И даже не зная сам язык, я могу работать с фильтрами и получать нужную мне информацию.

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

Безопасность ML-моделей: какие риски появились с развитием ИИ

Распространение машинного обучения привело к появлению новых классов уязвимостей — уже не просто в коде, а в самих алгоритмах и ML-моделях. Мы уже не первый год наблюдаем, как традиционные проблемы кибербезопасности меняются с развитием ИИ.

Возьмём, к примеру, облачные LLM-сервисы. С одной стороны, они очень мощные и обучаются на огромном количестве запросов — можно быстро получить ответ на сложный технический вопрос или сгенерировать фрагмент кода. При этом все введённые данные попадают к разработчику модели, а даже крупные вендоры не всегда обеспечивают должный уровень их защиты.

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

Еще одна проблема связана, скорее, не с безопасностью ИИ, а с опасностью, которую он представляет в руках злоумышленников. Все чаще даже неопытные хакеры используют ML-модели в своих целях: если раньше для создания вредоносного кода требовались специфические знания, то теперь достаточно пары грамотно составленных запросов. Проблема не в том, что ML — зло, а в том, что мы порой переоцениваем его непогрешимость. Напомню, что нейросеть ошибается иначе, чем человек. Она может с восторгом принять специально искаженные данные за чистую монету. Кроме того, знания о том, как обмануть модель, становятся всё более доступными. Если вчера это были редкие научные статьи, то сегодня существуют публичные списки и инструменты для взлома нейросетей (например, репозиторий awesome-ml-security на GitHub, где собраны реальные инциденты и методы). Проще говоря, злоумышленникам не нужно иметь научную степень по ML, чтобы найти лазейку — достаточно повторить чужой эксперимент.

Большинство сервисов, разумеется, пытаются фильтровать такие запросы, но обход этих ограничений – дело техники. Тем более, когда в самых наипопулярнейших продуктах каждый месяц обнаруживается по одной (а то и больше) самых опасных, или как мы их называем – трендовых, уязвимостей.

Трендовые уязвимости и вызовы эпохи ИИ

В нашем решении по управлению уязвимостями есть такая сущность как «Трендовые узявимости». Это уязвимости, которые прямо сейчас доступны для эксплуатации злобными хакерами, которые уже засветились в паблике, для них есть (не всегда, но и не редко) публичные эксплойты, при этом софт, подверженный этим уязвимостям, вовсю используется пользователями. То есть это самые опасные уязвимости! И здесь намечается интересный сдвиг: если раньше основная доля трендовых уязвимостей приходилась на зарубежное ПО, то теперь мы всё чаще находим их в отечественных решениях. Это не означает, что наши разработчики меньше думают о защите — просто доля российского софта в компаниях растёт, и они становятся более заметной мишенью для злоумышленников. При этом вендоры не всегда оперативно публикуют информацию об обнаруженных уязвимостях, что создаёт дополнительные риски для пользователей. В определении той самой «трендовости» нам тоже помогают ML-модели, а уже результат работы переходит к экспертам для дальнейшей валидации.

Интересно, что некоторые уязвимости в ML-системах напоминают классические проблемы безопасности, только в новом обличье. Тот же инжектинг вредоносных инструкций в промпты — это, по сути, SQL-инъекции, но уже для языковых моделей. Получается, что старые угрозы никуда не делись — они просто эволюционировали вместе с технологиями. С другой стороны, традиционные методы защиты не всегда работают в мире ML-моделей. Например, если раньше мы учили сотрудников не открывать подозрительные письма, то теперь нужно думать о том, как защитить сам ИИ от злонамеренных запросов. Как бы пессимистично это ни звучало, но похоже, уязвимости будут с нами всегда — вопрос лишь в том, как мы с ними справляемся.

Патчи здорового человека vs заплатки курильщика

Наверняка многие слышали такую шутку: «Работает – не трогай» Или трогай?). На самом деле, это недалеко от истины — в любом продукте можно найти уязвимости, будь то в собственном коде, используемых библиотеках или в логике работы. Если бы разработчики могли предусмотреть все возможные сценарии атак, у нас не было бы ни базы NVD, БДУ ФСТЭК, ни MaxPatrol VM, да и работы у безопасников было бы куда меньше.

Возьмем тот же Microsoft — каждый второй вторник месяца выходят патчи, закрывающие уязвимости в их софте, в том числе критические. Это не значит, что они плохо пишут код: просто операционные системы и сопутствующие сервисы это сложные продукты, которые невозможно полностью защитить.

Так что сам по себе неидеальный код это еще не беда: проблемы начинаются тогда, когда появляется zero-day уязвимость, о которой становится известно до появления патча. Еще хуже, если по сети уже вовсю гуляют работающие эксплойты, а вендор просто не признает наличие проблемы. Бывает и так, что разработчик не сообщает, в какой именно версии будет добавлена та самая заплатка. В таких условиях ИБ-специалистам остается только давить на ИT-отдел с требованием обновляться как можно быстрее, что редко способствует нормальным рабочим отношениям.

Среди отечественного софта в этом плане хороший пример, который я вижу — подход Astra Linux. Они четко публикуют информацию об уязвимостях и версиях, где они исправлены. Такой уровень прозрачности значительно упрощает жизнь всем — и ИБ-командам, и системным администраторам.

Как доставлять пользователям обновления, а не проблемы

Чтобы яснее представить проблему, рассмотрим две крайности в подходе к обновлениям — раскатывать все автоматически или устанавливать вручную. Например, в Японии распространена концепция «24/7», предполагающая полную автоматизацию установки патчей. Что может пойти не так в этой ситуации, могут рассказать разработчики CrowdStrike, чье обновление привело к массовым сбоям в работе аэропортов и крупных компаний. Их пример хорошо показывает, почему автоматическое обновление без должного тестирования — плохая идея.

Ручная установка тоже не лучший вариант — пока мы будем с хирургической точностью имплантировать наши патчи, злоумышленники также прекрасно справятся с остановкой ключевых сервисов и не только. Некий баланс смогли найти британские регуляторы с их поэтапной схемой обновлений: сначала тестируем патч, затем накатываем на 10% инфраструктуры, ждем пару дней, потом еще на 50%, и только затем — на самые критичные системы.

Лично я считаю, что автопатчинг может быть эффективным, но только при соблюдении определенных условий:

• У клиента должна быть возможность выбирать между стабильными и тестовыми версиями (как LTS и rolling release в Linux)

• Важно иметь механизм быстрого отката (фич-флаги в облачных решениях или бэкапы для on-prem)

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

Ситуация здесь похожа на применение в работе ML — как и любой инструмент, автоматическое обновление может принести как пользу, так и вред. Все зависит от того, насколько грамотно оно реализовано.

Как изменился рынок управления уязвимостями за последние годы

Изменение подходов к патч-менеджменту — яркий пример того, как стремительно эволюционирует вся сфера управления уязвимостями. Еще в 2021 году картина была совсем другой и на рынке существовало всего несколько ключевых игроков, включая наш MaxPatrol 8 и пару-тройку других сканеров.

Начиная с 2022 года произошло несколько важных изменений:

• НКЦКИ выпустил новые алгоритмы принятия решений по патч-менеджменту

• ФСТЭК представил методику оценки критичности уязвимостей

• В 2023-м появились официальные рекомендации по выстраиванию процессов управления уязвимостями

• Новый приказ №117 ФСТЭК. Он заменяет 17-й приказ 2012 года и касается всех ИС госорганов, учреждений и ГУПов, не только ГИС. (Теперь помимо анализа защищённости и сканирования на уязвимости, появилось новое прямое требование:

  Контроль конфигураций информационных систем.)

• На рынок вышло множество новых игроков со своими решениями

• Появились новые требования по сертификации безопасной разработки.

Почему так резко вырос спрос на управление уязвимостями? Конечно, свою роль сыграл определенный вакуум, который образовался после ухода из России западных вендоров. Однако главное — изменилось само отношение компаний к безопасности. Клиенты стали более зрелыми, появилось четкое понимание, чего именно они хотят от продуктов по управлению уязвимостями.

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

Будущее управления уязвимостями: симбиоз с ИИ

Прошедший год стал для нас серьезным шагом вперед, ведь мы не просто нарастили функционал, а перешли на качественно новый уровень. Например, MaxPatrol VM научился справляться с сотнями тысяч активов, хотя еще недавно такие цифры казались фантастикой. Причем мы прекрасно понимаем, что в перспективе должны быть готовы к работе с миллионами устройств в единой системе.

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

На наш взгляд, ИИ в кибербезопасности — это не конкурент, а полезный инструмент в руках профессионалов. А как вы считаете, какие задачи в вашей работе можно делегировать алгоритмам, а какие нужно оставить под контролем человека?