ROSS`2012 о сертификации СПО

Эксперты отмечают рост регулятивных требований к информационной безопасности (ИБ) программного обеспечения, применяемого в госструктурах. В ситуации, когда исходные коды востребованного проприетарного программного обеспечения (ППО) недоступны для проведения необходимых в госсекторе проверок, хорошей альтернативой становится свободное программное обеспечение (СПО).

В настоящее время СПО чаще всего сертифицируется на соответствие требованиям руководящих документов Гостехкомиссии (РД ГТК), которые включают проверку на отсутствие несанкционированного доступа (НСД) и недекларированных возможностей (НДВ), что дает возможность использовать сертифицированное таким образом ПО в информационных системах (ИС) до класса 1Г включительно и до класса 1К для информационных систем персональных данных (ИСПДн). Сертификации подлежит каждая конкретная сборка ПП, а не исходные коды, независимо от того, СПО это или ППО.

В процессе сертификации действует принцип аддитивности: если система состоит из нескольких компонентов, то ее аттестация сильно упрощается в случае, когда ее компоненты сертифицированы. По отзывам представителей испытательных лабораторий наблюдаемый рост заявлений на сертификацию СПО не составляет для них проблемы — они вполне справляются с запросами. Сертификация, по оценкам специалистов испытательных лабораторий, не сильно удорожает ПО.

На состоявшейся 12 апреля в Москве конференции Russian Open Source Summit 2012 ( ROSS`2012) вопросам использования СПО в построении защищенных ИС и их сертификации была отведена отдельная секция.

Основные требования к заявителю

Отталкиваясь от опыта своей компании, начальник испытательной лаборатории “Центра безопасности информации” Сергей Макаров заявляет, что ПО с открытым кодом сертифицировать можно и нужно. По его мнению, самый ответственный момент в сертификации СПО, влияющий на длительность и даже на конечный результат этой процедуры, — этап предоставления заявителем на сертификацию образца для проведения испытаний.

В идеальном варианте заявитель должен передать в испытательную лабораторию исходные тексты, загрузочные коды, документацию, а при необходимости и инструментальные средства для сборки загрузочных кодов из исходников. На практике же случается, что заявитель дает только ссылку, по которой можно добраться до кодов дистрибутива. Это сильно затрудняет для испытательной лаборатории проведение оценки объекта, поскольку в этом случае ее специалистам приходится изучать объект испытаний по открытым источникам, определять, что в нем может быть сертифицировано, а что в принципе не может пройти процедуру, вступать в диалог с заявителем, предлагая ему уточнить физические и логические границы сертифицируемого объекта, т. е. функции, которые объект должен выполнять, перечень файлов дистрибутива и пр. При этом в исходных текстах, добываемых из открытых источников, могут оказаться и такие уязвимости, которые не позволят защитить программный продукт доступными средствами защиты, и тогда сертифицировать его окажется просто невозможно.

СПО часто разрабатывается несколькими разработчиками, каждый из них может работать в своей среде, со своими программными библиотеками. Если заявитель не в курсе процесса сборки продукта, испытательная лаборатория вынуждена создавать сборочные машины, которых для одного продукта может быть несколько и которые нужно хранить, чтобы сопровождать продукт — сертифицировать его изменения.

Как пояснил г-н Макаров, испытательная лаборатория должна собрать из исходных текстов дистрибутив, который хочет использовать заявитель. Такой дистрибутив становится эталоном, он-то и определяется при положительном исходе как прошедший сертификацию. Заявитель хранит у себя эталонную версию, поставляет на сертификацию обновления и ведет их архив.

Сергей Макаров обращает внимание заявителей на то, что согласно российскому законодательству о защите прав потребителей пользовательская документация на ПП должна быть представлена на русском языке. То же самое относится к документации, которая сопровождает ПП при предоставлении во ФСТЭК. Это обязанность заявителя. Как показывает практика, пожелания испытательной лаборатории и действующие обязательные правила проще выполняют крупные заказчики.

Проблемы сертификации обновлений

Заявитель должен аккумулировать обновления ПП, которые генерирует разработчик для изменения функционала или закрытия обнаруженных уязвимостей, и направлять их в испытательную лабораторию. Лаборатория по результатам контроля делает заключение о влиянии обновлений на безопасность ПП. Для минимизации сроков сертификации обновлений контролю подвергаются только те изменения дистрибутива, что затрагивают функции безопасности. При этом специалисты испытательных лабораторий предупреждают о том, что проверку на НДВ проходит конкретный дистрибутив. Это означает, что любые внесенные в код ПП изменения, в том числе и обновления, требуют новой проверки всего кода, а не только кода обновления. Если же ПП не проходит проверки на НДВ, сертификации подлежат только те обновления, по которым сертифицирующий орган на основании предоставляемого вендором описания делает заключение о проверке.

После получения заключения о соответствии обновлений сертифицируемым параметрам вендор размещает обновления в репозитории сертифицированных обновлений, доступ пользователей к которому осуществляется через защищенный портал.

Установка сертифицированных обновлений является обязательным условием действия сертификата. Если пользователь нарушает его, то действие сертификата прекращается. Время, отводимое для установки сертифицированных обновлений, зависит от эксплуатируемого ПО и определяется аттестационной комиссией при аттестации системы, в которой данное ПО используется. Обычно это месяц. Как сообщил генеральный директор компании “Сертифицированные информационные системы” Сергей Груданов, сертификация обновлений ПП в настоящее время занимает тоже около месяца. Таким образом, с момента выпуска обновления разработчиком до обязательной установки его сертифицированной версии пользователем должно пройти не более двух месяцев. Однако на момент проверки контролирующими органами сертифицированные обновления должны быть в обязательном порядке установлены. В противном случае проверяемые должны уметь обосновать причины задержки их установки.

