Управление уязвимостями

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

В этих условиях особое значение приобретает системный подход к выявлению, оценке, классификации и устранению уязвимостей. Эффективность процесса зависит от грамотной автоматизации, прозрачных процессов и тесной координации между подразделениями безопасности, ИТ и разработки. Современные решения в области VM (vulnerability management — управление уязвимостями) выходят за рамки традиционного сканирования, интегрируясь в жизненный цикл разработки, обогащаясь аналитикой угроз и поддерживая приоритизацию на основе бизнес-контекста. Управление уязвимостями превращается из технической функции в стратегический процесс, напрямую влияющий на устойчивость бизнеса.

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

Специалисты уточнили, как обеспечить централизованный сбор и корреляцию данных из различных источников, какие метрики позволяют отслеживать эффективность процессов, и как организовать координацию между командами безопасности, разработки и эксплуатации. Кроме того, эксперты поделились мнением о перспективах внедрения ИИ, развитии VOC-центров, интеграции с CI/CD и новых подходах к оценке риска. С нами пообщались:

• Руслан Рахметов, СЕО Security Vision.
• Владимир Иванов, CEO ScanFactory.
• Никита Котиков, руководитель направления верификации уязвимостей, компания CICADA8.
• Вадим Матвиенко, руководитель лаборатории исследований кибербезопасности аналитического центра кибербезопасности «Газинформсервиса».
• Роман Коваленко, Ведущий специалист по анализу безопасности «Группы Астры».
• Екатерина Буденная, Руководитель отдела анализа защищённости «Группы Астры».

Какие источники и методы используют для своевременного выявления уязвимостей и проверки их релевантности инфраструктуре?

Руслан Рахметов, СЕО Security Vision:

«Современные системы управления уязвимостями (VM) позволяют проканировать активы в режимах «белый» ящик (аудит, аутентифицированное сканирование) и «черный» ящик (пентест, неаутентифицированное сканирование), выполнить сканирование веб-приложений и Docker-контейнеров, провести детальное сканирование файловой системы актива для получения информации о portable-версиях ПО».

«Кроме того, VM-решения позволяют провести инвентаризацию и классификацию активов и поддерживают функционал ретроспективного сканирования, который позволяет быстро обнаруживать уязвимости без повторного сканирования на основе собранной ранее информации о версиях установленного на активах ПО».

Руслан Рахметов подчеркнул, что продвинутые платформы управляют приоритетами, уведомляют ответственных лиц и автоматизируют патчинг.

«Продвинутые VM-решения выполняют также обогащение уязвимостей из внешних аналитических сервисов, позволяют приоритизировать уязвимости, создавать заявки на их устранение и отправлять уведомления ответственным, а также поддерживают автоматический патчинг уязвимостей и управление политиками обработки уязвимостей».

Владимир Иванов, CEO ScanFactory:

«К сожалению, все российские вендоры используют два базовых подхода: баннерный детект (черным ящиком) и анализ установленных пакетов (белым ящиком). Это устаревший и в современных реалиях недостаточный подход к анализу уязвимостей, поскольку не учитывает особенности установки реальных приложений».

Он указал, что современный инструмент должен поддерживать проверку активной эксплуатации и веб-уязвимостей с использованием широкой базы.

«В современном инструменте, помимо вышеназванного, должен присутствовать анализ с помощью широкой базы поддерживаемого ПО путём запуска safe-check’ов для проверки активной эксплуатации, анализа уязвимостей веб-приложений. Все это необходимо не для галочки регулятора, а проверять реальные атаки, которыми злоумышленники пользуются для пробива критичных сегментов».

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

«В связи с этим, источники уязвимостей можно использовать, но это бесполезно, а методы и подходы должны соответствовать действиям и инструментарию реальных злоумышленников».

Никита Котиков, руководитель направления верификации уязвимостей, компания CICADA8:

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

Он отметил, что современные компании переходят к решениям EASM/ETM, способным обнаруживать уязвимости и «теневую» инфраструктуру.

«Поэтому сейчас более широкое распространение получают решения класса EASM/ETM (external attack surface management). Они обнаруживают на внешнем периметре не только уязвимости, но и неизвестные ИТ-активы (shadow infrastructure). При сканировании происходит также поиск доступных сервисов для ИТ-активов, это позволяет произвести их инвентаризацию. EASM-решения классифицируют уязвимости и отображают их уровень критичности, что помогает определить их релевантность для исследуемой инфраструктуры».

Никита Котиков добавил, что важно учитывать и другие киберриски — в том числе утечки данных и работу подрядчиков.

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

Он пояснил, что для внутренних активов применяются классические VM-системы.

«Для поиска уязвимостей во внутренней инфраструктуре используются решения класса VM (vulnerability management). Они также идентифицируют доступные ИТ-активы компании, выявляют сервисы и сканируют их на уязвимости».

Специалист отдельно выделил работу с веб-приложениями, где анализ следует начинать ещё на этапе разработки.

«Отдельно следует сказать о выявлении уязвимостей в веб-приложениях, которые находятся на внешнем и внутреннем периметре. Здесь меры по контролю защищенности могут и должны приниматься еще на этапе разработки – с помощью технологий динамического анализа (DAST), анализа исходного кода (SAST), выявления уязвимостей сторонних библиотек и компонентов (SCA) и других решений. Тут также можно использовать метод моделирования угроз, который помогает выявить проблемы безопасности еще до имплементации приложений в виде кода».

И подчеркнул значимость открытых баз, включая CVE, NIST и ExploitDB, как источников информации.

«В качестве источников информации об уязвимостях и определения их релевантности зачастую используют открытые базы данных, такие как CVE, NIST, ExploitDB и другие. Они содержат информацию об уязвимой технологии, методах эксплуатации, доступности PoC (proof-of-concept) и CVSS (Common Vulnerability Scoring System), на основе которой возможно понять уровень критичности уязвимости. Для решений класса SCA важным параметром является EPSS (exploit prediction scoring system). Все эти данные позволяют приоритизировать, классифицировать и выявить релевантность уязвимостей для исследуемой инфраструктуры».

Никита Котиков добавил, что оценка релевантности может проводиться вручную, автоматически, а в будущем и с участием ИИ.

«Проверка релевантности уязвимостей также может производиться автоматически путем их воспроизведения, однако данный подход имеет свои тонкости и не всегда может быть использован. Другим методом является ручная проверка внутренними или привлеченными специалистами. Кроме того, сейчас для решения этого класса задач начинает использоваться ИИ, и мы прогнозируем усиление этого тренда в ближайшие годы».

Вадим Матвиенко, руководитель лаборатории исследований кибербезопасности аналитического центра кибербезопасности «Газинформсервиса»:

«Основным источником информации об уязвимостях в системах и программах являются национальные и международные базы данных уязвимостей. Для российских организаций и программного обеспечения, созданного в России, рекомендуется использовать БДУ ФСТЭК России.
Этот ресурс содержит уникальные записи и подробную информацию о программном обеспечении, разработанном в России».

Он пояснил, что CVE остаётся мировым стандартом идентификации уязвимостей и широко применяется в различных инструментах и системах.

«Один из самых известных международных проектов — CVE (Common Vulnerabilities and Exposures). CVE — это стандарт для идентификации уязвимостей, который поддерживается некоммерческой организацией MITRE. Каждая уязвимость получает уникальный идентификатор (CVE-ID), что позволяет унифицировать данные между различными инструментами и базами».

Вадим Матвиенко также упомянул Национальную базу США — NVD, которая дополняет CVE и предоставляет технические детали, оценки и рекомендации.

«Также стоит упомянуть Национальную базу данных уязвимостей США (NVD), которая используется во многих странах мира. Этот ресурс поддерживается Национальным институтом стандартов и технологий (NIST). NVD основана на CVE и дополняет каждую запись техническими деталями, оценками по CVSS (Common Vulnerability Scoring System), рекомендациями по устранению, ссылками на патчи и другими полезными материалами».

Он добавил, что в Китае действуют аналогичные платформы — CNNVD и CNVD, которые ориентированы на национальные потребности и обеспечивают централизованный сбор и анализ информации.

«В Китае существуют свои аналоги национальных баз данных уязвимостей: CNNVD (Chinese National Vulnerability Database), CNVD (China National Vulnerability Database). Обе базы выполняют функции, аналогичные американской NVD, но ориентированы на внутренние нужды Китая. Они обеспечивают централизованный сбор, анализ и публикацию данных об уязвимостях в программном и аппаратном обеспечении, активно используемом в стране. Это позволяет Китаю оперативно реагировать на угрозы, особенно в отношении программного обеспечения, недоступного на западном рынке. На фоне новостей об закрытии проекта CVE имеет смысл обратить и на данный источник информации».

В заключение Вадим Матвиенко подчеркнул, что для эффективной работы с уязвимостями требуется чёткая методика, инвентаризация активов и регулярный автоматизированный анализ.

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

Роман Коваленко, Ведущий специалист по анализу безопасности «Группы Астры»:

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

Специалист добавил, что для эффективной обработки этой информации необходимо автоматизированное решение.

«Для эффективного сбора и управления получаемой информацией необходимо наличие автоматизированной среды».

Роман Коваленко отметил, что анализом релевантности уязвимостей должен заниматься профильный специалист, имеющий доступ к актуальной нормативной документации.

«Определением релевантности уязвимостей инфраструктуре должен заниматься специалист-аналитик, причем необходимо наличие понятной и актуальной МУ и ПА, чтобы можно было оперативно сопоставить с ней информацию об уязвимости и принять решение о релевантности ее инфраструктуре».

Эксперт указал на необходимость учитывать зависимости между программными компонентами при анализе угроз.

«Также необходимо учитывать информацию о зависимостях тех или иных программных компонентов, входящих в инфраструктуру».

Коваленко Роман обратил внимание, что особую важность представляют новые уязвимости, которые зачастую уже активно эксплуатируются злоумышленниками.

«Особую ценность представляют новые уязвимости, поскольку на самом деле они могут быть «не новы», а уже активно эксплуатироваться нарушителями».

Ведущий специалист по анализу безопасности «Группы Астры» добавил, что в качестве источников сведений о таких угрозах стоит использовать программы BugBounty, а также внутренние и внешние пентесты.

«В качестве источников информации о таких уязвимостях могут выступать площадки BugBounty, а также внтренний и внешний пентест. В таком случае на выходе сразу получаются релевантные уязвимости».

Как выстроить централизованный сбор, агрегацию и корреляцию данных из сканеров, багбаунти и тикет-систем?

Руслан Рахметов, СЕО Security Vision: «Для подобной централизации необходимо применять платформы управления уязвимостями, в которых происходит обработка и обогащение всех данных по уязвимостям. Важно не только получить результаты сканирования из одного сканера, но и объединить и скоррелировать их с данными из других сканеров, систем управления активами и конфигурациями (ITAM/CMDB), а затем сформировать заявки на устранение уязвимостей или на изменение конфигураций систем».

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

Владимир Иванов, CEO ScanFactory: «Лучшими практиками считается использование SOAR, либо любой таск-трекер ИБ-специалистов, таких как SGRC и TIP, то есть вариант централизованного хранения информации».

Владимир Иванов отметил, что помимо автоматизации возможен альтернативный путь — назначение конкретных сотрудников на ключевые системы защиты и налаживание их координации.

«В качестве альтернативного, но не менее эффективного, подхода — завязать конкретных специалистов на конкретные системы защиты информации, настроить их взаимодействие между собой».

Вадим Матвиенко, руководитель лаборатории исследований кибербезопасности аналитического центра кибербезопасности «Газинформсервиса»: «Для эффективного управления уязвимостями рекомендуется использовать автоматизированные и централизованные инструменты сбора информации. Это особенно важно для крупных и сложных инфраструктур, где ручной труд занимает много времени и часто приводит к ошибкам».

