Подводные камни open source при создании отечественных средств защиты

Давайте не будем лукавить и честно признаемся - свежие российские решения по ИБ (исключая СЗИ от НСД, СКЗИ и других “старичков”) активно используют open source компоненты в своем составе.

Этого нечего стыдиться - это нормальная практика, задействовать уже написанный кем-то и распространяемый под разными лицензиями (GPL, ) код. Согласно отчету Black Duck Open Source Security and Risk Analysis (OSSRA) за 2017-й год 96% проанализированных авторами отчета приложений используют open source. Прошли те времена, когда сложные приложениям (да и не очень сложные тоже) целиком создавались одной командной с нуля. В условиях нехватки времени и компетенций, многие используют уже кем-то написанный код. И наша отрасль не является исключением. По данным отчета OSSRA сфера кибербезопасности находится на 3-м месте по проценту использования открытого ПО (после здравоохранения и ритейла с электронной коммерцией). А вообще согласно OSSRA 96% приложений задействует open source компоненты, число которых может достигать 147 штук на одно приложение.

Учитывая стратегию на импортозамещение в России, тема контроля применения open source в российских средствах защиты информации становится как никогда актуальной. Особенно в контексте последних нормативных изменений. Например, недавний приказ ФСТЭК №55 по новым правилам сертификации. Есть там такой пассаж, который применяется в тех случаях, когда продукт, подаваемый на сертификацию, содержит компоненты не только одного разработчика, но и других компаний или команд. Да, к open source этот фрагмент тоже имеет отношение.

Соответственно, при использовании open source, заявитель должен прикладывать к продукту текст лицензии (GPL, BSD и других), которые и считаются договорами. Интересно, что согласно OSSRA 85% приложений содержат компоненты open source в нарушение существующих лицензий, а 53% и вовсе не упоминают об использовании open source, нарушая права авторов на создание, модификацию и распространение своего ПО. Например, у Континент СОВ явного упоминания использования open source нет - кроме единственной новости 2013-го года про использования Snort и завуалированной новости про устранение уязвимости в движках Snort и Suricata. А вот у Инфотекса есть отдельный документ про использование open source, который прилагается к VipNet IDS. И тут возникает

Второй вопрос достаточно очевиден и я про него уже не раз писал. Речь идет об уязвимостях в open source и иных компонентах третьих фирм. Согласно требованиям ФСТЭК именно заявитель отвечает за устранение уязвимостей в своем продукте, независимо от того, в каком компоненте (своем или чужом) эта уязвимость найдена. Согласно OSSRA среднее число уязвимостей в open source компоненте составляет 27, а известные open source уязвимости (OpenSSL, Apache, zlib, libxml2, libpng, ядро Linux и др.) найдены в 67% приложений. Вспоминая историю с некоторыми сертифицированными форками, авторы которых прямо признавались, что они не способны устранить уязвимость, пока ее не устранит сообщество, поддерживающее компонент open source, возникает логичный:


Ну и, наконец, еще один момент, который "всплыл" после прочтения проектов приказов ФСБ по ГосСОПКЕ. В приказе по техсредствам ГосСОПКИ есть раздел с требованиями по "доверию" (по аналогии со схожими требованиями ФСТЭК), в котором написано, что должно выполняться применительно к техсредствам ГосСОПКИ:

Меня в этой пятерке требований интересует 3-й и 4-й пункт, которые, если транслировать их на open source, вызывают вопросы. Возьмем к примеру Snort или Suricata, в числе активных контрибуторов или разработчиков которого, российских ИБ-вендоров не наблюдается. Кто занимается модернизацией этих движков, на которых построены некоторые "отечественные IDS"? Российский вендор или все-таки сообщество, которое находится преимущественно зарубежом и обычно работает в иностранных организациях? Что-то мне подсказывает, что второе. Но тогда получается, что это приводит к невозможности выполнения третьего пункта в перечне на слайде? А покупка сигнатур атак у той же Emerging Threats - это ведь гарантийная поддержка (4-й пункт слайда)? Кстати, наличие управляющей компании в Лондоне тоже ведь нарушает данные требования ФСБ (правда, это уже не про open source). Отсюда


В качестве заключения мне бы хотелось привести список рекомендаций к вендорам, потребителям и регуляторам, относительно применения open source в отечественных решениях (в большей степени для них, хотя и для "иностранцев" это тоже важно):

ЗЫ. Тем, кто утверждает, что на open source не распространяются геополитические риски и санкции, впору вспомнить историю с запретом Asterisk в Иране и кейс с блокированием доступа к Sourceforge пользователям Судана, Сирии, Кубы, Ирана и Северной Кореи.

Источник: