Учитывая стратегию на импортозамещение в России, тема контроля применения 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 пользователям Судана, Сирии, Кубы, Ирана и Северной Кореи.