Руководитель лаборатории исследований кибербезопасности Вадим Матвиенко пояснил, что основой должны стать системы учёта активов, платформы управления уязвимостями и интеграция с тикет-системами для организации изменений.

«Вот несколько ключевых инструментов:

• Asset Management — это система, которая собирает и хранит все данные об информационных системах, их версиях, владельцах и состоянии. Она позволяет быстро получить полную информацию об ИТ-активах в одном месте.
• Vulnerability Management Platform — это платформа для сбора данных об уязвимостях. Они включают в себя сканеры уязвимостей, которые автоматически по расписанию или по запуску вручную проверяют ИТ-активы на наличие уязвимостей и позволяют приоритизировать уязвимости.

Однако управление уязвимостями — это не только поиск проблем, но и их устранение. В этом процессе участвуют разные ИТ-подразделения. Чтобы всё работало эффективно, нужно организовать управление изменениями.

Автоматизированные системы управления тикетами и заявками помогают планировать технологические окна и привлекать нужных специалистов в соответствующие временные промежутки, без потери данных в процессе. Это важно, потому что изменения в продуктивных бизнес-системах влияют на работу компании в целом».

Роман Коваленко, Ведущий специалист по анализу безопасности «Группы Астры»: «Специфика ОС — все актуальные уязвимости для ОС нам известны, поэтому сканеры не используются для управления уязвимостями непосредственно в продукте ОС. Сканируют ОС на уязвимости клиенты и внутренние команды пентестеров продуктов Группы. По результатам можно выявить проблемы в интеграции с вендорами VM-решений (в том числе проблемные места в OVAL-описаниях)».

Ведущий специалист по анализу безопасности Роман Коваленко пояснил, что вся информация об уязвимостях стекается в тикет-систему и должна централизованно обрабатываться в выбранной или разработанной VM-платформе, соответствующей внутренним требованиям.

«Кейсы из багбаунти, а также все запросы по уязвимостям попадают в тикет-систему. Для качественного мониторинга, агрегации и обработки информации об уязвимостях необходим единый «центр» — специализированная VM-платформа, которую необходимо выбирать, основываясь на специфике своего продукта, а в некоторых случаях и разрабатывать, основываясь на собственных требованиях к этой системе с учётом специфики процессов управления уязвимостями в организации. При этом, разумеется, платформа должна принимать данные из разных источников, быть интегрирована с используемой тикет-системой для получения актуальных статусов, а также предоставлять удобную визуализацию и, возможно, интерфейсы для использования актуальной информации об уязвимостях другим автоматизированным системам».

По каким критериям оценивают риски уязвимостей с учётом вероятности эксплуатации и бизнес-ценности активов?

Руслан Рахметов, СЕО Security Vision: «Риски эксплуатации уязвимостей можно обрабатывать в соответствии с правилами риск-менеджмента, которые включают несколько вариантов:

Принятие — взвешенное и согласованное принятие риска эксплуатации определенной уязвимости;

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

Передача — использование киберстрахования или переход на облачные сервисы;

Избежание — удаление уязвимого софта, отключение уязвимых компонент, вывод уязвимых активов из эксплуатации».

Генеральный директор компании Security Vision пояснил, что при выборе меры реагирования нужно учитывать характеристики актива, свойства уязвимости, вектор её эксплуатации и значимость ИТ-ресурса для бизнеса. Также он отметил возможность использования логики деревьев решений для оценки степени риска и сроков обработки.

«Оценивать опасность уязвимости и срок её устранения можно с использованием логики деревьев принятия решений, которые позволяют учитывать декомпозированный вектор CVSS (например, наличие эксплойта и эксплуатируемость уязвимости по сети), влияние уязвимости на свойства безопасности актива (целостность, конфиденциальность, доступность), а также критичность актива и требования, предъявляемые к целостности, конфиденциальности, доступности информации, которая на нём обрабатывается. Например, если «CVSS>=7″ и критичность актива=»Высокая», то срок устранения уязвимости = 12 часов, а если «4<=CVSS<7″ и критичность актива=»Средняя» то срок устранения = 96 часов».

Владимир Иванов, CEO ScanFactory: «В правильной картине мира этап приоритизации включает в себя анализ критичности отдельно взятого актива, наличие публичного эксплойта и CVSS-метрики, а также отсев false positive».

Владимир Иванов подчеркнул, что ключевым фактором является возможность lateral movement — перехода из одного сегмента в другой. Это требует анализа сетевых связей и построения пути потенциальной атаки.

«В первую очередь необходимо патчить уязвимости, которые позволяют выйти из одного сетевого сегмента в другой, и таким образом пробраться до бизнес-критичных хостов. Для этого, на этапе приоритизации важно анализировать расширение поверхности атаки (lateral movement) при эксплуатации того или иного хоста, путём анализа доступных сетевых интерфейсов».

Никита Котиков, руководитель направления верификации уязвимостей, компания CICADA8: «В соответствии со стандартом CVSS уязвимость имеет конкретную оценку и уровень риска».

Руководитель направления верификации уязвимостей компании CICADA8 Никита Котиков уточнил, что числовое значение CVSS — лишь отправная точка. Он отметил, что анализ контекста, архитектуры, доступности PoC и экспертное мнение часто снижают фактическую значимость уязвимости.

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

Вадим Матвиенко, руководитель лаборатории исследований кибербезопасности аналитического центра кибербезопасности «Газинформсервиса»:

«Сегодня организации ежедневно сталкиваются с десятками, а иногда и сотнями новых уязвимостей в своих ИТ-системах».

Руководитель лаборатории исследований кибербезопасности аналитического центра «Газинформсервис» пояснил, что CVSS как метод оценки устарел, так как игнорирует бизнес-аспекты. Он подчеркнул необходимость оценки вероятности эксплуатации и ценности актива с учётом рисков и ресурсов.

