Руководящий документ

Защита от несанкционированного доступа к информации

Программное обеспечение средств защиты информации

Классификация по уровню контроля отсутствия недекларированных возможностей

Утверждено решением председателя Государственной технической комиссии при Президенте Российской Федерации от 4 июня 1999 г. № 114

1.ОБЩИЕ ПОЛОЖЕНИЯ

2.ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ

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

Действие документа не распространяется на программное обеспечение средств криптографической защиты информации.

Уровень контроля определяется выполнением заданного настоящим РД набора требований, предъявляемого:

К составу и содержанию документации, представляемой заявителем для проведения испытаний ПО СЗИ;

Руководящий документ разработан в дополнение:

РД «Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации», М., Военное издательство, 1992 г.;

РД «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации», М., Военное издательство, 1992 г.;

РД «Средства вычислительной техники. Межсетевые экраны. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации», М., 1997 г.

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

1. ОБЩИЕ ПОЛОЖЕНИЯ

1.1. Классификация распространяется на ПО, предназначенное для защиты информации ограниченного доступа.

1.2. Устанавливается четыре уровня контроля отсутствия недекларированных возможностей. Каждый уровень характеризуется определенной минимальной совокупностью требований.

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

1.4. Самый высокий уровень контроля - первый, достаточен для ПО, используемого при защите информации с грифом «ОВ».

Второй уровень контроля достаточен для ПО, используемого при защите информации с грифом «CC».

Третий уровень контроля достаточен для ПО, используемого при защите информации с грифом «C».

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

2. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ

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

Реализацией недекларированных возможностей, в частности, являются программные закладки.

2.2. Программные закладки – преднамеренно внесенные в ПО функциональные объекты, которые при определенных условиях (входных данных) инициируют выполнение не описанных в документации функций ПО, приводящих к нарушению конфиденциальности, доступности или целостности обрабатываемой информации.

2.3. Функциональный объект – элемент программы, осуществляющий выполнение действий по реализации законченного фрагмента алгоритма программы.

В качестве функциональных объектов могут выступать процедуры, функции, ветви, операторы и т.п.

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

2.5. Маршрут выполнения функциональных объектов – определенная алгоритмом последовательность выполняемых функциональных объектов.

2.6. Фактический маршрут выполнения функциональных объектов – последовательность фактически выполняемых функциональных объектов при определённых условиях (входных данных).

2.7. Критический маршрут выполнения функциональных объектов – такой маршрут, при выполнении которого существует возможность неконтролируемого нарушения установленных правил обработки информационных объектов.

2.8. Статический анализ исходных текстов программ – совокупность методов контроля (не)соответствия реализованных и декларированных в документации функциональных возможностей ПО, основанных на структурном анализе и декомпозиции исходных текстов программ.

2.9. Динамический анализ исходных текстов программ – совокупность методов контроля (не)соответствия реализованных и декларированных в документации функциональных возможностей ПО, основанных на идентификации фактических маршрутов выполнения функциональных объектов с последующим сопоставлением маршрутам, построенным в процессе проведения статического анализа.

3.ТРЕБОВАНИЯ К УРОВНЮ КОНТРОЛЯ

3.1. ПЕРЕЧЕНЬ ТРЕБОВАНИЙ

Таблица 1.

Обозначения

"-" - нет требований к данному уровню;

"+" - новые или дополнительные требования;

"=" - требования совпадают с требованиями предыдущего уровня.

3.2. ТРЕБОВАНИЯ К ЧЕТВЕРТОМУ УРОВНЮ КОНТРОЛЯ

3.2.1.Контроль состава и содержания документации

В состав документации, представляемой заявителем, должны входить:

Спецификация (ГОСТ 19.202-78), содержащая сведения о составе ПО и документации на него;

Описание программы (ГОСТ 19.402-78), содержащее основные сведения о составе (с указанием контрольных сумм файлов, входящих в состав ПО), логической структуре и среде функционирования ПО, а также описание методов, приемов и правил эксплуатации средств технологического оснащения при создании ПО;

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

Исходные тексты программ (ГОСТ 19.401-78), входящих в состав ПО.

Для ПО импортного производства состав документации может отличаться от требуемого, однако содержание должно соответствовать требованиям указанных ГОСТ.

3.2.2. Контроль исходного состояния ПО

Контроль заключается в фиксации исходного состояния ПО и сравнении полученных результатов с приведенными в документации.

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

Контрольные суммы должны рассчитываться для каждого файла, входящего в состав ПО.

3.2.3. Статический анализ исходных текстов программ

Статический анализ исходных текстов программ должен включать следующие технологические операции:

Контроль полноты и отсутствия избыточности исходных текстов ПО на уровне файлов;

Контроль соответствия исходных текстов ПО его объектному (загрузочному) коду.

3.2.4. Отчетность

По окончании испытаний оформляется отчет (протокол), содержащий результаты:

Контроля исходного состояния ПО;

Контроля полноты и отсутствия избыточности исходных текстов контролируемого ПО на уровне файлов;

Контроля соответствия исходных текстов ПО его объектному (загрузочному) коду.

3.3.ТРЕБОВАНИЯ К ТРЕТЬЕМУ УРОВНЮ КОНТРОЛЯ

3.3.1.Контроль состава и содержания документации

Требования полностью включают в себя аналогичные требования к четвертому уровню контроля.

Кроме того, должна быть представлена «Пояснительная записка» (ГОСТ 19.404-79), содержащая основные сведения о назначении компонентов, входящих в состав ПО, параметрах обрабатываемых наборов данных (подсхемах баз данных), формируемых кодах возврата, описание используемых переменных, алгоритмов функционирования и т.п.

3.3.2.Контроль исходного состояния ПО

Требования полностью включают в себя аналогичные требования к четвёртому уровню контроля.

3.3.3.Статический анализ исходных текстов программ

Кроме аналогичных требований, предъявляемых к четвёртому уровню контроля, дополнительно предъявляются следующие требования:

Контроль полноты и отсутствия избыточности исходных текстов ПО на уровне функциональных объектов (процедур);

Контроль связей функциональных объектов (модулей, процедур, функций) по управлению;

Контроль связей функциональных объектов (модулей, процедур, функций) по информации;

Контроль информационных объектов различных типов (например, локальных переменных, глобальных переменных, внешних переменных и т.п.);

Формирование перечня маршрутов выполнения функциональных объектов (процедур, функций).

3.3.4. Динамический анализ исходных текстов программ

Динамический анализ исходных текстов программ должен включать следующие технологические операции:

Контроль выполнения функциональных объектов (процедур, функций);

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

3.3.5. Отчетность

Кроме аналогичных требований, предъявляемых к четвертому уровню контроля, дополнительно отчет (протокол) должен содержать результаты:

Контроля полноты и отсутствия избыточности исходных текстов контролируемого ПО на уровне функциональных объектов (процедур);

Контроля связей функциональных объектов (модулей, процедур, функций) по управлению;

Контроля связей функциональных объектов (модулей, процедур, функций) по информации;

Контроля информационных объектов различных типов (например, локальных переменных, глобальных переменных, внешних переменных и т.п.);

Формирования перечня маршрутов выполнения функциональных объектов (процедур, функций);

Контроля выполнения функциональных объектов (процедур, функций);

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

3.4. ТРЕБОВАНИЯ КО ВТОРОМУ УРОВНЮ КОНТРОЛЯ

3.4.1.Контроль состава и содержания документации

3.4.2.Контроль исходного состояния ПО

Требования полностью включают в себя аналогичные требования к третьему уровню контроля.

3.4.3. Статический анализ исходных текстов программ

Контроль полноты и отсутствия избыточности исходных текстов контролируемого программного обеспечения на уровне функциональных объектов (функций);

Синтаксический контроль наличия заданных конструкций в исходных текстах ПО из списка (базы) потенциально опасных программных конструкций;

Формирование перечня маршрутов выполнения функциональных объектов (ветвей);

Анализ критических маршрутов выполнения функциональных объектов (процедур, функций) для заданных экспертом списков информационных объектов;

Построение по исходным текстам контролируемого ПО блок-схем, диаграмм и т.п., и последующий сравнительный анализ алгоритма работы функциональных объектов (процедур, функций) и алгоритма работы, приведенного в “Пояснительной записке”.

3.4.4. Динамический анализ исходных текстов программ

Кроме аналогичных требований, предъявляемых к третьему уровню контроля, дополнительно предъявляются следующие требования:

Контроль выполнения функциональных объектов (ветвей);

Сопоставление фактических маршрутов выполнения функциональных объектов (ветвей) и маршрутов, построенных в процессе проведения статического анализа

3.4.5 Отчетность

Кроме аналогичных требований, предъявляемых к третьему уровню контроля, дополнительно отчет (протокол) должен содержать результаты:

Контроля полноты и отсутствия избыточности исходных текстов контролируемого программного обеспечения на уровне функциональных объектов (функций);

Синтаксического контроля наличия заданных конструкций в исходных текстах ПО из списка (базы) потенциально опасных конструкций;

Формирования перечня маршрутов выполнения функциональных объектов (ветвей);

Анализа критических маршрутов выполнения функциональных объектов (процедур, функций) для заданных экспертом списков информационных объектов;

Построения по исходным текстам контролируемого ПО блок-схем, диаграмм и т.п., и последующего сравнительного анализа алгоритма работы функциональных объектов (процедур, функций) и алгоритма работы, приведённого в “Пояснительной записке”;

Контроля выполнения функциональных объектов (ветвей);

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

3.5. ТРЕБОВАНИЯ К ПЕРВОМУ УРОВНЮ КОНТРОЛЯ

3.5.1. Контроль состава и содержания документации

3.5.2. Контроль исходного состояния ПО

Требования полностью включают в себя аналогичные требования ко второму уровню контроля.

3.5.3. Статический анализ исходных текстов программ

Кроме аналогичных требований, предъявляемых ко второму уровню контроля, дополнительно предъявляются следующие требования:

Контроль соответствия исходных текстов ПО его объектному (загрузочному) коду с использованием сертифицированных компиляторов;

Семантический контроль наличия заданных конструкций в исходных текстах ПО

3.5.4. Динамический анализ исходных текстов программ

Требования полностью включают в себя аналогичные требования ко второму уровню контроля.

3.5.5. Отчетность

Кроме аналогичных требований, предъявляемых ко второму уровню контроля, дополнительно отчет (протокол) должен содержать результаты:

Контроля соответствия исходных текстов ПО его объектному (загрузочному) коду с использованием сертифицированных компиляторов;

Семантического контроля наличия заданных конструкций в исходных текстах ПО из списка (базы) потенциально опасных конструкций.

Контроль недекларированных возможностей

Максим Репин
Специалист ОАО "Концерн "БЕГА"

Анастасия Сакулина
Специалист ОАО "Концерн "БЕГА"

В наше время в связи с увеличением случаев утечек конфиденциальной информации (КИ) основным становится вопрос о ее надежной защите.

В отличие от государственной тайны и персональных данных, документы регуляторов в области защиты КИ носят рекомендательный характер, поэтому возникает естественный вопрос: следовать им или нет?

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

Уровни контроля отсутствия НДВ

Существуют четыре уровня контроля отсутствия НДВ. Для защиты КИ обычно используют 4-й уровень, но также можно использовать и 3-й уровень, включающий более тщательный анализ отсутствия НДВ.

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

Мы часто слышим следующие аргументы в пользу сертификации:

• сертифицированное ПО корректно выполняет свои функции защиты информации;
• сертифицированное ПО гарантирует отсутствие встроенных механизмов, которые могут нанести вред информации заказчика.

На практике наличие сертификата у ПО не всегда обеспечивает выполнение этих утверждений.

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

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

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

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

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

Парадокс проблемы наличия в продукте программных закладок (ПЗ)

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

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

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

На данный момент для построения действительно надежной системы защиты лучше вложить деньги в грамотных и проверенных системных администраторов и консультантов. Их знания и опыт помогут выбрать наиболее надежные и подходящие именно для конкретной фирмы решения.

