Александр ЛЕОНОВ, ведущий эксперт рынка, автор телеграмм-канала «Управление Уязвимостями и прочее» рассказывает об эволюции Управления уязвимостями в России и перспективах отрасли. 

Под Управлением Уязвимостями (Vulnerability Management) понимают процесс детектирования и устранения уязвимостей программных и аппаратных средств. Как отдельное направление информационной безопасности Управление уязвимостями начало складываться во второй половине 1990-х. В 1998 году вышла первая версия Nessus, наиболее известного инфраструктурного сканера уязвимостей на сегодняшний день. Примерно в это же время появились компании, которые продолжают контролировать большую часть мирового рынка средств Управления уязвимостями. Компания Qualys была основана в 1999, Rapid7 в 2000, Tenable в 2002. Наиболее крупный российский вендор средств Управления уязвимостями, компания Positive Technologies была основана в 2002, а их первый продукт XSpider (тогда Spider) появился ещё раньше – первая версия в 1998, а в 2000 продукт стал публично доступным.

Мой путь в Vulnerability Management начался в 2009 году, когда после окончания университета я попал в компанию Positive Technologies. Я проработал там 6,5 лет. В основном разрабатывал скрипты детектирования мисконфигураций и уязвимостей Linux/Unix систем для MaxPatrol 8. Некоторое время занимался конкурентным анализом. После чего работал в крупных российских компаниях, выстраивая процесс Управления уязвимостями на практике.

Чем дальше, тем сложнее верится, что совсем недавно в России было возможно строить ИT/ИБ системы, используя западные решения. Более того, это было абсолютным мейнстримом. Как следствие, сотрудники российских компаний естественным образом развивались в высококлассных специалистов по продуктам Microsoft, Oracle, Cisco, Palo Alto Networks, AWS, и прочим. А в случае Управления уязвимостями, по продуктам Tenable, Qualys, Rapid7. В этом была своя прелесть. Если специалист использует те же решения, что и крупные компании во всём мире, его навыки также становятся востребованы в общемировом масштабе. А значит релокация туда, где лучше, выглядит как вполне себе план Б (а у кого-то и как план А). Минусом этого шла привязка к западным вендорам и их судьбе в России. Но что с ними могло сделаться?

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

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

Первая. Если в организации использовалось западное решение для детектирования уязвимостей, скорее всего его работа была нарушена отзывом лицензий и требовала восстановления. Часть организаций продолжили использовать западные решения по Управлению уязвимостями с помощью разного рода ухищрений. При этом общая эффективность таких западных решений снизилась из-за частичного перехода ИТ-инфраструктур организаций на отечественные программные и аппаратные средства, которые западными решениями не поддерживаются. Другая часть организаций форсировала переход на продукты отечественных вендоров средств Управления уязвимостями: Positive Technologies, «Алтэкс-Софт», «Эшелон», «Фродекс» и др. Также некоторые крупные российские компании стали разрабатывать решения детектирования уязвимостей для собственных нужд. Есть вероятность появления таких разработок на рынке.

Вторая. Для всех продетектированных уязвимостей в западных продуктах теперь требуется принимать решение: исправлять их установкой обновления с риском привнести недекларированные возможности или не исправлять, приняв риски эксплуатации уязвимости злоумышленниками. Российские регуляторы достаточно оперативно отреагировали на эту проблему, выпустив свои методические рекомендации. «Критерии для принятия решения по обновлению критичного ПО, не относящегося к open-source» НКЦКИ содержат алгоритм принятия решения о необходимости обновления западного ПО. «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» ФСТЭК описывает, каким образом можно получить общую оценку критичности уязвимости и выставить требования по оперативности исправления. «Методика тестирования обновлений безопасности программных, программно-аппаратных средств» ФСТЭК описывает, какими способами искать недекларированные возможности в обновлениях безопасности.

Скорейшая замена ИT-решений на отечественные (стабильные) может помочь избавиться от второй проблемы и вернуться к более простому и надёжному процессу Управления уязвимостями. Однако в этом вопросе более значима не позиция ИБ, а позиция регуляторов, бизнеса и ИT. Аврального отказа от продуктов, например, Microsoft или вендоров мейнстримных Linux дистрибутивов пока не наблюдается. Хотя и некоторое движение в сторону постепенного отказа от них, безусловно, присутствует. Позиция регуляторов достаточно умеренная и сводится к требованию контроля обновлений. Как минимум до 2025 года.

Однако переход на отечественные ИT-решения совсем не обязательно будет простым с точки зрения Управления уязвимостями. Есть сомнения в зрелости отечественных вендоров программных и аппаратных средств. Заводят ли они все уязвимости своих продуктов в БДУ ФСТЭК? Выпускают ли бюллетени безопасности? Если не будет идентификаторов уязвимостей и бюллетеней, значит, не будет адекватной поддержки в решениях по Управлению уязвимостями. Хотелось бы, чтобы регуляторы обращали на это внимание и выдвигали такие требования к сертифицированным решениям и решениям, находящимся в реестрах.

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

·       релоцироваться туда, где можно продолжать строить системы на западных решениях;

·       остаться и строить системы на тех решениях, которые остались/появились в РФ;

·       остаться, перестать строить системы и принять участие в копировании западных решений.

Релокация в другую страну всегда была достаточно рискованным мероприятием, а теперь и вовсе выглядит, как дорога в один конец. С другой стороны, остаться и развиваться в чём-то другом – это и потеря конкурентных преимуществ, и необходимость быстро учиться новому, и переход в новый локальный контекст. Опыт с Яндекс Клауд и Астра Линукс, безусловно, менее универсален, чем с AWS и RHEL. Это нужно осознать и принять.

Для себя я сформулировал три установки, которые выглядят полезными в сложившихся условиях, в том числе и для Управления уязвимостями.

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

Вторая. Фокусироваться на open-source проектах, в особенности на GNU/Linux. С одной стороны, мы во многом утратили или утратим в ближайшем будущем доступ к проприетарным западным решениям. Но вот доступ к open-source останется, этого у нас никто не отберёт. Несмотря на попытки ограничить возможности контрибьютить код и вести свои проекты, эффективных механизмов препятствовать этому также нет. Поэтому для российского специалиста активная самореализация в open-source проектах это логичный путь для приобретения навыков актуальных в общемировом масштабе. С другой стороны, open-source – это основа российского импортозамещения. Практически все российские ОС это Linux, отечественных ИT/ИБ продуктов без использования открытых библиотек также не бывает. Можно долго спорить на тему, оправдано ли называть отечественным то, что в основном разрабатывается где-то в Калифорнии. По моему мнению, это довольно скверно, но может быть в какой-то степени скомпенсировано вовлечённостью в эти проекты российских специалистов как со стороны разработки, так и со стороны использования. Безусловно, история успеха здесь – проект PostgreSQL. Если появятся эффективные центры компетенций по ключевым открытым компонентам, то, возможно, появятся и шансы «перевернуть игру», и уже на Западе будут переживать по поводу российского влияния на open-source. А если не появятся, хотя бы несколько снизим свои риски в процессе.

Третья. Относиться к российским коммерческим решениям с «презумпцией крутости». Если не доказано, что продукт полностью неработоспособен, и это явное мошенничество, считать российский продукт крутым. Российские ИT/ИБ-продукты действительно часто дороже и менее функциональны. Но критиковать их за это так же бессмысленно, как возмущаться тем, что за летом приходит зима. Наши вендоры зачастую стартуют с нуля, имея в сотни и тысячи раз меньше ресурсов, чем западные. У них нет возможности демпинговать и работать на перспективу, им нужно выживать и развиваться здесь и сейчас. И при этом они умудряются производить что-то сопоставимое с западными решениями. Это ли не чудо!

Жизнь, развивается, безусловно, занятно. Кто бы мог подумать ещё года 2 назад, что избавление от доминирования продуктов Microsoft станет ощутимо вырисовываться в нашей отдельно взятой стране. Что российские ИБ-вендоры начнут спешно реализовывать поддержку Linux серверов и Linux десктопов (!), потому что именно это теперь перспективная инфраструктура. А то, что десятки лет было стандартом де-факто в корпоративной среде, превратится в legacy, которое здесь и сейчас ещё поработает, но на горизонте 2025–2030 вряд ли от него хоть что-то ещё останется. 

Мне, как ИБ-специалисту с бэкграундом именно в *nix безопасности, наблюдать это, безусловно, отрадно. Хотя и гарантии реализации именно такого будущего вряд ли кто-то может дать. Поживём – увидим. А пока будем обеспечивать Управление уязвимостями российских организаций в тех обстоятельствах, которые сложились здесь и сейчас. 

Текст: Александр Леонов, независимый эксперт, автор телеграмм-канала «Управление Уязвимостями и прочее»

Материал также опубликован в печатной версии Национального банковского журнала (май 2023)