«Традиционный метод оценки с помощью CVSS (Common Vulnerability Scoring System), который измеряет техническую тяжесть уязвимости по шкале от 0 до 10, устарел. Эта система не учитывает важные аспекты:

Где находится уязвимый актив?

Насколько он важен для бизнеса?

Используют ли эту уязвимость в реальных атаках?

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

Роман Коваленко, Ведущий специалист по анализу безопасности «Группы Астры»: «Что касается ОС, риски уязвимостей оцениваются исходя из ПА на ОС. Поскольку почти все механизмы защиты Астры могут быть отключены только на уровне ядра ОС либо ВЦ администратором системы, то самыми опасными являются уязвимости LPE вкупе с RCE (в первую очередь уязвимости ядра и среди них в частности уязвимости сетевого стека ядра)».

Ведущий специалист по анализу безопасности «Группы Астры» отметил, что помимо класса уязвимости в оценке учитываются вероятность её эксплуатации, наличие эксплойта, упоминания в публичных источниках, а также способность механизмов защиты ОС противостоять атаке.

«На второе место могут быть поставлены уязвимости в сетевых и системных сервисах, функционирующих от имени пользователя (на высоком уровне целостности, в случае МКЦ). При этом, наряду с отнесением уязвимости к указанным классам, всегда оценивается вероятность успешной эксплуатации той или иной уязвимости — наличие в публичном доступе эксплойта, а также информация в СМИ об эксплуатациях уязвимости, являются безусловным критерием необходимости закрытия уязвимости в приоритетном порядке. Такие уязвимости достаточно часто называют трендовыми. Кроме того, одним из неотъемлемых критериев оценки возможных последствий от эксплуатации той или иной уязвимости является способность СЗИ ОС Астра Linux противостоять этой уязвимости».

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

Руслан Рахметов, СЕО Security Vision: «Приоритизация может включать в себя оценку опасности уязвимости по системе CVSS (предпочтение стоит отдавать новой версии CVSS v4, в которой появились дополнительные метрики), оценку уровня критичности уязвимостей по методике ФСТЭК России, оценку вероятности эксплуатации уязвимости по моделям EPSS и SSVC».

Эксперт добавил, что на приоритизацию влияет популярность уязвимостей у злоумышленников, наличие их в перечнях ФСТЭК, CISA и в аналитике вендоров. Кроме того, он подчеркнул, что даже высокая оценка по CVSS не всегда означает релевантность — требуется оценка на предмет эксплуатации в конкретной инфраструктуре с использованием pentest-функций или ручного анализа.

«Следует также учитывать и популярность определённых уязвимостей среди атакующих — для этого можно использовать перечни самых распространённых уязвимостей от ФСТЭК России (наиболее опасные уязвимости) и от CISA (Known Exploited Vulnerabilities Catalog). Кроме того, некоторые ИБ-вендоры составляют свои списки наиболее опасных уязвимостей на основе собственной экспертизы. При этом не всякая уязвимость даже с высоким CVSS-рейтингом может быть реально проэксплуатирована в текущей конфигурации корпоративной инфраструктуры — для уточнения перечня действительно актуальных уязвимостей следует проверять возможность эксплуатации конкретной уязвимости в контролируемой манере с помощью функционала Pentest-проверок в VM-системе. Кроме того, можно проверять реальную эксплуатируемость выявленных уязвимостей в ручном режиме силами команды Red Team или с привлечением внешних пентестеров».

Владимир Иванов, CEO ScanFactory: «Процесс организовывается из отдельных шагов, в первую очередь это отсев false positive результатов, например, с применением AI; и последующим этапом проводить ручную верификацию и приоритизацию».

Владимир Иванов уточнил, что автоматизация применяется на первом этапе для устранения ложных срабатываний, а далее задействуется экспертный подход.

«И последующим этапом проводить ручную верификацию и приоритизацию».

Никита Котиков, руководитель направления верификации уязвимостей, компания CICADA8: «Несмотря на существенный прогресс технологий искусственного интеллекта и автоматизации, порядка 35% уязвимостей внешнего периметра требуют экспертной оценки (IBM Cost of a Data Breach Report, 2024). Это связано, в первую очередь, с особенностями интерпретации контекста с точки зрения бизнеса и специфичными многоуровневыми уязвимостями».

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

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

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

Вадим Матвиенко, руководитель лаборатории исследований кибербезопасности аналитического центра кибербезопасности «Газинформсервиса»: «Автоматизация и ручной анализ помогают находить баланс между скоростью и точностью при работе с уязвимостями. Автоматизированные инструменты лучше подходят для первичной оценки».

Вадим Матвиенко отметил, что на автоматическом этапе важна агрегация и сортировка по приоритету на основе CVSS, EPSS и стоимости актива. Он добавил, что финальную корректировку оценок и действий должен выполнять специалист.

«В фазе автоматизированного режима важно собрать все данные от сканеров и расставить приоритеты. Для этого можно использовать CVSS, EPSS и стоимость актива. Автоматизация помогает определить приоритеты, а после первичной оценки с помощью автоматических средств специалист проверяет и корректирует их при необходимости.
Специалист может перепроверить дополнительные данные, например, есть ли активные попытки эксплуатации в вашей отрасли, существует ли PoC-эксплойт, давно ли он выпущен и другие».

Роман Коваленко, Ведущий специалист по анализу безопасности «Группы Астры»: «С учетом неуклонного роста числа уязвимостей ПО всё больший приоритет отдаётся автоматизированным методам не только сбора, хранения, проведения первичного анализа поступающей из различных источников информации об уязвимостях, но и оценке их реальных уровней критичности и формированию рекомендаций по их устранению».

Ведущий специалист Роман Коваленко подчеркнул, что автоматизация критична для массового анализа, но для уязвимостей высокого приоритета и компонентов с максимальной экспозицией необходим ручной триаж. Он пояснил, что только ручной подход позволяет учесть архитектурные особенности, применимость PoC и действенность предлагаемых средств защиты.

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