Статьи по теме

Защита от несанкционированного доступа к информации Часть 1. Программное обеспечение средств защиты информации

Классификация по уровню контроля отсутствия недекларированных возможностей

Утверждено решением председателя Государственной технической комиссии при Президенте Российской Федерации от 4 июня 1999 г. N 114

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

Действие документа не распространяется на программное обеспечение средств криптографической защиты информации.

Уровень контроля определяется выполнением заданного настоящим РД набора требований, предъявляемого:
- к составу и содержанию документации, представляемой заявителем для проведения испытаний ПО СЗИ;
- к содержанию испытаний.

Руководящий документ разработан в дополнение:
- РД «Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации», М., Военное издательство, 1992 г.;
- РД «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации», М., Военное издательство, 1992 г.;
- РД «Средства вычислительной техники. Межсетевые экраны. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации», М., 1997 г.

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

1. ОБЩИЕ ПОЛОЖЕНИЯ

1.1. Классификация распространяется на ПО, предназначенное для защиты информации ограниченного доступа.

1.2. Устанавливается четыре уровня контроля отсутствия недекларированных возможностей. Каждый уровень характеризуется определенной минимальной совокупностью требований.

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

1.4. Самый высокий уровень контроля - первый, достаточен для ПО, используемого при защите информации с грифом «ОВ».

Второй уровень контроля достаточен для ПО, используемого при защите информации с грифом «CC».

Третий уровень контроля достаточен для ПО, используемого при защите информации с грифом «C».

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

2. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ

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

Реализацией недекларированных возможностей, в частности, являются программные закладки.

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

2.3. Функциональный объект - элемент программы, осуществляющий выполнение действий по реализации законченного фрагмента алгоритма программы.

В качестве функциональных объектов могут выступать процедуры, функции, ветви, операторы и т.п.

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

2.5. Маршрут выполнения функциональных объектов - определенная алгоритмом последовательность выполняемых функциональных объектов.

2.6. Фактический маршрут выполнения функциональных объектов - последовательность фактически выполняемых функциональных объектов при определённых условиях (входных данных).

2.7. Критический маршрут выполнения функциональных объектов - такой маршрут, при выполнении которого существует возможность неконтролируемого нарушения установленных правил обработки информационных объектов.

2.8. Статический анализ исходных текстов программ - совокупность методов контроля (не)соответствия реализованных и декларированных в документации функциональных возможностей ПО, основанных на структурном анализе и декомпозиции исходных текстов программ.

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

3. ТРЕБОВАНИЯ К УРОВНЮ КОНТРОЛЯ
3.1. ПЕРЕЧЕНЬ ТРЕБОВАНИЙ

Таблица 1

Обозначения
"-" - нет требований к данному уровню;
"+" - новые или дополнительные требования;
"=" - требования совпадают с требованиями предыдущего уровня.

3.2. ТРЕБОВАНИЯ К ЧЕТВЕРТОМУ УРОВНЮ КОНТРОЛЯ

3.2.1.Контроль состава и содержания документации

В состав документации, представляемой заявителем, должны входить:

Спецификация (ГОСТ 19.202-78), содержащая сведения о составе ПО и документации на него;

Описание программы (ГОСТ 19.402-78), содержащее основные сведения о составе (с указанием контрольных сумм файлов, входящих в состав ПО), логической структуре и среде функционирования ПО, а также описание методов, приемов и правил эксплуатации средств технологического оснащения при создании ПО;

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

Исходные тексты программ (ГОСТ 19.401-78), входящих в состав ПО.

Для ПО импортного производства состав документации может отличаться от требуемого, однако содержание должно соответствовать требованиям указанных ГОСТ.

3.2.2. Контроль исходного состояния ПО

Контроль заключается в фиксации исходного состояния ПО и сравнении полученных результатов с приведенными в документации.

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

Контрольные суммы должны рассчитываться для каждого файла, входящего в состав ПО.

3.2.3. Статический анализ исходных текстов программ

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

3.2.4. Отчетность

