«Лаборатория Касперского» выпустила новый продукт Kaspersky VM для мониторинга инфраструктуры на уязвимости и соответствие требованиям. Цель запуска — дополнение экосистемы Kaspersky Security Center. Однако вендор явно задумывался о дополнительных нереализованных функциях в этой нише.
- 1. Введение
- 2. Зачем ещё один продукт в нише VM
- 3. «Зоопарк» решений в инфраструктуре, «хаотичность» в управлении защитой, Open Source
- 4. Доступ к базам уязвимостей
- 5. Комплаенс и отечественные VM-продукты
- 6. Количество уязвимостей в базе и защищённость
- 7. Генерация уникальных уязвимостей уже близко
- 8. С приходом ИИ наблюдается рост направления Offensive Security
- 9. Останутся ли разработки Anthropic «лабораторным экспериментом»?
- 10. Kaspersky VM и ИИ
- 11. Выводы
Введение
15 июля компания «Лаборатория Касперского» анонсировала выпуск нового продукта в экосистеме безопасности Kaspersky Security Center. Он получил название Kaspersky VM (Vulnerability Management) v.1.0 и предназначен для реализации широкого набора задач: автоматизации централизованного поиска и управления уязвимостями; контроля за соответствием нормативным требованиям (комплаенс); скоринга рисков; планирования работ по поддержке ИТ-инфраструктуры в защищённом состоянии; усиленного контроля периметра и филиалов, через которые злоумышленники все чаще приходят в основную инфраструктуру из-за несвоевременного устранения уязвимостей на периметре защиты.
Рисунок 1. Анна Кулашова назвала уязвимости одной из главных проблем для устойчивости бизнеса компаний
На первый взгляд этот шаг выглядит логичным: ИБ-команда получает в своё распоряжение продукт, который позволит ИБ-службе снять стресс от трудностей поддержки безопасности в разветвлённой или лоскутно построенной ИТ-инфраструктуре, перейдя к более организованной форме выполнения задач мониторинга и обновления инфраструктуры.
На первый взгляд этот продукт принципиально ничего не меняет. Возможности управления активами в безопасном состоянии существовали в экосистеме Kaspersky Security Center и до сих пор благодаря управлению через центральное Linux-приложение или веб-портал. Kaspersky VM фактически выглядит в этой экосистеме как middleware-надстройка. Экосистема Kaspersky получила ожидаемое дополнение.
Но если принять во внимание множество других подробностей, то окажется, что всё значительно интереснее.
Рисунок 2. Экосистемный подход на базе Kaspersky VM
Зачем ещё один продукт в нише VM
Для начала отметим, что ниша продуктов класса Vulnerability Management в целом достаточно хорошо развита на рынке. Она освоена как российскими, так и зарубежными разработчиками.
Среди российских решений можно назвать как экосистемные, так и самостоятельные продукты: MaxPatrol VM от Positive Technologies, R-Vision VM, ScanFactory VM, Vulns.io VM и др.
Список западных продуктов не менее обширен: Cisco Vulnerability Management; ESET Vulnerability & Patch Management; Qualys VMDR; Rapid7 InsightVM; Tenable.io Vulnerability Management и др.
Добавим также обширный список Open Source-утилит этого класса, которые позволяют решать многие относящиеся к этой области задачи не хуже, чем коммерческие продукты. Список лучших Open Source-инструментов может выглядеть так: Apiiro; DefectDojo; Nuclei; OpenSCAP; OpenVAS; Trivy и др.
На первый взгляд появление Kaspersky VM выглядит достаточно заурядно. Может показаться (хотя, возможно, именно так и ставилась задача в начале), что необходимо просто добавить недостающее звено в экосистему продуктов Kaspersky Security Center, обеспечив магическое «всё учтено и меньше рисков для нестыковок ПО».
Но за этой внешней витриной лежит пласт нераскрытых задач, который невидим с первого взгляда. Отрасль находится на этапе нового большого скачка в своём развитии после преобразования HW (аппаратных решений) в IaC (Infrastructure as Code), распределения функций между on-premise- и cloud-локациями, существенного преобразования endpoint-устройств и, самое последнее, прихода ИИ в отрасль ИБ.
Понимая новые условия и риски, можно теперь иначе взглянуть на новый продукт Kaspersky VM.
«Зоопарк» решений в инфраструктуре, «хаотичность» в управлении защитой, Open Source
Для начала надо ответить на вопрос, зачем Kaspersky Security Center нужен инструмент класса VM, если он, по сути, выполняет функции, которые уже есть в арсенале Security Center.
Ответ скрыт в особенностях ИТ-инфраструктуры компаний, которые для российских заказчиков сейчас значительно выросли в силу разных причин:
- «зоопарк» и «хаотичность» при построении ИТ-инфраструктуры;
- риски потери доступа к общедоступным глобальным базам уязвимостей, требующим постоянного обновления;
- изменения в российской регуляторике и повышение размера штрафов за нарушение её требований.
Разберём каждый пункт.
«Зоопарк» и «хаотичность» существуют в той или иной мере у всех компаний. Это – результат естественного роста их ИТ-инфраструктуры и постоянного обновления составляющих элементов, изменения требований со стороны бизнеса, например, после M&A-процессов и т. д. Неизбежное следствие – головная боль ИТ- и ИБ-служб «Как жить с этим?»
До 2022 года в России многие компании могли в той или иной мере перекладывать проблемы на крупных поставщиков (HPE, Dell и других). Главное – закупать в инфраструктуру только оборудование выбранного вендора и его рекомендованных партнёров. После 2022 года таких поставщиков-аналогов нет в России, а те компании, которые стремились вырасти до такого уровня, не получили поддержки со стороны Минпромторга и сейчас оказались в лучшем случае убыточными, в худшем – банкротами.
В таких условиях российские компании вынуждены снижать требования к закупке оборудования, переходить на параллельный импорт и выбор оборудования от нескольких производителей. Это значительно повышает «хаотичность». Поскольку в стране нет единого стандарта для отечественных продуктов для импортозамещения, это порождает порождение многочисленных альтернативных решений и проблемы обеспечения их совместимости «закладываются» на годы вперёд.
Первое, что отметила «Лаборатория Касперского» при анонсе Kaspersky VM, – это широта охвата поддерживаемых пакетов под Linux. В настоящее время её список поддержки насчитывает свыше 48 000 пакетов.
В условиях, когда многие российские компании переходят на отечественные Linux-дистрибутивы, их учёт в продуктах VM также является критичным. Антон Иванов, технический директор «Лаборатории Касперского», отметил, что сейчас в списке поддержки представлены более 10 основных отечественных и зарубежных дистрибутивов Linux.
Первый вывод для Kaspersky VM – это желание снизить остроту проблем от хаотичности развития ИТ-инфраструктуры российских предприятий.
Рисунок 3. Антон Иванов показал, что найденных уязвимостей в ПО становится больше
Доступ к базам уязвимостей
Второй важный признак для развития направления VM – это гарантия доступности постоянно обновляемых баз уязвимостей.
Коснувшись этого направления, Антон Иванов назвал, что уже на этапе первой версии Kaspersky VM в её базе уязвимостей представлено более 370 000 записей. Пока новый продукт не предоставляет доступа к подробным описаниям уязвимостей из собственной базы Kaspersky Threat Intelligence (TI), но возможность оперативного доступа к этой информации будет добавлена в будущем.
Отметим и то, что Антон Иванов сравнил в завуалированной форме (не называя конкретно) новый продукт Kaspersky VM с его известным VM-аналогом. Не так трудно догадаться, что речь идёт о Rapid7 InsightVM. В поставляемой с ним базе содержится на порядок меньше учтённых уязвимостей (около 20 000 шт.). Но в силу понятных причин не был отмечен более существенный признак: Rapid7 агрегирует информацию в т. ч. из общедоступных западных каталогов уязвимостей, что видно по отчётам каталога OpenCVE, а задачи суверенитета и импортозамещения для российских компаний делают такой путь… рискованным.
Комплаенс и отечественные VM-продукты
Следующий признак – это особенности поддержки функций комплаенса. Особое значение приобретает сейчас автоматизация проверки конфигураций ИТ-инфраструктуры и оценки на соответствие стандартам безопасности и регуляторным требованиям, а также поддержка готовых профилей ФСТЭК № 17, № 21, № 31, № 239. Эти функции – одно из значимых свойств Kaspersky VM.
Добавим ещё несколько слов о патч-менеджменте для управления обновлениями. В новом продукте он реализуется через уже доступный в экосистеме Kaspersky Security Center Linux. Отсутствие упоминания Kaspersky Security Center Web Console, скорее всего, объясняется ограничением первой версии Kaspersky VM. Принципиальной разницы между этими вариантами нет, но веб-вариант требует дополнительно усилить контроль над критичными операциями, чтобы исключить риск компрометации. Можно ожидать, что эта поддержка будет добавлена в более поздних версиях.
Рисунок 4. Архитектура решения задач с применением Kaspersky V
Важность собственного контроля комплаенса проявляется в сравнении с Open Source-продуктами VM, которые сильно зависимы от сообщества. Open Source-продукты ориентированы чаще всего на поддержку европейского регламента по защите данных GDPR (General Data Protection Regulation), тогда как для российских компаний требуется поддержка отечественной регуляторики.
Количество уязвимостей в базе и защищённость
Запуск разработки Kaspersky Vulnerability Management был связан с очевидной необходимостью дополнить комплекс ИБ-решений «Лаборатории Касперского», оформив её в самостоятельную платформу из ИБ-продуктов и продолжить их развитие как единой экосистемы, опираясь на сохраняющуюся многолетнюю международную экспертизу в выявлении и устранении киберугроз по всему миру.
Прагматичная цель, как отметила Анна Кулашова, вице-президент по развитию бизнеса «Лаборатории Касперского» в России и странах СНГ, стояла в том, чтобы предоставить заказчикам возможность оптимизировать совокупную стоимость владения своей ИТ-инфраструктурой за счёт интеграции с другими продуктами вендора. Появление нового продукта должно положительно повлиять на эффективность и конкурентоспособность бизнеса самого вендора.
Это – фундамент задач, которые должны решать российские заказчики в первую очередь. Но на их фоне есть также новые риски, связанные с приходом ИИ в отрасль ИБ. На них обратил внимание Антон Иванов.
Тогда как российские участники рынка чаще всего пока только делают прогнозы, как ИИ отразится на защищённости компаний, в «Лаборатории Касперского», похоже, уже осознали, что время для прогнозов уже исчерпано. Пришло время внедрять «кирпичики», защищающие от грядущего наращивания угроз со стороны злоумышленников, которые осваивают ИИ вместе с рынком. Иначе последствия для компаний будут катастрофическими.
Как отметил Антон Иванов, в «Лаборатории Касперского» ожидают стремительного ускорения процесса выявления уязвимостей и генерации эксплойтов. Управлять уязвимостями, скорингом рисков, контролировать комплаенс в прежнем темпе и на прежних технологиях скоро будет недопустимо. Широкое применение ИИ злоумышленниками качественно изменит ИБ уже в ближайшем будущем.
Можно делать прогноз, когда это произойдёт – через полгода/год или через несколько лет. Но темпы изменений, которые демонстрирует сейчас ИИ, существенно сужают горизонт событий.
Генерация уникальных уязвимостей уже близко
«Лаборатория Касперского» насчитывает в настоящее время 3,5 тыс. разработчиков и более 200 000 единиц серверного оборудования, расположенных в дата-центрах по всему миру. Значительная часть мощностей используется для ежедневного поиска и классификации багов, обновления угроз, разработки и поддержки инструментов для управления безопасностью на предприятиях.
Становясь частью единой экосистемы Kaspersky Security Center, Kaspersky VM обеспечивает централизованное управление совокупностью ИБ-задач, связанных с поддержкой ИТ-инфраструктуры в безопасности: выявление и устранение уязвимостей; «накатка» обновлений; классификация рисков, планирование задач по нейтрализации угроз, комплаенс и т. д.
Рисунок 5. Kaspersky VM становится частью единой экосистемы ИБ-продуктов «Лаборатории Касперского»
Согласно статистике «Лаборатории Касперского», количество выявленных уязвимостей продолжает расти с каждым годом. Несмотря на внедрение методологий безопасной разработки, повышенное внимание к вопросам безопасности и пр., процесс неуклонно идет круто вверх.
Это знают и злоумышленники. По данным глобального отчёта Kaspersky Security Services, если 25 % реальных атак связано с атаками злоумышленников через скомпрометированные учётные записи, то 44 % кибератак приходится на эксплуатацию уязвимостей, обнаруженных в публично доступных приложениях.
Но отметим очень важный признак: принципиально новые (алгоритм или принцип атаки) уязвимости появляются достаточно редко. В основном уязвимости возникают на базе известных моделей, только они проявляются в индивидуальном паттерне для разного SW/HW.
Развитие ИИ качественно меняет общую картину. Как показали данные собственных исследований «Лаборатории Касперского», на создание экспериментального рабочего эксплойта для Firefox с использованием ИИ было затрачено менее одного часа, тогда как раньше эта задержка составляла несколько дней и более. Аналогичная картина наблюдается и для задач поиска багов. Взамен прежних недель на поиски ИИ помогает найти их в течение одного или нескольких часов.
На первый взгляд, внедрение ИИ даёт преимущество прежде всего стороне защиты («синим»). После обучения LLM появляется возможность понимать «модель построения бага» и сразу оценивать инфраструктурные элементы, в каком виде она может проявиться. В результате ИИ позволяет отыскивать баги без заранее найденных эксплойтов, тогда как до сих пор сначала требовалось выявить эксплойт, а потом по нему восстанавливалась вся цепочка поражения системы и отыскивались баги.
С появлением хакерских ИИ-инструментов преимущество «синих» будет потеряно. Главный потенциал Kaspersky VM – это вовремя предоставить информацию, чтобы поставить преграду на пути таких «уникальных уязвимостей», которые в будущем будет плодить ИИ со стороны злоумышленников.
С приходом ИИ наблюдается рост направления Offensive Security
Катастрофы с приходом ИИ ещё не произошло, но можно ли смотреть на происходящее со стороны?
Чтобы дать ответ, достаточно внимательно посмотреть на историю того, как происходило развитие ИИ в последние пару лет. В качестве примера мы воспользуемся тем, как этот вопрос раскрыла компания Anthropic на примере четырёх последовательных версий своей LLM-модели Claude. Эти результаты демонстрируют «ранние предупреждающие признаки» того, что прогресс в росте угроз может оказаться настолько быстрым, что соответствующий заслон надо ставить уже сейчас.
Почему мы тоже выбрали показать здесь пример Claude? Даже в Anthropic не скрывали, что эта LLM-модель обучается для задач «двойного назначения». Она может применяться как для Defensive, так и для Offensive Security. И если взять за пример геополитику, то кто будет первым испытуемым для отработки задач нападения, думаю, трудно ошибиться.
Для оценки прогресса в развитии ИИ эксперты Anthropic использовали задачи по кибербезопасности, предлагаемые на хакерских соревнованиях Capture The Flag (CTF), где требуется показать навыки в поиске и реализации уязвимостей ПО в контролируемой среде (Intercode CTF Challenge).
Как показали результаты исследования, всего за один год доля правильных ответов LLM-моделей семейства Claude выросла с 23 % (уровень старшеклассника) до около 90 % (уровень бакалавра). Особую ценность этим результатам придаёт то, что в тестовый набор были добавлены задачи, которые ранее не встречались в соревнованиях и нигде не упоминались. Их специальная разработка гарантировала чистоту эксперимента, исключала возможность нахождения ранее полученного и подтверждённого ответа в обучающих данных.
Рисунок 6. Доля правильных ответов при решении задач Intercode CTF Challenge с помощью Claude
Аналогичные результаты дают бенчмарки Cybench для оценки LLM-моделей, разработанные на основе более сложных задач CTF. Благодаря им можно оценить, как изменяется доля успешно решённых ИБ-задач в зависимости от числа предпринятых попыток. Результат налицо: если доля правильных ответов с пятой попытки для LLM-модели Claude 3 Sonnet, выпущенной в марте 2024 года, составляла только 3 %, то для модели Claude 3.7 Sonnet, выпущенной год спустя, планка поднялась уже выше 30 %.
Рисунок 7. Результаты Cybench CTF для различных версий Claude 3 Sonnet
На следующем рисунке показано, как росло качество ответов ИИ в разных категориях ИБ-задач (CTF). В этих запросах ИИ должен был предложить код для обнаружения уязвимостей в небезопасной программной среде и написать программу для их реализации. Варианты рассмотренных ниш: а) на удалённом сервере («pwn»); б) в веб-приложениях («web»); в) в криптографических примитивах и протоколах («crypto»).
Рисунок 8. Доля задач CTF для различных задач ИБ, решённых с помощью Claude 3
Но здесь важно отметить другое. Уже на этапе этих исследований (март 2025 года) в Anthropic искали ниши, где Claude все ещё уступала человеку с уровнем подготовки «опытный член команды Red Teaming». На тот момент эти выявленные преграды еще не скрывались. ИИ-модель уступала человеку: 1) в задачах реверс-инжиниринга исполняемых файлов и поиска скрытых уязвимостей в исходном коде; 2) в проведении разведки и эксплуатации уязвимостей в сетевой среде (ей требовались по крайней мере подсказки, чтобы достичь результата).
Останутся ли разработки Anthropic «лабораторным экспериментом»?
Тема публичной закрытости части разработок в области ИБ всегда была очевидна. Невозможно разрабатывать средства защиты только на артефактах кибератак. Нужны собственные, как минимум, тестовые образцы, на базе которых ведётся разработка средств безопасности.
Но уже год концепция развития Security-инструментов сместила крен из Defensive Security в направлении Offensive. Деятельность Anthropic попала как раз в точку разлома этого тренда на рынке. Поэтому её явный крен в сторону Offensive проявился сразу.
В Anthropic уже тогда отмечали, что развитие LLM-модели Claude ориентировано на решение ИБ-задач, но для экспериментов использовались не только тесты CTF (которые можно считать все-таки «синтетическими»), а реалистичные киберполигоны (число хостов — около 50). На них отрабатывалась способность обнаруживать уязвимости в небезопасной программной среде и использовать их, например, для вирусного заражения, осуществления бокового движения с целью перемещения по сети.
На примере созданной тестовой сети Anthropic было доказано, что уровень развития Claude (на март 2025 года) достаточен для реализации кибератаки, подобной той, которую провели китайские хакеры на кредитное бюро Equifax.
Kaspersky VM и ИИ
Но вернёмся к теме Vulnerability Management и Kaspersky VM. Предыдущий рассказ об изменениях в связи с приходом ИИ довольно прозрачно указывает на то, что классические VM-продукты могут быстро устареть, если им придётся столкнуться с ИИ-угрозой.
Изменения коснулись не только скорости появления новых уязвимостей, значительного роста рисков выявления уязвимостей в ИТ-инфраструктуре с учётом её текущей конфигурации и полноты покрытия обновлениями. С приходом ИИ поверхность атаки ИТ-инфраструктуры предприятий осталась прежней, но ИИ меняет логику управления уязвимостями. Если традиционная логика Vulnerability Management построена на модели частого сканирования ИТ-инфраструктуры и последующего устранения уязвимостей, то ИИ встраивает VM в жизненный цикл инфраструктуры.
Рисунок 9. Поверхность кибератаки, контролируемой через VM
Приход ИИ вносит изменения как минимум по следующим четырём направлениям. Формально они встречались и ранее, но ИИ качественно меняет их содержание.
Объединение и унификация данных о рисках
Модели ИИ позволяют собирать и приводить к нормализованному виду результаты оценки рисков, полученные из различных источников: облачные сканеры; инструменты ASPM (оценка безопасности кода и элементов управления питанием); инструменты SCA (Software Composition Analysis, автоматизированное сканирование ПО для выявления уязвимостей в сторонних библиотеках Open Source); другие сканеры уязвимостей.
На базе этой информации формируется единый список уникальных рисков для ИТ-инфраструктуры без повторов и фрагментации информации на различных панелях мониторинга — известная проблема для традиционных систем управления уязвимостями, которые способны отображать информацию об обнаруженных проблемах только в пределах заданной поверхности контроля.
Контекстная приоритизация рисков
Традиционная модель сканирования на поиск уязвимостей ведёт к статичной классификации рисков. Внедрение ИИ позволяет учесть новые факторы при выборе уровня риска для уязвимости: доступность; возможность эксплуатации; наличие доступа к внешним сетям/интернету; критичность для бизнес-задач.
ИИ добавляет к абстрактным рискам контекст и расширяет логику учёта в условиях конкретной среды. В традиционной модели безопасности эта оценка была на уровне субъективного понимания CISO.
Анализ источника проблем
Традиционная модель защиты рассматривает каждое обнаруженное уязвимое место через риск совершения там определённого изолированного события. Внедрение ИИ позволяет отследить группу связанных между собой уязвимостей и выявить общий для них источник проблемы. Он может быть связан с определённым модулем IaC (Infrastructure as Code) или вызван неправильно настроенной политикой.
В результате вместо набора изолированных рисков теперь ИИ сможет выделять отдельный кластер проблемы и обозначать последовательную цепочку того, как она может проявляться при реализации выявленных рисков.
Управление и автоматизация операций
Самые передовые ИИ-платформы будут использовать агентные ИИ-решения для подготовки кода на внесение изменений и моделирования ответных эффектов отработки этого кода. Фактически это позволит оценить результаты внесения изменений до их фактической реализации и смягчить тем самым возможные неблагоприятные последствия, которые нередко возникают, потому что разработка кода ведётся без учёта реальных особенностей конкретной инфраструктуры.
При традиционной модели требуется готовить не только обновления, но и резервировать прежнее состояние ИТ-инфраструктуры для смягчения последствий, если исправления сработают с ошибкой. Из-за этого немедленный возврат часто оказывается невозможным, и проблема остаётся нерешённой. Напомним, что время поиска новых уязвимостей стремительно сокращается с приходом ИИ. Если до сих пор у ИБ был запас времени в противостоянии угрозам, то в будущем такой возможности у них может не оказаться.
Выводы
Выход компании «Лаборатория Касперского» выглядит не только полезным, но и необходимым. Но впереди много задач, связанных с Vulnerability Management. Их решение — это уже не импортозамещение. Как отражать новые угрозы, придётся разрабатывать самим.
Прежде можно было рассчитывать на то, что это сделают западные вендоры, получив от них готовое решение. Сейчас нужно двигаться в сторону создания собственных решений. Делать ли это порознь с глобальными игроками или проводить границу иначе — ответ на этот вопрос также будет сказываться на том, как российские вендоры отреагируют на угрозы. Это касается не только «Лаборатории Касперского» как нового вендора на рынке VM, но и всех остальных российских игроков.