Ручной анализ также необходим для верификации предлагаемых способов предотвращения или минимизации последствий эксплуатации уязвимости, в том числе за счёт применения СЗИ. Это в том числе позволяет выявлять слабые стороны текущих механизмов защиты и предлагать пути их модернизации и/или развития.

То же самое касается и вопросов проверки применимости появляющихся PoC/эксплойтов для дальнейшей приоритизации уязвимостей. Особенно если речь идёт про системное ПО. Автоматизировать данную задачу в полном объёме практически невозможно, поэтому при выстраивании полноценного процесса управления уязвимостями для этих целей сразу стоит отдавать приоритет ручному триажу, как правило, с привлечением высококвалифицированных специалистов».

Какие интеграции с CI/CD-пайплайнами и оркестраторами ускоряют развёртывание патчей и конфигурационных правок?

Руслан Рахметов, СЕО Security Vision: «Выявление ошибок на наиболее ранних этапах проектирования и разработки ПО — ключевое условие планомерного повышения качества кода в рамках процесса безопасной разработки ПО. В случае, если компания занимается внутренней разработкой ПО, важно переходить к практикам SSDLC, DevSecOps и CI/CD/CS-пайплайнам, в которых учтено управление уязвимостями, а также использовать анализаторы кода (SAST, DAST, IAST, BAST) и решения для тестирования безопасности API (API Security Testing)».

Руслан Рахметов подчеркнул важность интеграции SCA, SBOM, OSA и подходов Secure by Design на уровне пайплайна, чтобы эффективно отслеживать риски, связанные с компонентами и зависимостями. Он добавил, что использование справочников MITRE и OWASP помогает разработчикам избежать типовых ошибок и строить систему с безопасностью по умолчанию.

«Формирование спецификаций SBOM, применение инструментов анализа состава ПО (SCA, Software Composition Analysis) и анализа компонентов с открытым исходным кодом (OSA, Open Source Analysis) поможет в работе с рисками атак на цепочки поставок. Кроме того, важно использовать справочные сведения о наиболее опасных ошибках при разработке ПО (например, от MITRE и от OWASP), а также руководствоваться подходами Secure by Design (использование ИБ-практик при разработке продуктов), Secure by Default (использование безопасных конфигураций по умолчанию), Secure by Demand (критерии, по которым заказчики могут оценить надёжность вендора, включая использование им практик SSDLC, предоставление спецификации SBOM на разрабатываемый софт, его политику раскрытия информации об уязвимостях, наличие roadmap по повышению безопасности разработки)».

Вадим Матвиенко, руководитель лаборатории исследований кибербезопасности аналитического центра кибербезопасности «Газинформсервиса»: «DevOps традиционно автоматизирует поставку изменений с помощью CI/CD для улучшения бизнес-функций в программном обеспечении».

Вадим Матвиенко отметил, что современные пайплайны можно использовать и для автоматического управления патчами, обновлениями и безопасными конфигурациями. Он акцентировал внимание на необходимости интеграции безопасности в каждую стадию CI/CD для обеспечения прозрачности, масштабируемости и соответствия требованиям.

«Однако CI/CD также позволяет автоматизировать обновление систем для обеспечения информационной безопасности и управления конфигурациями.

Безопасность необходимо интегрировать с быстрой доставкой. Внедрение автоматизации патчей и конфигурационных изменений в CI/CD и оркестрационные платформы — это не просто модный тренд, а жизненная необходимость. Только так можно обеспечить предсказуемое время реакции, масштабируемость безопасности и прозрачность соответствия требованиям».

Как обеспечить сквозную прослеживаемость от обнаружения уязвимости до подтверждения её исправления в продакшен-среде?

Никита Котиков, руководитель направления верификации уязвимостей, компания CICADA8: «Для достижения сквозной прослеживаемости на всех этапах — от идентификации до фиксации — применяется комплекс инструментов:

• Статический анализ кода (SAST) — выявление уязвимостей на этапе написания кода посредством проверки исходного кода без необходимости запуска.
• Динамическое тестирование (DAST) — тестирование работающего приложения для обнаружения рисков, проявляющихся в режиме реального времени.
• Анализ компонентов (SCA) — сканирование сторонних библиотек и зависимостей на наличие известных уязвимостей».

Никита Котиков отметил, что интеграция этих методов в CI/CD-конвейер обеспечивает автоматизацию контроля, сокращает «окно экспонирования» и создаёт культуру, в которой каждая уязвимость рассматривается как инцидент, требующий отслеживания и анализа. Эксперт подчеркнул, что ключ к эффективности — в прозрачной системе контроля статусов, приоритизации, тестирования и подтверждения результатов.

«Интеграция этих методов в CI/CD-конвейер позволяет автоматизировать контроль безопасности, минимизировать „окно экспонирования“ угроз и гарантировать прозрачность на каждом этапе — от разработки до релиза.

Такой подход не только снижает риски, но и формирует культуру безопасности, где каждая уязвимость рассматривается как инцидент, требующий документирования, приоритизации и анализа.

Эффективность процесса достигается посредством реализации чёткого контроля состояния на всех этапах жизненного цикла:

• Контроль состояния и статусов выявленных угроз.
• Приоритизация задач на основе экспертной оценки и формирования релевантного уровня угрозы.
• Контроль исправления и SLA.
• Тестирование исправлений в реальных условиях.

Такой подход превращает фрагментированные действия в единый и управляемый процесс, где каждый шаг логически связан. Это снижает риски эксплуатации уязвимостей в „сыром“ коде и формирует культуру проактивного подхода к безопасности, а не реагирования на инциденты по факту их возникновения».

Вадим Матвиенко, руководитель лаборатории исследований кибербезопасности аналитического центра кибербезопасности «Газинформсервиса»: «Отслеживание жизненного цикла уязвимости от обнаружения до устранения в продакшене не менее важно, чем само обнаружение. Сквозная прослеживаемость объединяет технические процессы, автоматизацию и контроль на всех этапах: от поиска уязвимостей до исправления в продуктивных системах».