По окончании испытаний оформляется отчет (протокол), содержащий результаты:
- контроля исходного состояния ПО;
- контроля полноты и отсутствия избыточности исходных текстов контролируемого ПО на уровне файлов;
- контроля соответствия исходных текстов ПО его объектному (загрузочному) коду.

3.3.ТРЕБОВАНИЯ К ТРЕТЬЕМУ УРОВНЮ КОНТРОЛЯ

3.3.1.Контроль состава и содержания документации

Требования полностью включают в себя аналогичные требования к четвертому уровню контроля.

Кроме того, должна быть представлена «Пояснительная записка» (ГОСТ 19.404-79), содержащая основные сведения о назначении компонентов, входящих в состав ПО, параметрах обрабатываемых наборов данных (подсхемах баз данных), формируемых кодах возврата, описание используемых переменных, алгоритмов функционирования и т.п.

3.3.2.Контроль исходного состояния ПО

Требования полностью включают в себя аналогичные требования к четвёртому уровню контроля.

3.3.3.Статический анализ исходных текстов программ

Кроме аналогичных требований, предъявляемых к четвёртому уровню контроля, дополнительно предъявляются следующие требования:
- контроль полноты и отсутствия избыточности исходных текстов ПО на уровне функциональных объектов (процедур);
- контроль связей функциональных объектов (модулей, процедур, функций) по управлению;
- контроль связей функциональных объектов (модулей, процедур, функций) по информации;
- контроль информационных объектов различных типов (например, локальных переменных, глобальных переменных, внешних переменных и т.п.);
- формирование перечня маршрутов выполнения функциональных объектов (процедур, функций).

3.3.4. Динамический анализ исходных текстов программ

Динамический анализ исходных текстов программ должен включать следующие технологические операции:
- контроль выполнения функциональных объектов (процедур, функций);
- сопоставление фактических маршрутов выполнения функциональных объектов (процедур, функций) и маршрутов, построенных в процессе проведения статического анализа.

3.3.5. Отчетность

Кроме аналогичных требований, предъявляемых к четвертому уровню контроля, дополнительно отчет (протокол) должен содержать результаты:
- контроля полноты и отсутствия избыточности исходных текстов контролируемого ПО на уровне функциональных объектов (процедур);
- контроля связей функциональных объектов (модулей, процедур, функций) по управлению;
- контроля связей функциональных объектов (модулей, процедур, функций) по информации;
- контроля информационных объектов различных типов (например, локальных переменных, глобальных переменных, внешних переменных и т.п.);
- формирования перечня маршрутов выполнения функциональных объектов (процедур, функций);
- контроля выполнения функциональных объектов (процедур, функций);
- сопоставления фактических маршрутов выполнения функциональных объектов (процедур, функций) и маршрутов, построенных в процессе проведения статического анализа.

3.4. ТРЕБОВАНИЯ КО ВТОРОМУ УРОВНЮ КОНТРОЛЯ

3.4.1.Контроль состава и содержания документации

3.4.2.Контроль исходного состояния ПО

Требования полностью включают в себя аналогичные требования к третьему уровню контроля.

3.4.3. Статический анализ исходных текстов программ

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

3.4.4. Динамический анализ исходных текстов программ

Кроме аналогичных требований, предъявляемых к третьему уровню контроля, дополнительно предъявляются следующие требования:
- контроль выполнения функциональных объектов (ветвей);
- сопоставление фактических маршрутов выполнения функциональных объектов (ветвей) и маршрутов, построенных в процессе проведения статического анализа

3.4.5 Отчетность

Кроме аналогичных требований, предъявляемых к третьему уровню контроля, дополнительно отчет (протокол) должен содержать результаты:
- контроля полноты и отсутствия избыточности исходных текстов контролируемого программного обеспечения на уровне функциональных объектов (функций);
- синтаксического контроля наличия заданных конструкций в исходных текстах ПО из списка (базы) потенциально опасных конструкций;
- формирования перечня маршрутов выполнения функциональных объектов (ветвей);
- анализа критических маршрутов выполнения функциональных объектов (процедур, функций) для заданных экспертом списков информационных объектов;
- построения по исходным текстам контролируемого ПО блок-схем, диаграмм и т.п., и последующего сравнительного анализа алгоритма работы функциональных объектов (процедур, функций) и алгоритма работы, приведённого в “Пояснительной записке”;
- контроля выполнения функциональных объектов (ветвей);
- сопоставления фактических маршрутов выполнения функциональных объектов (ветвей) и маршрутов, построенных в процессе проведения статического анализа.

