9 сентября 2025 г.

Продолжение. Начало здесь и здесь

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

Всегда готов!

Ирина Назаренко, директор «Инферит ОС», подтверждает, что сегодня информационная безопасность является приоритетом № 1: «Именно поэтому мы выстроили эффективную систему мониторинга и оперативного устранения уязвимостей, включая угрозы „нулевого дня“. Критические уязвимости устраняются в течение 1-3 рабочих дней с момента обнаружения. Все исправления оперативно доставляются пользователям через систему автоматических обновлений. За последний год мы устранили около 100 уязвимостей разного уровня критичности, при этом в 93% случаев уложились в заявленные сроки».

По словам Алексея Смирнова, председателя совета директоров компании «Базальт СПО», российские разработчики систематически проводят проверку исходного кода на уязвимости: «Создан консорциум на базе Института системного программирования РАН, участниками которого мы являемся, где распределяется работа между участниками по проверке различных фрагментов кода. И она уже не только относится к ядру Linux, но и к ряду других компонентов. Это очень важная кооперация, по духу построенная на принципах свободных лицензий, и эти уязвимости не только исправляются локально, но и исправления отправляются в международный апстрим, где их принимают. Есть требования ФСТЭК по безопасности, в частности, требования по безопасной разработке, и, конечно, серьёзный разработчик должен их учитывать».

Реагирование на уязвимости у российских разработчиков, особенно среди ведущих вендоров, поставлено на системную основу, — это утверждает Алексей Киселев, руководитель разработки ОС РОСА: «У нас в РОСА работает отдел ИБ, который регулярно мониторит базы данных уязвимостей, включая БДУ ФСТЭК и использует собственные сканеры для анализа пакетов. При выявлении уязвимостей задачи незамедлительно передаются разработчикам. Критичные уязвимости, включая уязвимости нулевого дня, стараемся закрывать максимально быстро, иногда в течение суток. Еженедельно выходят обновления, включающие патчи безопасности. Это касается как стабильной версии РОСА 2021.1, так и будущей, которая будет называться РОСА-13».

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

«Что касается уязвимостей нулевого дня, — продолжает эксперт, — то здесь подходы примерно такие же: как только уязвимость выявлена, мы оперативно информируем заказчиков и даём рекомендации по её предотвращению. По срокам реагирования — всё индивидуально. Например, есть пакеты, которые не зависят ни от каких других, и от которых не зависят иные пакеты. В таких случаях пересборка занимает считанные часы, далее идут тестирование и выпуск обновления, обычно в течение 3–5 дней. Однако существуют пакеты, используемые в составе других программ, либо от них зависит сборка других компонентов. Тогда необходимо пересобрать всё с учётом изменений, — что занимает значительно больше времени. Если речь идёт о сертифицированной версии, требуется также проведение лабораторных испытаний, что дополнительно увеличивает сроки. В таких случаях регламент предписывает выполнять работы как можно быстрее, но иногда единственным способом минимизировать риск эксплуатации уязвимости становится обходное решение — например, временное прекращение использования уязвимого пакета до выпуска обновления».

Михаил Геллерман, директор управления операционных систем «Группы Астра», указывает на ключевую роль ФСТЭК России в вопросах ИБ на уровне отечественных ОС: «Регулятор в зависимости от уровня критичности уязвимостей устанавливает сроки принятия мер по их устранению. В противном случае разработчик рискует сертификатом на программное обеспечение. А это, в свою очередь, закроет ему возможность поставлять продукт госзаказчикам, для которых важно, чтобы софт был сертифицированным. Для поиска угроз „нулевого дня“ мы, в числе прочих инструментов, используем QA-фаззинг. Этот метод тестирования ПО использует автоматические инструменты, которые вводят случайные или специально сгенерированные данные в программу для обнаружения ошибок, уязвимостей и сбоев».

Всем миром

Внутреннее тестирование перед выпуском в свет проводится для операционных систем, как и для любого ПО, — но какова практика российских разработчиков по части открытого тестирования их на предрелизном этапе? Привлекаются ли внешние ресурсы — ИТ сообщества, в частности — для организации таких испытаний?

«Тестирование бета-версий системы — это важный этап становления и развития продукта, — соглашается Ирина Назаренко. — Привлечение ИТ-сообщества помогает выявлять больше потенциальных проблем, чем внутренние скрининги. Например, до 29 октября у нас проходит открытое тестирование бета-версии ОС „МСВСфера“ версии 10, для которого мы разработали специальную методику оценки; участие могут принять все желающие. Бета-тесты не только позволяют выявить и исправить недостатки, но и предоставляют возможность частным разработчикам разного уровня проверить совместимость своих продуктов с системой. Многие из них впоследствии становятся нашими технологическими партнёрами».

По словам Алексея Киселева, практика открытого тестирования применяется активно: «Особенно в рамках проекта РОСА. У нас есть своё сообщество, которое участвует в тестировании предрелизных версий. Мы используем систему Bugzilla, где любой желающий может оставить баг-репорт. Эти отчёты обязательно обрабатываются. Open source предполагает отдачу в сообщество — и мы в этом плане придерживаемся прозрачной модели. Активная работа с пользователями, чатами, форумами, — всё это повышает качество конечного продукта. Потенциал здесь ещё не исчерпан: мы считаем, что нужно расширять коммуникацию с сообществом и вовлекать больше участников».

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

«Наши операционные системы публично доступны, — говорит Алексей Смирнов, — в том числе предрелизные: бета- и альфа-версии. Мы получаем обратную связь от сообщества на всех этапах, и это нам хорошо помогает в работе. При этом, естественно, у нас есть и регулярное тестирование: специальное подразделение, специальные инструменты, которые мы используем. Это и функциональное тестирование, тестирование безопасности, нагрузочное тестирование и многое другое».

По словам Михаила Геллермана, его компания реализует иной подход к тестированию своей ОС: «Обычно для заказчика важнее, чтобы ПО безотказно работало и обеспечивало защиту без необходимости предварительных исследований и тестирования. Не все готовы вкладывать в это ресурсы. Тем не менее, у компаний с высокими требованиями к устойчивости инфраструктуры и непрерывности бизнес-процессов действительно существуют практики активного и пассивного тестирования нового ПО в „песочнице“. Следует заметить, что тесты исключительно на стороне вендора не могут на 100% закрыть все сценарии заказчиков, как минимум у каждого — своя инфраструктура. Поэтому мы, конечно, вовлечены в испытания на стороне клиентов. Доля рынка Astra Linux среди российских ОС составляет 76%; это означает, что вместе с пользователями нашей системы мы можем покрыть максимальное количество сценариев, актуальных для отечественных компаний».

Процесс разработки в РЕД СОФТ включает открытое тестирование операционной системы на предрелизном этапе, — об этом говорит Рустам Рустамов: «Например, мы проводим бета-тестирование новых версий РЕД ОС среди специально сформированных фокус-групп пользователей. Участники получают ранний доступ к релизу и предоставляют обратную связь по критериям: функциональность, стабильность работы системы, удобство использования и качество интерфейса. Эти данные помогают выявить недостатки и внести необходимые улучшения перед официальным выпуском продукта. Привлечение внешних ресурсов позволяет РЕД СОФТ значительно повысить качество конечного программного решения».

Окончание следует


Источник: Максим Белоус, IT Channel News