Вадим Матвиенко подчеркнул, что для полной прослеживаемости следует выстраивать чёткую последовательность действий — от фиксации до верификации и аудита, включая не только техническое исправление, но и административные процессы.

«Для этого нужно организовать шесть ключевых этапов:

• Обнаружение уязвимости.
• Оценка и приоритизация.
• Создание задачи на устранение.
• Внедрение исправления или обходного решения.
• Подтверждение исправления в тестовой и продакшен-среде.
• Закрытие инцидента с метками соответствия и аудита».

Екатерина Буденная, Руководитель отдела анализа защищённости «Группы Астры»:

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

Екатерина Буденная объяснила, что все выявленные уязвимости должны проходить через единую систему, где они нормализуются, получают приоритет и отслеживаются до полного закрытия. Для этого используются платформы ASOC, которые синхронизируются с баг-трекингом, автоматизируют контроль и помогают формировать отчётность.

«Все выявленные недостатки безопасности — будь то автоматизированные системы анализа защищённости приложений, код-ревью, тестирование ФБ, программы bug-bounty и другие, после верификации и оценки уровня критичности должны быть зафиксированы как задачи на исправление в едином пространстве.

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

Для решения этих проблем целесообразно применение систем класса Application Security Orchestration and Correlation (ASOC), объединяющих большинство используемых инструментов в единую платформу. Эти решения позволяют устранить дублирование сведений путём дедупликации и корреляции результатов, поступивших из различных источников, обеспечивая более качественные результаты для дальнейшего триажа уязвимостей.

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

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

Какие метрики и KPI применяют для контроля эффективности, скорости и качества процессов управления уязвимостями?

Руслан Рахметов, СЕО Security Vision: «Можно применять метрики, отражающие количество уязвимостей в различных статусах (новая, в работе, устранена), скорость обработки уязвимостей (временной период от момента обнаружения уязвимости сканером до момента устранения), скорость закрытия окна возможностей для атакующих (временной период от момента публикации уязвимости в публичных реестрах до момента устранения)».

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

«Можно оценивать соотношение уязвимостей, закрытых вручную и автоматически (например, за счёт механизма автопатчинга), а также соотношение числа уязвимостей, по которым приняты разные решения по обработке рисков их эксплуатации (принятие / снижение / передача / избежание). Кроме того, в системах VM применяются различные встроенные оценки совокупного уровня уязвимости инфраструктуры и отдельных информационных систем в зависимости от интегрального уровня критичности уязвимостей».

Владимир Иванов, CEO ScanFactory: «Каждый отдел ИБ выбирает метрики в соответствии со стратегией ИБ в организации: это может быть скорость по исправлению critical-угроз на периметре, объём запатченных хостов, время реакции на тикет и так далее».

Владимир Иванов указал, что ключевой критерий для бизнеса — это отсутствие доступа к инфраструктуре извне. Он добавил, что некачественные инструменты мониторинга создают нагрузку и имитацию работы без реальной пользы.

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

Отдельно стоит отметить, что применение слабых решений по детектированию угроз вредит бизнесу: имитируется VM-деятельность, процесс строится с белыми пятнами, излишняя нагрузка на админов, и, как следствие — меньше уважения к отделу ИБ».

Вадим Матвиенко, руководитель лаборатории исследований кибербезопасности аналитического центра кибербезопасности «Газинформсервиса»: «Основные категории метрик:

1. Скорость реагирования на риски

• MTTR (Mean Time to Remediate) — среднее время от обнаружения уязвимости до её закрытия.
• MTTT (Mean Time to Triage) — время от обнаружения до классификации.
• Time to Patch in Production — время на внедрение патча в рабочую среду.

2. Эффективность устранения уязвимостей

• Fix Rate — доля закрытых уязвимостей за определённый период.
• SLA Compliance Rate — процент устранённых уязвимостей в соответствии с установленным SLA.
• Повторные инциденты — доля уязвимостей, которые появились снова после устранения».

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

«3. Качество процесса и контроль

False Positive Rate — доля ложноположительных находок, которые были исключены вручную.

Verification Rate — процент уязвимостей, исправленных и подтверждённых повторным сканированием.

Traceability Coverage — доля уязвимостей с полной отслеживаемостью от обнаружения до закрытия.

4. Бизнес-контекст и приоритизация

Уязвимости на критичных активах — оценка угрозы для бизнес-сервисов.

Risk Reduction Score — динамика снижения совокупного риска (например, на базе CVSS × актив × EPSS)».

Екатерина Буденная, Руководитель отдела анализа защищённости «Группы Астры»: «Метрики играют ключевую роль в выявлении проблемных зон существующих процессов, а также позволяют отслеживать динамику зрелости информационной безопасности компании».

Екатерина Буденная отметила, что управление уязвимостями требует оценки не только времени реакции, но и накопленного технического долга, качества покрытия кода и структуры критичности. Она подчеркнула, что важен и источник данных об уязвимости.

«Применительно к управлению уязвимостями целесообразно учитывать следующие ключевые показатели эффективности:

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

Среднее время триажа — своевременный анализ и классификация угроз позволяет эффективнее ранжировать приоритетность устранения недостатков.

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

Технический долг неразобранных уязвимостей — применяется преимущественно к результатам автоматизированного сканирования и характеризуется соотношением необработанных ошибок безопасности к общему количеству.

Технический долг устранения — характеризуется количеством проверенных и подтверждённых дефектов, которые выявлены, однако пока не ликвидированы.

Покрытие кода — отражает долю программного кода, подлежащего проверке, свидетельствует о полноте охвата анализа.

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

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

Источник информации уязвимости — важный маркер, откуда мы получаем информацию: внутренние исследования, системы автоматической проверки, внешние каналы связи».