По наблюдениям г-на Груданова, при идентичности технологий сертификации СПО и ППО сроки процедур для СПО нередко значительно больше, и во многом из-за слабой информированности заявителей о выпущенных обновлениях предоставляемого ими ПП, разработанного на основе СПО.

В случае выпуска обновлений, закрывающих критические уязвимости, г-н Груданов рекомендует максимально оперативно устанавливать их, не дожидаясь завершения сертификации этого обновления — система должна быть в первую очередь безопасной и уже потом удовлетворять требованиям сертифицированной. По утверждениям экспертов, переложить ответственность за ущерб от наличия уязвимостей в сертифицированном ПП на сертифицирующую структуру не удастся, поскольку она предоставляет только инструмент, прошедший оговоренную в документах на сертификацию проверку надежности. Как этим инструментом пользуются, зависит от конкретного заказчика.

Признано, что исключить наличие уязвимостей невозможно даже в сертифицированных ПП, как, впрочем, в любой программной разработке. Однако вероятность наличия уязвимостей благодаря процедурам сертификации резко снижается. Прецеденты обнаружения уязвимостей в сертифицированных ПП были, но случаев судебных разбирательств и даже просто обращений в суд по этим поводам не отмечено. Сертификация обеспечивает необходимые, но не достаточные условия безопасной эксплуатации ПП.

Некоторые особенности построения защищенных систем с использованием СПО

Как сообщил директор департамента программных разработок НПО “Эшелон” Андрей Фадин, большая часть современных российских средств защиты информации (СЗИ) базируется на продуктах, разработанных с применением СПО; есть также немало примеров успешного интегрирования ППО и СПО. Однако о подобном происхождении своих продуктов их разработчики предпочитают умалчивать.

Вместе с тем в приведенном г-ном Фадиным списке СЗИ, построенных на СПО и прошедших сертификацию, есть операционные системы, ПО промежуточного слоя, антивирусы, межсетевые экраны, DLP-системы, средства обнаружения вторжений, средства разработки и аудита программных продуктов, базы данных, веб-платформы и многое другое. Названия таких СЗИ можно найти в Государственном реестре сертифицированных СЗИ ФТЭК, в “Перечне средств защиты информации, сертифицированных ФСБ РФ”, в перечне разработанных и принятых на снабжение Вооруженных Сил РФ средств БИЗКТ, а также в таких открытых источниках, как сайты разработчиков и Википедия.

По мнению г-на Фадина, несмотря на распространенность СПО в разработках СЗИ, рынку таких разработок не хватает прозрачности, регламентов и стандартов, оставляет желать лучшего и уровень документирования таких отечественных СЗИ, даже тех из них, которые создаются в рамках государственных программ, что сильно затрудняет их сертификацию. Он выразил надежду на то, что проект “Национальной программной платформы” (НПП) сыграет в преодолении этих негативных моментов положительную роль.

Вместе с этим г-н Фадин отметил, что на соответствующем этапе к работам по созданию национальной программной платформы будут привлечены и испытательные лаборатории, пока же это делать рано. В нынешнем году планируется создание механизмов и функционала разработки ПП для НПП и их передачи в фонд алгоритмов и программ для открытого, коммерческого и закрытого сегментов рынка потребления ПО, который будет контролироваться государством. Для этих сегментов потребителей механизмы и функции проверок будут различаться. Возможно, в ходе создания НПП возникнут и новые руководящие документы для сертификации, новые нормы и методики, которые будут описывать процесс проверок.

Российские средства криптозащиты информации (СКЗИ) подлежат обязательной сертификации в ФСБ, а их использование предъявляет требования также и к среде функционирования, в первую очередь к аппаратной платформе, и перенос их на другую платформу требует новой сертификации СКЗИ. Сертификат на СКЗИ действует три года, а процесс сертификации занимает до двух лет.

Как напомнил эксперт по информационной безопасности “Академии информационных систем” Дмитрий Левиев, для встраивания российских криптоалгоритмов в программные продукты, не только предназначенные для внутрикорпоративного использования, но и распространяемые как самостоятельные продукты или применяемые для предоставления с их помощью услуг независимо от того, построены они на СПО или ППО, нужна лицензия ФСБ. Он предупредил, что требования на получение таких лицензий вскоре станут строже, чем действующие в настоящее время, что приведет к необходимости переоформления лицензий и дообучения персонала лицензиатов.

Г-н Левиев полагает, что российские регуляторы нацелены на перенос криптопротоколов в доверенную аппаратную среду. В качестве таковой могут выступать как доверенные компьютеры (что очень дорого для коммерческого применения), так и некоторые более дешевые дополнительные устройства (например, токены), в которых криптоалгоритмы могут быть реализованы. Он сообщил, что для СПО в настоящее время имеется пять соответствующих этим требованиям к доверенной среде смарт-карт, находящихся в стадии сертификации, и напомнил о существовании открытого перечня средств криптозащиты у ФСБ РФ, которые можно использовать в информационных системах, не обрабатывающих данные, содержащие государственную тайну.

Российским корпоративным пользователям не стоит также забывать о том, что СПО, задействованное в обслуживании электронной подписи, должно удовлетворять требованиям вступающего в силу 1 июня нынешнего года закона “Об электронной подписи” и соответствующим подзаконным актам.