Pull to refresh

Comments 31

Вот очень интересный для меня вопрос, может быть те, кто в теме, ответят?
«Для того разработчики должны описать каждую функцию и механизм работы. ».

А как это применимо к популярной у нас теме выпуска брендированного опенсорса, накрытого сертификатами?
Они что описывают каждую функцию и механизм работы какого-нибудь Libreoffice? :)
Когда я сталкивался с этим вопросом, довольно таки давно, лет 7 назад, ни о каком анализе исходников речи и не шло. Если проверка и была, то чисто формальная и автоматизированными тулами, и естественно никто ничего не описывал.
Что-то реально изменилось, и исходники теперь анализируются, описываются и комментируются?
Угу, называется «документация»
Это относится только к программному обеспечению из сферы информационной безопасности. К Libreoffice и остальному софту требования пока не меняются.
Кажется не все функции подряд, а только те функции, которые относятся к реализации механизмов безопасности.
Вы когда-нибудь паспорт от матерники листали? «Option: Bus Spread Spectrum. Possible values: On, Off. Function: Turns on or off Bus Spread Spectrum». Такую документацию можно программно генерировать из исходников.
Я говорил про сертификационную документацию. А паспорт от материки к такой не относится.
Кроме того, предоставление исходных кодов с определенного времени запрещается законодательством ряда стран

А можно поподробнее:
1) Я правильно понял, что компании может быть запрещено предоставлять кому-либо (или кому-то конкретному) её же написанный исходный код?
2) Можно примеры стран и компаний?
3) Какова логика? Чьи интересы затронет то, что я покажу свои исходники своим клиентам?

Я не знаю подробностей, но могу предположить.


Какова логика? Чьи интересы затронет то, что я покажу свои исходники своим клиентам?

Интересы других клиентов, которые используют ваш софт. Клиент, который видел код может обнаружить в нём уязвимость или недокументрованную возможность, которую вы внедрили по настойчивой просьбе ваших локальных спецслужб, а затем использовать их (уязвимость и НДВ) против других ваших клиентов.

Какова логика? Чьи интересы затронет то, что я покажу свои исходники своим клиентам?

Попадалась мне новость о том, что министерство обороны США будет отказываться покупать ПО тех, кто показывал исходники другим странам. Логику уже объяснил IvaYan.

Пример комании — Microsoft. У них есть сертифицированные по требованиям ФСТЭК, нашего МО и, кажется, ФСБ версии СУБД и ОС. Если еще и исходиники покажут этих продуктов, то это серьезный удар по информационной безопасности США будет.

Запрещать, думаю, не станут. Как Вы думаете кого выберет MS в качестве покупателя, если будет выбор США или иное государство?
UFO just landed and posted this here
Попадалась мне новость о том, что министерство обороны США будет отказываться покупать ПО тех, кто показывал исходники другим странам. Логику уже объяснил IvaYan.

Не обязательно будет, но может. Появляется некий риск, но тут вендоры уже соотносят риски и прибыль. Плюс, наверняка, на таком уровне, как Microsoft, включаются свои лоббистские рычаги.

У них есть сертифицированные по требованиям ФСТЭК, нашего МО и, кажется, ФСБ версии СУБД и ОС

Если сертифицировали на НДВ (недекларируемые возможности) 4 уровня и выше (3,2,1), по старому РД НДВ то не могли не показывать.
Возможная причина отказа иностранных вендоров от сертификации ( safe.cnews.ru/news/top/2019-04-09_gosudarstvo_zastavit_rossijskih_ibvendorov_potratitsya )
Напомним, что в августе 2018 г. президент США Дональд Трамп (Donald Trump) подписал закон H.R.5515. В соответствии с ним Министерству обороны США разрешается отказываться от использования ИТ-решений или технологий информационной безопасности, если выявлен факт проведения анализа исходного кода этих решений иностранными государственными структурами и иными организациями, под определение которых попадает и ФСТЭК.
Вот этот параграф 1655 в первоисточнике (закон H.R. 5515 на сайте Конгресса): www.congress.gov/bill/115th-congress/house-bill/5515/text#toc-H446400AAA598419DADB2E6D9D3B06CEF

В двух словах: если иностранный вендор открыл иностранцам (например, русским) код, то обязан об этом сообщить при поставке ПО для нужд Минобороны США. Те, в свою очередь, вправе при такой покупке проверить, а нет ли тут «risk to the national security infrastructure or data of the United States, or any national security system under the control of the Department» и принять какие-то дополнительные меры «защиты» (доп. условия / требования в контракт) вплоть до непрописанного, но подразумеваемого отказа от приобретения такого софта.
А как это применимо к популярной у нас теме выпуска брендированного опенсорса, накрытого сертификатами?

У нас есть опенсорс с сертифиатами ФСТЭК? А можно пример? Насколько я знаю сертифицируются только средства защиты информации, а не всякие OpenOffice и LibreOffice…

Например некоторые творения компании эшелон брэндированный опенсорс. Там конечно средства защиты, не офис, но опенсорсные в девичестве )