Как наладить координацию между командами безопасности, разработки и эксплуатации при управлении уязвимостями?

Вадим Матвиенко, руководитель лаборатории исследований кибербезопасности аналитического центра кибербезопасности «Газинформсервиса»: «В любой современной компании управление уязвимостями — это задача не одного подразделения, а всего коллектива. В этот процесс могут быть вовлечены:

• специалисты по информационной безопасности (Security),
• разработчики (Dev),
• инженеры, отвечающие за эксплуатацию и поддержку инфраструктуры (Ops)».

Вадим Матвиенко отметил, что при большом количестве участников и систем без централизованной координации возникают дублирование, просроченные тикеты и необработанные уязвимости. Эксперт подчеркнул, что координация должна опираться на принципы DevSecOps, регламентировать зоны ответственности, использовать общие инструменты и предусматривать контроль за верификацией и отчетностью.

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

Решение — в выстраивании координации, чётких ролей и процессов, которые становятся частью культуры DevSecOps.

Когда есть разобщённость команд, то это может привести к уязвимостям на продуктивных системах. Например:

• Команда ИБ сообщает об уязвимости, но разработчики узнают об этом только через неделю.
• DevOps внедряет патч, но не знает, прошёл ли он повторную проверку безопасности.
• Системные администраторы не видят связи между тикетом и реальной угрозой.
• Отчётность по устранению уязвимостей отсутствует, SLA не соблюдаются.

Для решения этих проблем необходимо принять следующие меры:

• Определить роли и зоны ответственности. Все участники процесса должны чётко понимать, кто за что отвечает.
• Использовать общие инструменты и единую систему тикетов. Это позволит всем видеть одну и ту же информацию и сделает процесс прозрачным.
• Встроить безопасность в CI/CD. На ранних этапах выявлять и устранять проблемы.
• Реализовать процесс верификации устранения уязвимостей.
• Проводить регулярную синхронизацию между командами. Это поможет улучшить взаимодействие и повысить эффективность процесса».

Екатерина Буденная, Руководитель отдела анализа защищённости «Группы Астры»: «Необходимо создать прозрачный последовательный процесс взаимодействия. Процесс взаимодействия должен быть документально закреплён на уровне корпоративных стандартов и внутренних инструкций».

Екатерина Буденная пояснила, что координация невозможна без формализованных ролей, понятной среды для совместной работы и организованной обратной связи. Она отметила важность сбора проблемных кейсов по итогам релизов, а также ведения централизованного учёта уязвимостей.

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

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

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

Какие роли и компетенции необходимы для управления уязвимостями и как поддерживать их развитие?

Владимир Иванов, CEO ScanFactory: «Очень важно поддерживать уровень offensive безопасности у команды redteam, которая занимается поиском актуальных угроз, поскольку это влияет на понимание той работы, которую делает команда».

Владимир Иванов отметил, что redteam-специалисты должны уметь самостоятельно оценивать риск уязвимости как для инфраструктуры, так и для приложений, а также грамотно взаимодействовать с IT-администраторами. Он подчеркнул важность постоянного развития через тренинги и сертификации.

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

Вадим Матвиенко, руководитель лаборатории исследований кибербезопасности аналитического центра кибербезопасности «Газинформсервиса»:

«Управление уязвимостями — это комплексная дисциплина, где безопасность, разработка, эксплуатация и управление пересекаются, создавая эффективные решения. Эти решения позволяют не только находить уязвимости, но и устранять их быстро, надёжно и без ущерба для бизнеса».

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

«Кто участвует в управлении уязвимостями?

Аналитик ИБ или инженер по уязвимостям

Задачи:

• Анализ и приоритизация уязвимостей (CVSS, EPSS, TI).
• Корреляция уязвимостей с активами и бизнес-контекстом.
• Инициация тикетов и отслеживание устранения.

Ключевые навыки:

• Знание сканеров и платформ управления уязвимостями.
• Понимание модели угроз.

DevSecOps—инженер

Задачи:

• Обнаружение и устранение уязвимостей на этапе CI/CD.
• Внедрение инструментов для безопасной разработки.
• Настройка безопасности в инструментах разработки.

Ключевые навыки:

• Работа с GitLab/GitHub Actions, Jenkins.
• Использование инструментов для автоматизированных проверок кода, конфигураций и зависимостей.
• Знание policy-as-code и Kubernetes security.

Системный администратор или инженер эксплуатации (Ops)

Задачи:

• Внедрение патчей и конфигурационных правок.
• Мониторинг исправлений и подтверждение их устранения.

Ключевые навыки:

• Знание Ansible, Puppet, Terraform.
• Управление конфигурацией и инфраструктурой как кодом.
• Развёртывание безопасных шаблонов ОС и middleware.

Владелец активов или бизнес-владелец ИТ-системы

Задачи:

• Оценка критичности уязвимости с точки зрения бизнес-рисков.
• Принятие решений о срочности устранения или исключениях.
• Участие в процессе приоритизации.

Ключевые навыки:

• Понимание бизнес-процессов и зависимостей от ИТ-сервисов.
• Навыки оценки рисков и управления изменениями.

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

Задачи:

• Организация процесса.
• Мониторинг KPI, подготовка отчётности и аудит.
• Согласование с требованиями.

Ключевые навыки:

• Управление процессами и SLA.
• Знание нормативных требований.
• Навыки коммуникации между Dev, Sec и Ops.

Для поддержания и развития компетенций рекомендуется реализовать следующие меры:

• Внутренние тренинги и обмен знаниями между подразделениями.
• Практические сценарии (в виде лабораторных работ или CTF).
• Внешние сертификации и курсы.
• Использование метрик для оценки прогресса».

Екатерина Буденная, Руководитель отдела анализа защищённости «Группы Астры»: «Комплексная информационная безопасность предполагает привлечение специалистов различного профиля, каждый из которых играет определённую роль в данном процессе».

Екатерина Буденная выделила ключевые роли: менеджер ИБ, AppSec-специалист, DevSecOps, аналитик, разработчики. Она отметила, что развитие сотрудников должно быть системным и сопровождаться менторством, участием в конференциях, обучением и расширением зоны ответственности.

«Менеджер информационной безопасности. В его обязанности входит выстраивание эффективных процессов мониторинга и управления, контролирует соблюдение нормативных требований регулирующих органов и стандартов. Координирует деятельность отделов и контролирует выполнение установленных процедур.

AppSec. В зону ответственности входит проведение тестирования на проникновение и оценка наличия потенциальных уязвимостей и возможных путей их эксплуатации. Подготавливает рекомендации по снижению риска атак и обеспечивает оптимизацию защитных механизмов.

DevSecOps. Отвечает за встройку инструментария в полный цикл разработки программного обеспечения (SDLC). Настраивает CI/CD-пайплайны, внедряет автоматические проверки безопасности (AST), занимается разработкой и совершенствованием методов автоматического обнаружения уязвимостей, формирует требования к правилам автоматизированных проверок безопасности.

Аналитик информационной безопасности. Выполняет глубокий технический анализ выявленных уязвимостей, оценивает степень их актуальности и потенциального воздействия на продукты компании. Формулирует технические задания на устранение дефектов безопасности, осуществляет разработку контрмер и ведёт работу по фиксации и оценке уязвимых мест. Совместно с DevSecOps-специалистами проводит аналитику ложных срабатываний сканеров безопасности (AST), обеспечивая повышение точности работы инструментов и снижение нагрузки на другие подразделения.

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

Для повышения уровня зрелости компании необходима целенаправленная работа по развитию профессиональных компетенций: определить необходимые компетенции для достижения целей компании. Составить индивидуальные планы развития сотрудников. Организовать менторство опытными специалистами над менее квалифицированными коллегами. Поддерживать участие сотрудников в отраслевых конференциях. Предоставлять возможность повышения квалификации за счёт внешнего обучения. Мотивировать сотрудников. С ростом компетенций расширять зону их ответственности».

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

Руслан Рахметов, СЕО Security Vision: «Один из набирающих популярность подходов — создание Vulnerability Operations Center (VOC), т. е. операционного центра по обработке уязвимостей, по аналогии с SOC-центрами. Создание VOC подразумевает переход от чисто технического восприятия уязвимостей к риск-ориентированному управлению уязвимостями с непрерывным обнаружением уязвимостей, обогащением данных по ним, с оценкой влияния уязвимостей на бизнес-процессы и дальнейшей приоритизацией устранения уязвимостей на основе скоринга рисков их эксплуатации».

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

«Выделенный VOC-центр позволяет поднять приоритет процесса управления уязвимостями на стратегический уровень в компании. Среди трендовых технологий можно отметить машинное обучение и системы ИИ: так, используемая в продуктах Security Vision технология ИИ позволяет эффективно выявлять в сети неучтённые устройства и связи между ними, а также классифицировать активы, например, на основе анализа накопленных исторических данных о сетевых коммуникациях между различными элементами инфраструктуры.

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

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

Никита Котиков, руководитель направления верификации уязвимостей, компания CICADA8:

«Тем не менее, в последние годы набирает силу тренд на интеграцию алгоритмов машинного обучения в процессы управления уязвимостями».

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

«Современные технологии позволяют достаточно точно прогнозировать актуальность и релевантность угрозы, проводить анализ архитектуры систем и выстраивать приоритеты.

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

Вадим Матвиенко, руководитель лаборатории исследований кибербезопасности аналитического центра кибербезопасности «Газинформсервиса»: «Машинное обучение и искусственный интеллект становятся всё более популярными. Системы на их основе будут предсказывать новые уязвимости и угрозы, анализируя большие объёмы данных из ИТ-систем и баз уязвимостей».

Вадим Матвиенко добавил, что ИИ будет не только предсказывать риски, но и активно использоваться в сканерах и автоматизированных системах, которые охватывают все ИТ-ресурсы организации.

«Искусственный интеллект продолжит активно применяться в сканерах безопасности. Автоматизированные платформы охватят все информационные ресурсы компании, интегрируясь с ними и проводя перекрёстные проверки. Это позволит выявлять скрытые ИТ-зоны и своевременно информировать о них, тем самым понижая риски».

Екатерина Буденная, Руководитель отдела анализа защищённости «Группы Астры»: «Как разработчики защищённой ОС, мы активно участвуем в трансформации подходов безопасной разработки в целом и к управлению уязвимостями в частности».

Екатерина Буденная подчеркнула, что управление уязвимостями всё больше уходит от разового сканирования к системному управлению экспозицией, где используются VEX, SBOM, CTEM и автоматизация первичного анализа с помощью ИИ.

«Речь идёт уже не просто об автоматизации сканирования, а о фундаментальных изменениях в процессной составляющей, цикле безопасной разработки ПО и управлении жизненным циклом уязвимостей. Разумеется, как вендор, мы обязаны предоставлять точную информацию о составе компонентов (SBOM), одним из путей развития и расширения этого направления также является поддержка VEX для понимания реального воздействия и эффективного управления уязвимостями, популярность которых сейчас растёт в индустрии, в том числе у зарубежных компаний.

Помимо этого, также активно набирает популярность подход CTEM (Continuous Threat Exposure Management), который по сути является эволюцией привычного нам VM, и помогает организациям системно оценивать реальную экспозицию киберугроз для продукта или конкретной инфраструктуры, приоритизировать устранение тех уязвимостей, которые действительно могут быть эксплуатированы нарушителем и делать всё это в рамках непрерывного цикла безопасной разработки.

Помимо этого, нельзя не упомянуть и о развитии AI/ML-подходов в области ИБ, в частности применение данных подходов для триажа и первичного анализа уязвимостей. Не за горами автоматический триаж для приоритизации с учётом контекста использования, графа компонентов и путей эксплуатации в целом, а также сопоставление результатов различных практик AppSec между собой».