3.5. ТРЕБОВАНИЯ К ПЕРВОМУ УРОВНЮ КОНТРОЛЯ

3.5.1. Контроль состава и содержания документации

3.5.2. Контроль исходного состояния ПО

Требования полностью включают в себя аналогичные требования ко второму уровню контроля.

3.5.3. Статический анализ исходных текстов программ

Кроме аналогичных требований, предъявляемых ко второму уровню контроля, дополнительно предъявляются следующие требования:
- контроль соответствия исходных текстов ПО его объектному (загрузочному) коду с использованием сертифицированных компиляторов;
- семантический контроль наличия заданных конструкций в исходных текстах ПО из списка (базы) потенциально опасных конструкций.

3.5.4. Динамический анализ исходных текстов программ

Требования полностью включают в себя аналогичные требования ко второму уровню контроля.

3.5.5. Отчетность

Кроме аналогичных требований, предъявляемых ко второму уровню контроля, дополнительно отчет (протокол) должен содержать результаты:
- контроля соответствия исходных текстов ПО его объектному (загрузочному) коду с использованием сертифицированных компиляторов;
- семантического контроля наличия заданных конструкций в исходных текстах ПО из списка (базы) потенциально опасных конструкций.

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

Начну, пожалуй, с середины - с проверки, которая называется "Контроль соответствия исходных текстов ПО его объектному (загрузочному) коду", данная проверка присутствует на всех уровнях контроля и одинакова для всех уровней, кроме первого - на нем появляется дополнение "с использованием сертифицированных компиляторов".

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

Итак, контроль соответствия исходных текстов объектному. Что же это такое? Всё просто - разработчик передает в испытательную лабораторию исходные тексты ПО и дистрибутив, при этом лаборатория должна убедиться, что исходные тексты соответствуют дистрибутиву. Сделать это, казалось бы, очень просто - компилируем исходные тексты, получаем объектные файлы, сравниваем их с дистрибутивом. Но на практике всё оказывается сложнее, разные компиляторы и сборщики работают по-разному.

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

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

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

Общая методика такова - контроль соответствия исходных текстов ПО его объектному (загрузочному) коду проводится с использованием программного комплекса фиксации и контроля исходного состояния ФИКС (или АК-ВС, ПИК и т.д.) путем выбора режима работы «Сравнение файлов» с настройкой «для *.exe». В случае обнаружения расхождений при сравнении файлов, данные файлы повторно сравниваются с помощью утилиты адаптивного сравнения бинарных файлов. Данное средство анализирует смещение блоков в бинарных файлах.

Средство написано на PHP, запускается из командной строки с двумя параметрами - путями к сравниваемым объектным файлам. Пример вывода (результатов работы):

Comparing file1.exe to file2.exe .

272700/272700 errors: 0 , warnings: 0

Warnings: 0/272700

Значения «Forward deep» и «Backward deep» - настраиваемые величины, дальность поиска блока в байтах, значение «Block size» - размер блоков. Данные величины подбираются экспертом в зависимости от типа бинарного файла и среды разработки и изменяются в коде файла bindiff.php с помощью любого текстового редактора. Возвращаемое значение «Errors» - количество различающихся байт, «Warnings» - количество передвижений блоков.

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

Если расхождения касаются служебной информации бинарных файлов и несущественно исполняемый код (не влияют на процесс выполнения), данные расхождения не являются несоответствием и проверка считается пройденной.

Утилита доступна на GitHub , лицензия - GNU GPL v.3. Форки, пуллреквесты и комментарии приветствуются.

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

Коллеги, прошу высказывать своё мнение по данной проверки и возможности её использования при сертификации в системе ФСТЭК.