Журнал "Information Security/ Информационная безопасность" #1, 2019

Егор Кожемяка – Требования устанав- ливают критерии, отно- сящиеся к вопросам правообладания, а не к вопросам написания программного кода и архитектуры решений. Например, во многих российских про- дуктах, которые основаны на свободном ПО, значительная часть программного кода написана независимыми разра- ботчиками, которые могут быть граж- данами других государств. Проблема эта частично решается членами экс- пертного совета. Таким образом, каких- либо четких правил на этот счет мы не знаем, а человеческий фактор точно есть. Александр Новожилов – Требования обосно- ванны. Они правильные, они достаточные, ослаб- лять их точно не нужно. Единственное – можно было бы ускорить про- цедуру включения в реестр. Потому что в XXI в. изменения в продукте происходят каждые три меся- ца, а процедура сертификации чересчур длительная. – Допустимо ли считать отечественными программные и аппаратные решения, основным компонентом которых являются иностранные средства? Как вы считаете, нужно ли ввести для отечественных производителей программного обеспечения требование "достаточно глубокой степени переработки" зарубежного решения, как и существующее требование для оборудования? Дмитрий Кандыбович – Это вопрос открытый. С одной стороны, экс- перты говорят, что если вы используете все свое, то только тогда продукт считается оте- чественным. С другой стороны, сложно обходиться без импортных компонентов. Это зависит еще и от среды заказчика, в которую нужно интегрировать решение. Если уже приобретены компоненты, нет смысла от них отказываться. Третий момент – возникает вопрос спекуляций: берут западное решение, делают на него небольшой обвес и продают. Здесь назначение реестра – оградить заказчиков от жульнических компаний. Но если описать технологию, ее назначение, указать, что разработка мультиплатформенная, включающая такие-то компоненты наряду с опен- сорсом, – этого достаточно, чтобы попасть в реестр. Егор Кожемяка – Все зависит от крите- риев отнесения к отече- ственному программно- му обеспечению и от соответствующей мето- дики. Вопрос этот нужно решать всему профес- сиональному сообществу – достаточно широкому кругу экспертов. Не следует также забывать, что вне зависимости от "степени и глубины переработки" в основном компоненте могут быть уязвимости, которые не всегда можно обнаружить даже при наличии исходных текстов программ. Александр Новожилов – Программный код пишется не на русском, не на китайском, не на английском языках. Он пишется на определен- ных языках программи- рования. От того, анг- личанин или русский написали на С++ фрагмент кода, этот код будет отли- чаться лишь языком комментариев, написанных к нему. Не более. Отече- ственный производитель может полу- чить легальным образом права на какие-то программные модули, напри- мер, в виде Ое-контракта или без- условной передачи, или через GPL- условия, когда разработчики пишут код "в эфир" для общего пользования кодом. Тогда производитель просто должен указывать, откуда он этот код взял. Когда этот код разрабатывает большая группа разработчиков из раз- ных стран, очень странно там было бы увидеть "закладки" для кого-то. Ну, а если они и есть, то на страже стоит ФСТЭК России, который все это отсле- живает. Поэтому не очень понятно, что такое "переработка". Взять и пере- писать С++ на Pascal или на LISP? Может, и можно, но вопрос: зачем? Программный код интернационален, не относится ни к какой стране. Значе- ние имеет исключительно использова- ние российских библиотек, например, шифрования. Андрей Ревяшко – Уверен, что вполне допустимо. Проводя параллель с производ- ством автомобилей: наличие основных агре- гатов, произведенных за рубежом, это вполне себе нормальная практика. Так и со ста- новлением того или иного отечественного ПО. Использование, к примеру, в каче- стве хранилища иностранной базы дан- ных не делает его иностранным. Кроме того, нередко используются решения OpenSource-сообщества, работу которого сложно привязать к какой либо стране. Глубокая переработка основных компо- нентов, появившихся не в нашем отече- стве, на мой взгляд, не требуется, осо- бенно OpenSource-проектов. Ведь вокруг подобных компонентов появляется целая "инфраструктура", которая берет на себя задачи выпуска обновлений, совершен- ствования подходов и реакции на появле- ния уязвимостей в безопасности. – Нужно ли вообще вести речь о "степени переработки" ПО? Дмитрий Кандыбович – Если будет некий рег- ламент, который даст определенные критерии, внесет ясность в прави- ла игры, это не будет лишним. Тогда профес- сиональное сообщество сможет более четко оценивать, что из себя представляет ПО, состоящее из компонентов различного происхождения. Егор Кожемяка – Допустим, некий про- дукт существенно пере- работан. В этом продук- те обнаружена уязви- мость, а устранить ее российский разработчик самостоятельно не может, так как продукт основан на сво- бодном ПО и уязвимость находится в программном коде, который написал независимый "заокеанский коллега". В итоге наш разработчик просто ждет, когда кто-то, кто в этом коде разбирает- ся, устранит уязвимость. На наш взгляд, правильнее вести речь не о степени переработки, а о степени контроля над продуктом, а также возможностях и ком- петенциях вносить изменения в любую часть программного кода. 20 • ТЕХНОЛОГИИ Партнер "Круглого стола" www.confident.ru www.dallaslock.ru