Рубрикатор | ![]() |
![]() |
Блоги | ![]() |
Алексей ЛУКАЦКИЙ | ![]() |
![]() |
Подводные камни open source при создании отечественных средств защиты
29 мая 2018 |
![]() |
Давайте не будем лукавить и честно признаемся - свежие российские
решения по ИБ (исключая СЗИ от НСД, СКЗИ и других “старичков”) активно
используют 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 в российских средствах защиты информации становится как никогда актуальной. Особенно в контексте последних нормативных изменений. Например, недавний приказ ФСТЭК №55 по новым правилам сертификации. Есть там такой пассаж, который применяется в тех случаях, когда продукт, подаваемый на сертификацию, содержит компоненты не только одного разработчика, но и других компаний или команд. Да, к open source этот фрагмент тоже имеет отношение.
![](/data/2018/05/29/1237710577/Screen Shot 2018-05-23 at 14.34.22.png)
Соответственно, при использовании open source, заявитель должен
прикладывать к продукту текст лицензии (GPL, BSD и других), которые и
считаются договорами. Интересно, что согласно OSSRA 85% приложений
содержат компоненты open source в нарушение существующих лицензий, а 53%
и вовсе не упоминают об использовании open source, нарушая права
авторов на создание, модификацию и распространение своего ПО. Например, у
Континент СОВ явного упоминания использования open source нет - кроме
единственной новости 2013-го года про использования Snort и
завуалированной новости про устранение уязвимости в движках Snort и
Suricata. А вот у Инфотекса есть отдельный документ про использование
open source, который прилагается к VipNet IDS. И тут возникает
Вопрос №1. Должна ли ФСТЭК требовать соблюдения лицензий GPL и др. от заявителей?
Второй вопрос достаточно очевиден и я про него уже не раз писал. Речь идет об уязвимостях в open source и иных компонентах третьих фирм. Согласно требованиям ФСТЭК именно заявитель отвечает за устранение уязвимостей в своем продукте, независимо от того, в каком компоненте (своем или чужом) эта уязвимость найдена. Согласно OSSRA среднее число уязвимостей в open source компоненте составляет 27, а известные open source уязвимости (OpenSSL, Apache, zlib, libxml2, libpng, ядро Linux и др.) найдены в 67% приложений. Вспоминая историю с некоторыми сертифицированными форками, авторы которых прямо признавались, что они не способны устранить уязвимость, пока ее не устранит сообщество, поддерживающее компонент open source, возникает логичный:
Вопрос 2. Что делать потребителю, если ФСТЭК
отзывает/приостанавливает сертификат на средство защиты при
отказе/невозможности заявителя устранять уязвимость в open source
компоненте?
Ну и, наконец, еще один момент, который "всплыл" после прочтения проектов приказов ФСБ по ГосСОПКЕ. В приказе по техсредствам ГосСОПКИ есть раздел с требованиями по "доверию" (по аналогии со схожими требованиями ФСТЭК), в котором написано, что должно выполняться применительно к техсредствам ГосСОПКИ:
![](/data/2018/05/29/1237710583/Screen Shot 2018-05-23 at 14.07.14.png)
Меня в этой пятерке требований интересует 3-й и 4-й пункт, которые, если
транслировать их на open source, вызывают вопросы. Возьмем к примеру
Snort или Suricata, в числе активных контрибуторов или разработчиков
которого, российских ИБ-вендоров не наблюдается. Кто занимается
модернизацией этих движков, на которых построены некоторые
"отечественные IDS"? Российский вендор или все-таки сообщество, которое
находится преимущественно зарубежом и обычно работает в иностранных
организациях? Что-то мне подсказывает, что второе. Но тогда получается,
что это приводит к невозможности выполнения третьего пункта в перечне на
слайде? А покупка сигнатур атак у той же Emerging Threats - это ведь
гарантийная поддержка (4-й пункт слайда)? Кстати, наличие управляющей
компании в Лондоне тоже ведь нарушает данные требования ФСБ (правда, это
уже не про open source). Отсюда
В качестве заключения мне бы хотелось привести список рекомендаций к вендорам, потребителям и регуляторам, относительно применения open source в отечественных решениях (в большей степени для них, хотя и для "иностранцев" это тоже важно):
Вопрос №3. ФСБ сознательно закрывает доступ open source в ГосСОПКА или с этой стороны о проблемах никто не думал?
В качестве заключения мне бы хотелось привести список рекомендаций к вендорам, потребителям и регуляторам, относительно применения open source в отечественных решениях (в большей степени для них, хотя и для "иностранцев" это тоже важно):
![](/data/2018/05/29/1237710581/opensource.png)
![](/data/2018/05/29/1237710581/opensource.png)
ЗЫ. Тем, кто утверждает, что на open source не распространяются
геополитические риски и санкции, впору вспомнить историю с запретом
Asterisk в Иране и кейс с блокированием доступа к Sourceforge
пользователям Судана, Сирии, Кубы, Ирана и Северной Кореи.
Оставить свой комментарий:
Комментарии по материалу
Данный материал еще не комментировался.