Российские разработчики ПО систематически пренебрегают требованиями в отношении сроков устранения уязвимостей в рамках стандартов ФСТЭК России. В ведомстве отмечают, что чрезмерно медленное реагирование на выявленные уязвимости в продуктах может привести к отзыву сертификатов, что негативно повлияет на процессы поставки софта государственному сектору, сообщает «Коммерсант».
Представители российского рынка программного обеспечения признают наличие подобного негативного тренда. Утверждается, что проблема возникла из-за увеличившегося спроса на продукцию российских вендоров и перегруженности всех уровней технической поддержки.
Кроме того, по мнению экспертов, задержка в реагировании на уязвимости часто связана с тем, что многие отечественные программные решения основаны на открытом коде. И таких проектах уязвимости зачастую устраняются не самими разработчиками, а сообществом.
По информации ФСТЭК России, ведомство фиксирует множество нарушений регламентов со стороны отечественных разработчиков ПО в сфере устранения уязвимостей. В частности, акцентируется внимание на том, что многие компании не обеспечивают должной техподдержки своего ПО.
Замглавы ведомства Виталий Лютиков на недавно прошедшей конференции BIS Summit подчеркнул, что службы поддержки российских разработчиков ПО должны максимально оперативно реагировать на запросы клиентов, но на практике всё чаще фиксируются случаи, когда заказчики не получают своевременного и/или полноценного ответа по вопросам купленных российских ИБ-продуктов.
Сергей Деев, руководитель продукта по управлению безопасной разработкой компании МТС RED: «Проблема длительного реагирования на устранение уязвимостей вызвана множеством факторов. Важнейшим из них является различный уровень зрелости внедрения практик безопасной разработки по отрасли. Есть лидеры – те компании, которые имеют все необходимые инструменты и процессы, позволяющие довольно оперативно устранять уязвимости. При это по-прежнему остается множество компаний, которые находятся еще в начале пути.
При внедрении практик безопасной разработки компании сталкиваются с тремя основными проблемами.
- Во-первых, это кадровый голод. Множество компаний нуждается в специалистах application security и DevSecOps, экспертах по сертификации ПО. Радует, что отрасль стремится решить эту проблему. Коллеги из ФСТЭК России регулярно проводят обучение специалистов по использованию инструментов безопасности и ключевым практикам анализа уязвимостей. Организуют тренинги и другие участники рынка – учебные центры, вендоры ИБ и интеграторы. Поэтому компании вполне могут вырастить экспертов из своих сотрудников, направив их на обучение.
- Во-вторых, в компаниях пока не до конца выстроены процессы безопасной разработки ПО, частью которых является и решение задачи устранения уязвимостей. С выстраиванием таких процессов помогают как компании, специализирующиеся на подготовке к сертификации разрабатываемого ПО по требованиям ФСТЭК, так и интеграторы и вендоры, работающие в области автоматизации процессов безопасной разработки. Выбор компании-помощника зависит от целей организации.
- В-третьих, наблюдается недостаточная автоматизация процессов безопасной разработки. Даже наличие множества инструментов и обученных специалистов не гарантирует успешное функционирование процесса. Эксперты могут просто-напросто захлебнуться в количестве полученных от инструментов анализа сообщений о выявленных уязвимостях! Поэтому важно обеспечить управляемость этого процесса. А сделать это можно с помощью решений, которые сопоставляют, приоритизируют и сводят в едином окне результаты проверок на уязвимости из разных источников. Также эти решения могут централизованно управлять запуском разных инструментов анализа и выступать единой точкой интеграции с компонентами сборочной инфраструктуры.
Применение таких решений компетентными специалистами в совокупности со зрелыми инструментами анализа в рамках выстроенных процессов в компании не только позволит снизить нагрузку на экспертов, которые параллельно могут быть задействованы и в анализе информации о полученной уязвимости, но и снизить вероятность появления таковой.
Сам факт, что регулятор обращает внимание на проблемы, связанные с устранением уязвимостей, свидетельствует о том, что организациям следует предпринимать больше усилий в данном направлении. Что несомненно будет трендом на ближайшие несколько лет».
По словам Романа Карпова, директора по стратегии и развитию технологий Axiom JDK, необходимо принимать во внимание несколько моментов, перед тем как говорить о том, почему российские разработчики не реагируют на уязвимости и не укладываются в срок:
- Процесс разработки патча безопасности и его инспекционный контроль безусловно занимает время.
- Наличие Open Source компонент в СЗИ требует дополнительного внимания. Зачастую разработчик СЗИ не является разработчиком, интегрированным в проект с открытым кодом, и при появление уязвимостей может потребоваться время пока комьюнити починит, но «опубличивание» уязвимостей обычно (в зрелых Open Source проектах) происходит при уже выпущенном патче безопасности.
- В коде надо уметь разбираться. А если проект серьезный, то без реальной экспертизы разобраться в 3 Гб исходных текстов (например, верифицировать которые потребовалось при сертификации Java) не представляется возможным.
- Внедрение SBOM (Software Bill of Materials) позволит обеспечит прозрачность того, как сделан продукт на базе Open Source и что содержит сертифицированный продукт. Поставщик должен нести ответственность за свой продукт.
Кай Михайлов, Руководитель направления информационной безопасности iTPROTECT: “Проблема устранения уязвимостей и программных ошибок была характерна не только для российских, но и для зарубежных продуктов (кстати, в том числе сертифицированных), и до изменения ситуации на российском рынке кибербезопасности. Мы до сих пор наблюдаем, как в некоторых продуктах ошибки не исправляются годами и “кочуют” из старых версий в новые.
Но в данный момент российские вендоры находятся в ещё более сложной ситуации — им приходится в ускоренном темпе расширять функциональность продуктов, чтобы в полной мере заменить зарубежные аналоги для заказчиков, которые проводят импортозамещение. В связи с этим на устранение уязвимостей как в старой кодовой базе, так и в новых функциях, ресурсов остаётся меньше. Кроме того, при внесении изменений в сертифицированный продукт, в том числе для устранения уязвимостей или ошибок, необходимо проходить инспекционный контроль, а это дополнительно замедляет процесс оптимизации.
Так как мы в iTROTECT много времени посвящаем внедрению и пилотированию средств защиты, то замечаем, что главной мотивацией для исправления уязвимостей производителем являются не обращения в техподдержку (когда решение уже используется заказчиком), а именно замечания на этапе пилота. Если заказчик прямо подсвечивает, например, наличие уязвимых версий библиотек или модулей в продукте и это может послужить причиной отказа от закупки в пользу конкурента, то этой проблеме будет отдан приоритет со стороны производителя. Такие кейсы у нас были. Однако в целом нужно понимать, что в любом ПО есть уязвимости, даже часто обновляемом. Поэтому важно использовать сканеры уязвимостей, чтобы их вовремя выявлять и устранять компенсирующими мерами.
Что касается использования open-source решений, то нельзя забывать, что современный подход к разработке ПО основан на переиспользовании кода. Большая часть кодовой базы была разработана гораздо раньше и в ней наверняка содержатся уязвимости, даже если мы про них не знаем. Однако со временем разработчики переписывают, улучшают код и устраняют ошибки. Через какое-то время это позволит создать действительно качественные продукты, но такой результат появится только в долгосрочной перспективе“.
Актуальные вакансии по ИБ: https://cisoclub.ru/vacancy/. Отправить резюме во все популярные IT-компании: https://cisoclub.ru/jobmail/
Больше интересного материала на cisoclub.ru. Подписывайтесь на нас: VK | Twitter | Rutube | Telegram | Дзен | YouTube.