Есть AstraLinux, у ее версии Special Edition есть сертификат ФСТЭК.

Да да, это прямо на поверхности. Но тут опять же вопрос — сертификат имеет ОС со всем содержимым, или же ОС считается сертифицированной, если какие-то специальные ее компоненты сертифицированы? Это же не монолит.
UFO just landed and posted this here
Сертифицируются все компоненты ОС. Устанавливаемое на эту ОС стороннее ПО сертифицирует производитель этого ПО. За установку несертифицированного ПО несет ответственность тот, кто его установил/разрешил установить. В зависимости от класса защиты от несанкционированного доступа в состав вычислительного средства могут входить как простейшие средства защиты вроде логинов/паролей, так и специализированное ПО, аппаратные средства защиты и т.д. вплоть до ограничения физического доступа.
UFO just landed and posted this here
Сертификация предназначена для гарантии (в идеале, конечно) отсутствия бэкдоров, не обязательно сетевых, но и, например, передача информации через флешки. Можно придумать какие-нибудь экзотические способы передачи, например, через видеосигнал монитора или ультразвуком через динамики; я не знаю, насколько такое возможно на практике, но в теории почему бы и нет, история знает подобные прецеденты (известный «Златоуст»).
Настройка iptables — это обязанность уже службы безопасности. И одно другого не исключает.
Так они реально анализируют код на отсуствие бэкдоров? И как, успешно?
А уязвимости? А как быть, когда сертификат выдается на код, в котором потом обнаруживается уязвимость, сертификат отзывается/приостанавливается до момента релиза фикса?

Проводит ли реально кто-то анализ кода или просто через некоторое время ставят штамп «сертифицированно» я не знаю, но однажды был вынужден ознакомиться с вопросом «защита от несанкционированного доступа», пришлось почитать соответствующие документы, которые я очень кратко резюмировал в своем комментарии.
Про случаи отзыва сертификатов по причине найденных уязвимостей никогда не слышал. Вообще все ГОСТы и прочие документы обычно отстают от реальной жизни лет на 20-40, когда нормативная база по сертификации разрабатывалась, опенсорс и публикация информации по уязвимостям были в зачаточном состоянии.
UFO just landed and posted this here
UFO just landed and posted this here
Скорее просто Касперский станет монополистом.
Доктор не тусуется в нужных кругах
Если исходить из логики OpenSource, компаниям нечего скрывать, если конечно там нет закладок. Посмотрят и успокоятся. Плюс будет бэджик «Прошло проверку КАКАЯ НИБУДЬ АББРЕВИАТУРА».

Но зная наших законотворцев, думаю обяжут платить за эту процедуру, а проверки как таковой не будет.
Меня терзают смутные сомнения.
1. В письме от регулятора не совсем ясно прописано о решениях в которых используются те или иные модули по безопасности, но сами комплексные решения не являются продуктами по безопасности.
2. В дополнение к замечанию про предоставление исходного кода на НДВ. Часть решений как по безопасности так и общего пользования являются товарами двойного назначения по классификации в США. Межсетевой экран, тепловизор, обычный 8 портовый свич или бордер раутер, являются товарами двойного назначения.
3. В случае отказа зарубежных производителей сотрудничать с российскими органами и дальнейшем оттоком и сворачиванием бизнеса в России и Евразийском Союзе, это приведет в лучшем случаю к замораживанию проектов и пополнению рядов безработных из интеграторов и других структур. В худшем варианте это приведет к деградации и отказам в существующих системах.
Увы пока имеется изъян. Куча иностранных решений, аналогов российского производства нет и вероятно не предвидится, как и наоборот. Куча решений, как иностранных так и отечественных, с открытым или даже закрытым кодом не могут быть использованы в государственных информационных системах даже если сто раз пройдут сертификацию.
1. Ничего неожиданного или сверхъестественного не произошло. Новые требования разрабатывались давно. Собирались вводить с мая, а вот теперь из первоисточника на сайте ФСТЭК читаем про 1 июня.

2. Уровней доверия 6 (от большего к меньшему увеличивается строгость требований). На 5 и 6, насколько я знаю, исходный код показывать не нужно (только подготовить пачку документации и пройти сертификационные испытания). Исходники открываются только с 4 уровня.

Если иностранный поставщик ранее получал сертификат ФСТЭК по 4 уровню НДВ для какой-то поставки в госорган, значит, показывал исходники при сертификационных испытаниях. Если теперь покупатель выставит ему требование пересертифицировать софт на 4 уровень доверия по новым требованиям (как рекомендует ФСТЭК в своем информационном сообщении), то для вендора глобально («надо показывать исходники») ничего не изменится, за исключением одной хитрой детали — согласно п. 13 прошлогоднего приказа ФСТЭК №55, переопределившему процедуру сертификации, сертификационные испытания проводятся в России.

А вот захочет ли вендор (тот же MS) вывозить/передавать исходники из своей страны в РФ и демонстрировать их тут — это вопрос, на который каждый из них будет отвечать индивидуально.
Sign up to leave a comment.

Other news