контроль соответствия исходных текстов по его объектному загрузочному коду
Контроль исходного состояния ПО
Контроль исходного состояния ПО производится путем идентификации испытуемого образца программы (см. параграф 8.2) в соответствии с требованиями нормативного документа [15].
Контроль исходного состояния заключается в фиксации состояния всего ПО и сравнении полученных результатов с результатами, приведенными в документации.
Результатами контроля исходного состояния должны быть рассчитанные уникальные значения контрольных сумм исходных текстов программ, исполняемых и загрузочных модулей, входящих в состав ПО. Контрольные суммы должны рассчитываться для каждого файла, входящего в состав ПО.
Результаты контрольного суммирования оформляются в виде электронных приложений к протоколу сертификационных испытаний.
Статический анализ исходных текстов программ
Статический анализ исходных текстов программ предполагает проведение следующих технологических операций:
Контроль соответствия исходных текстов ПО объектному (загрузочному) коду производится на основе представленных на испытания описаний программ.В присутствии представителей Заявителя проводится контрольная компиляция исходных текстов и сборка всех загрузочных модулей ПО. С помощью программы ФИКС фиксируются размер, дата записи и контрольная сумма представленных и собранных объектных (загрузочных) файлов. Оформляется Акт сборки ПО, в котором результаты сравнения представляются в виде табл. 8.8.
Имя объектного (загрузочного) модуля
Размер представленного файла
Размер модуля (в байтах), представленного для проведения испытаний
Размер собранного файла
Размер модуля (в байтах), собранного в процессе испытаний
Дата записи модуля, представленного для проведения испытаний, в формате: час, минута, секунда, день, месяц и год записи
Дата записи собранного файла
Дата записи модуля, собранного в процессе испытаний, в формате:
час, минута, секунда, день, месяц и год записи
Контрольная сумма представленного файла
Контрольная сумма файла по алгоритму вычисления контрольных сумм (ВКС) в шестнадцатеричном формате, представленного для проведения испытаний
Контрольная сумма собранного файла
Контрольная сумма файла по алгоритму ВКС в шестнадцатеричном формате, собранного в процессе испытаний
Проставляется отметка «одинаковы», если при сравнении контрольные суммы файлов оказались идентичными. Если в результате сравнения обнаружены различия, указывается количество различий, а также предпринятое действие для установления соответствия модулей и вывод о соответствии модулей
Контроль полноты и отсутствия избыточности исходных текстов осуществляется на основании регистрации факта успешной компиляции и сборки исполняемых файлов всех компонентов ПО.
Полученные в результате компиляции исполняемые (загрузочные) модули сравниваются при помощи программы ФИКС с соответствующими модулями, представленными на испытания в составе исполняемого ПО. В случае совпадения сравниваемых модулей делается вывод о соответствии исходных текстов ПО его объектному (загрузочному) коду. В случае несовпаденияпроводится анализ характера обнаруженных различий с точки зрения их влияния на логику выполнения программы. По результатам анализа делается вывод о соответствии или несоответствии представленных исходных текстов полученным программным модулям.
Результаты контрольной компиляции и сборки ПО оформляются в виде электронного приложения к протоколу сертификационных испытаний.
Контроль полноты исходных текстов ПО. Полнота исходных текстов ПО подтверждается фактом успешной сборки всех компонентов типового ПО и контрольного примера с учетом установленного соответствия исходных текстов объектному (загрузочному) коду.
Контроль отсутствия избыточности исходных текстов производится путем сравнения перечня функциональных объектов, определенных в файлах исходных текстов, с перечнем функциональных объектов, код которых содержится в исполняемом (загрузочном) коде.
Контроль избыточности исходных текстов на уровне функциональных объектов осуществляется путем выявления факта наличия кода функционального объекта в исполняемом (загрузочном) файле. Функциональные объекты, код которых не вошел в исполняемые (загрузочные) модули, полученные в результате контрольной сборки ПО, признаются избыточными.
Файлы исходных текстов, не содержащие определения ни одного функционального объекта, код которого вошел в исполняемые (загрузочные) модули, признаются избыточными.
Результаты контроля оформляются в виде электронного приложения к протоколу сертификационных испытаний.
Контроль связей функциональных объектов по управлению, по информации и контроль информационных объектов выполняется посредством регистрации следующей информации:
Названные процедуры регистрации информации осуществляются для всех программных модулей ПО с помощью средств анализатора исходных текстов.
Результаты оформляются в виде электронного приложения к протоколу сертификационных испытаний.
Условия прекращения испытаний на начальном этапе. Таковыми являются:
Испытания могут быть возобновлены после устранения обнаруженных несоответствий и нарушений.
Объектные файлы исполняемых модулей, получаемые путем компиляции исходных текстов при проведении испытаний, могут отличаться от исполняемых модулей программного обеспечения, представленных на испытания, в части, касающейся служебной информации, генерируемой средой разработки, и зависящей от даты, времени и условий компиляции. Также ряд компиляторов при повторной сборке исходных текстов программ вносит изменения в порядок следования блоков команд, из-за чего бинарные файлы совпадают по содержимому и размеру, но отличаются при побайтовой проверке.
Что же делать в этой ситуации? Есть общепринятый метод и есть мой альтернативный способ. Общепринятый заключается в компиляции исходных текстов на территории разработчика и принятие полученного дистрибутива за эталонный, то есть сборка эталонного дистрибутива происходит не до передачи материалов в испытательную лабораторию, а уже после, под непосредственным контролем со стороны специалистов лаборатории, которые попутно собирают отчетные материалы для протоколов испытаний.
Comparing file1.exe [272700 bytes] to file2.exe [272700 bytes].
272700/272700 [100%] errors: 0 [0%], warnings: 0
Тут надо добавить, что вера в эту утилиту не должна быть абсолютной, в случае если расхождение подтверждается, несоответствующие блоки анализируются экспертом на предмет значимости и исполняемости различающегося кода. Для этого можно несколько раз повторить компиляцию на одном или разных компьютеров, вспомнить структуру PE-формата, ELF-формата и других (в зависимости от ОС и типа программы) и так далее.
Если расхождения касаются служебной информации бинарных файлов и несущественно исполняемый код (не влияют на процесс выполнения), данные расхождения не являются несоответствием и проверка считается пройденной.
Что касается правильности такого метода проверки с точки зрения органов по сертификации и федеральных органов, вопрос открытый. Я использовал эти проверки при проведении испытаний в системе сертификации МинОбороны и вопросов к данному методу со стороны сотрудников федерального органа по сертификации и привлеченных экспертов не последовало. Но система сертификации ФСТЭК отличается от МинОбороны, как минимум, в ней есть еще и обычные органы по сертификации, которые проверяют результаты испытаний, поэтому гарантировать прохождение данной проверки в таком виде я не могу.
Коллеги, прошу высказывать своё мнение по данной проверки и возможности её использования при сертификации в системе ФСТЭК.
Новости
Руководящий документ. Приказ председателя Гостехкомиссии России от 4 июня 1999 г. N 114
| 346 КБ | 110714 | |
| 164 КБ | 6860 |
Руководящий документ
Защита от несанкционированного доступа к информации Часть 1. Программное обеспечение средств защиты информации
Классификация по уровню контроля отсутствия недекларированных возможностей
Утверждено решением председателя Государственной технической комиссии при Президенте Российской Федерации от 4 июня 1999 г. N 114
Настоящий Руководящий документ (РД) устанавливает классификацию программного обеспечения (ПО) (как отечественного, так и импортного производства) средств защиты информации (СЗИ), в том числе и встроенных в общесистемное и прикладное ПО, по уровню контроля отсутствия в нем недекларированных возможностей.
Действие документа не распространяется на программное обеспечение средств криптографической защиты информации.
Уровень контроля определяется выполнением заданного настоящим РД набора требований, предъявляемого:
— к составу и содержанию документации, представляемой заявителем для проведения испытаний ПО СЗИ;
— к содержанию испытаний.
Руководящий документ разработан в дополнение:
— РД «Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации», М., Военное издательство, 1992 г.;
— РД «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации», М., Военное издательство, 1992 г.;
— РД «Средства вычислительной техники. Межсетевые экраны. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации», М., 1997 г.
Документ предназначен для специалистов испытательных лабораторий, заказчиков, разработчиков ПО СЗИ при его контроле в части отсутствия недекларированных возможностей.
1.1. Классификация распространяется на ПО, предназначенное для защиты информации ограниченного доступа.
1.2. Устанавливается четыре уровня контроля отсутствия недекларированных возможностей. Каждый уровень характеризуется определенной минимальной совокупностью требований.
1.3. Для ПО, используемого при защите информации, отнесенной к государственной тайне, должен быть обеспечен уровень контроля не ниже третьего.
Второй уровень контроля достаточен для ПО, используемого при защите информации с грифом «CC».
Третий уровень контроля достаточен для ПО, используемого при защите информации с грифом «C».
2. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ
Реализацией недекларированных возможностей, в частности, являются программные закладки.
2.2. Программные закладки – преднамеренно внесенные в ПО функциональные объекты, которые при определенных условиях (входных данных) инициируют выполнение не описанных в документации функций ПО, приводящих к нарушению конфиденциальности, доступности или целостности обрабатываемой информации.
2.3. Функциональный объект – элемент программы, осуществляющий выполнение действий по реализации законченного фрагмента алгоритма программы.
В качестве функциональных объектов могут выступать процедуры, функции, ветви, операторы и т.п.
2.5. Маршрут выполнения функциональных объектов – определенная алгоритмом последовательность выполняемых функциональных объектов.
2.6. Фактический маршрут выполнения функциональных объектов – последовательность фактически выполняемых функциональных объектов при определённых условиях (входных данных).
2.7. Критический маршрут выполнения функциональных объектов – такой маршрут, при выполнении которого существует возможность неконтролируемого нарушения установленных правил обработки информационных объектов.
2.8. Статический анализ исходных текстов программ – совокупность методов контроля (не)соответствия реализованных и декларированных в документации функциональных возможностей ПО, основанных на структурном анализе и декомпозиции исходных текстов программ.
2.9. Динамический анализ исходных текстов программ – совокупность методов контроля (не)соответствия реализованных и декларированных в документации функциональных возможностей ПО, основанных на идентификации фактических маршрутов выполнения функциональных объектов с последующим сопоставлением маршрутам, построенным в процессе проведения статического анализа.
3. ТРЕБОВАНИЯ К УРОВНЮ КОНТРОЛЯ
3.1. ПЕРЕЧЕНЬ ТРЕБОВАНИЙ
Требования к документации
Контроль состава и содержания документации
Спецификация (ГОСТ 19.202-78)
Описание программы (ГОСТ 19.402-78)
Описание применения (ГОСТ 19.502-78)
Пояснительная записка (ГОСТ 19.404-79)
Тексты программ, входящих в состав ПО (ГОСТ 19.401-78)
Требования к содержанию испытаний
Контроль исходного состояния ПО
Статический анализ исходных текстов программ
Контроль полноты и отсутствия избыточности исходных текстов
Контроль соответствия исходных текстов ПО его объектному (загрузочному) коду
Контроль связей функциональных объектов по управлению
Контроль связей функциональных объектов по информации
Контроль информационных объектов
Контроль наличия заданных конструкций в исходных текстах
Формирование перечня маршрутов выполнения функциональных объектов
Анализ критических маршрутов выполнения функциональных объектов
Анализ алгоритма работы функциональных объектов на основе блок-схем, диаграмм и т. п., построенных по исходным текстам контролируемого ПО
Динамический анализ исходных текстов программ
Контроль выполнения функциональных объектов
Сопоставление фактических маршрутов выполнения функциональных объектов и маршрутов, построенных в процессе проведения статического анализа
3.2. ТРЕБОВАНИЯ К ЧЕТВЕРТОМУ УРОВНЮ КОНТРОЛЯ
3.2.1.Контроль состава и содержания документации
В состав документации, представляемой заявителем, должны входить:
Спецификация (ГОСТ 19.202-78), содержащая сведения о составе ПО и документации на него;
Описание программы (ГОСТ 19.402-78), содержащее основные сведения о составе (с указанием контрольных сумм файлов, входящих в состав ПО), логической структуре и среде функционирования ПО, а также описание методов, приемов и правил эксплуатации средств технологического оснащения при создании ПО;
Описание применения (ГОСТ 19.502-78), содержащее сведения о назначении ПО, области применения, применяемых методах, классе решаемых задач, ограничениях при применении, минимальной конфигурации технических средств, среде функционирования и порядке работы.
Исходные тексты программ (ГОСТ 19.401-78), входящих в состав ПО.
Для ПО импортного производства состав документации может отличаться от требуемого, однако содержание должно соответствовать требованиям указанных ГОСТ.
3.2.2. Контроль исходного состояния ПО
Контроль заключается в фиксации исходного состояния ПО и сравнении полученных результатов с приведенными в документации.
Результатами контроля исходного состояния ПО должны быть рассчитанные уникальные значения контрольных сумм загрузочных модулей и исходных текстов программ, входящих в состав ПО.
Контрольные суммы должны рассчитываться для каждого файла, входящего в состав ПО.
3.2.3. Статический анализ исходных текстов программ
Статический анализ исходных текстов программ должен включать следующие технологические операции:
— контроль полноты и отсутствия избыточности исходных текстов ПО на уровне файлов;
— контроль соответствия исходных текстов ПО его объектному (загрузочному) коду.
По окончании испытаний оформляется отчет (протокол), содержащий результаты:
— контроля исходного состояния ПО;
— контроля полноты и отсутствия избыточности исходных текстов контролируемого ПО на уровне файлов;
— контроля соответствия исходных текстов ПО его объектному (загрузочному) коду.
3.3.ТРЕБОВАНИЯ К ТРЕТЬЕМУ УРОВНЮ КОНТРОЛЯ
3.3.1.Контроль состава и содержания документации
Требования полностью включают в себя аналогичные требования к четвертому уровню контроля.
Кроме того, должна быть представлена «Пояснительная записка» (ГОСТ 19.404-79), содержащая основные сведения о назначении компонентов, входящих в состав ПО, параметрах обрабатываемых наборов данных (подсхемах баз данных), формируемых кодах возврата, описание используемых переменных, алгоритмов функционирования и т.п.
3.3.2.Контроль исходного состояния ПО
Требования полностью включают в себя аналогичные требования к четвёртому уровню контроля.
3.3.3.Статический анализ исходных текстов программ
Кроме аналогичных требований, предъявляемых к четвёртому уровню контроля, дополнительно предъявляются следующие требования:
— контроль полноты и отсутствия избыточности исходных текстов ПО на уровне функциональных объектов (процедур);
— контроль связей функциональных объектов (модулей, процедур, функций) по управлению;
— контроль связей функциональных объектов (модулей, процедур, функций) по информации;
— контроль информационных объектов различных типов (например, локальных переменных, глобальных переменных, внешних переменных и т.п.);
— формирование перечня маршрутов выполнения функциональных объектов (процедур, функций).
3.3.4. Динамический анализ исходных текстов программ
Динамический анализ исходных текстов программ должен включать следующие технологические операции:
— контроль выполнения функциональных объектов (процедур, функций);
— сопоставление фактических маршрутов выполнения функциональных объектов (процедур, функций) и маршрутов, построенных в процессе проведения статического анализа.
Кроме аналогичных требований, предъявляемых к четвертому уровню контроля, дополнительно отчет (протокол) должен содержать результаты:
— контроля полноты и отсутствия избыточности исходных текстов контролируемого ПО на уровне функциональных объектов (процедур);
— контроля связей функциональных объектов (модулей, процедур, функций) по управлению;
— контроля связей функциональных объектов (модулей, процедур, функций) по информации;
— контроля информационных объектов различных типов (например, локальных переменных, глобальных переменных, внешних переменных и т.п.);
— формирования перечня маршрутов выполнения функциональных объектов (процедур, функций);
— контроля выполнения функциональных объектов (процедур, функций);
— сопоставления фактических маршрутов выполнения функциональных объектов (процедур, функций) и маршрутов, построенных в процессе проведения статического анализа.
3.4. ТРЕБОВАНИЯ КО ВТОРОМУ УРОВНЮ КОНТРОЛЯ
3.4.1.Контроль состава и содержания документации
Требования полностью включают в себя аналогичные требования к третьему уровню контроля.
3.4.2.Контроль исходного состояния ПО
Требования полностью включают в себя аналогичные требования к третьему уровню контроля.
3.4.3. Статический анализ исходных текстов программ
Кроме аналогичных требований, предъявляемых к третьему уровню контроля, дополнительно предъявляются следующие требования:
— контроль полноты и отсутствия избыточности исходных текстов контролируемого программного обеспечения на уровне функциональных объектов (функций);
— синтаксический контроль наличия заданных конструкций в исходных текстах ПО из списка (базы) потенциально опасных программных конструкций;
— формирование перечня маршрутов выполнения функциональных объектов (ветвей);
— анализ критических маршрутов выполнения функциональных объектов (процедур, функций) для заданных экспертом списков информационных объектов;
— построение по исходным текстам контролируемого ПО блок-схем, диаграмм и т.п., и последующий сравнительный анализ алгоритма работы функциональных объектов (процедур, функций) и алгоритма работы, приведенного в “Пояснительной записке”.
3.4.4. Динамический анализ исходных текстов программ
Кроме аналогичных требований, предъявляемых к третьему уровню контроля, дополнительно предъявляются следующие требования:
— контроль выполнения функциональных объектов (ветвей);
— сопоставление фактических маршрутов выполнения функциональных объектов (ветвей) и маршрутов, построенных в процессе проведения статического анализа
Кроме аналогичных требований, предъявляемых к третьему уровню контроля, дополнительно отчет (протокол) должен содержать результаты:
— контроля полноты и отсутствия избыточности исходных текстов контролируемого программного обеспечения на уровне функциональных объектов (функций);
— синтаксического контроля наличия заданных конструкций в исходных текстах ПО из списка (базы) потенциально опасных конструкций;
— формирования перечня маршрутов выполнения функциональных объектов (ветвей);
— анализа критических маршрутов выполнения функциональных объектов (процедур, функций) для заданных экспертом списков информационных объектов;
— построения по исходным текстам контролируемого ПО блок-схем, диаграмм и т.п., и последующего сравнительного анализа алгоритма работы функциональных объектов (процедур, функций) и алгоритма работы, приведённого в “Пояснительной записке”;
— контроля выполнения функциональных объектов (ветвей);
— сопоставления фактических маршрутов выполнения функциональных объектов (ветвей) и маршрутов, построенных в процессе проведения статического анализа.
3.5. ТРЕБОВАНИЯ К ПЕРВОМУ УРОВНЮ КОНТРОЛЯ
3.5.1. Контроль состава и содержания документации
Требования полностью включают в себя аналогичные требования ко второму уровню контроля.
3.5.2. Контроль исходного состояния ПО
Требования полностью включают в себя аналогичные требования ко второму уровню контроля.
3.5.3. Статический анализ исходных текстов программ
Кроме аналогичных требований, предъявляемых ко второму уровню контроля, дополнительно предъявляются следующие требования:
— контроль соответствия исходных текстов ПО его объектному (загрузочному) коду с использованием сертифицированных компиляторов;
— семантический контроль наличия заданных конструкций в исходных текстах ПО из списка (базы) потенциально опасных конструкций.
3.5.4. Динамический анализ исходных текстов программ
Требования полностью включают в себя аналогичные требования ко второму уровню контроля.
Кроме аналогичных требований, предъявляемых ко второму уровню контроля, дополнительно отчет (протокол) должен содержать результаты:
— контроля соответствия исходных текстов ПО его объектному (загрузочному) коду с использованием сертифицированных компиляторов;
— семантического контроля наличия заданных конструкций в исходных текстах ПО из списка (базы) потенциально опасных конструкций.
Новости
Руководящий документ. Приказ председателя Гостехкомиссии России от 4 июня 1999 г. N 114
| 346 КБ | 110714 | |
| 164 КБ | 6860 |
Руководящий документ
Защита от несанкционированного доступа к информации Часть 1. Программное обеспечение средств защиты информации
Классификация по уровню контроля отсутствия недекларированных возможностей
Утверждено решением председателя Государственной технической комиссии при Президенте Российской Федерации от 4 июня 1999 г. N 114
Настоящий Руководящий документ (РД) устанавливает классификацию программного обеспечения (ПО) (как отечественного, так и импортного производства) средств защиты информации (СЗИ), в том числе и встроенных в общесистемное и прикладное ПО, по уровню контроля отсутствия в нем недекларированных возможностей.
Действие документа не распространяется на программное обеспечение средств криптографической защиты информации.
Уровень контроля определяется выполнением заданного настоящим РД набора требований, предъявляемого:
— к составу и содержанию документации, представляемой заявителем для проведения испытаний ПО СЗИ;
— к содержанию испытаний.
Руководящий документ разработан в дополнение:
— РД «Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации», М., Военное издательство, 1992 г.;
— РД «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации», М., Военное издательство, 1992 г.;
— РД «Средства вычислительной техники. Межсетевые экраны. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации», М., 1997 г.
Документ предназначен для специалистов испытательных лабораторий, заказчиков, разработчиков ПО СЗИ при его контроле в части отсутствия недекларированных возможностей.
1.1. Классификация распространяется на ПО, предназначенное для защиты информации ограниченного доступа.
1.2. Устанавливается четыре уровня контроля отсутствия недекларированных возможностей. Каждый уровень характеризуется определенной минимальной совокупностью требований.
1.3. Для ПО, используемого при защите информации, отнесенной к государственной тайне, должен быть обеспечен уровень контроля не ниже третьего.
Второй уровень контроля достаточен для ПО, используемого при защите информации с грифом «CC».
Третий уровень контроля достаточен для ПО, используемого при защите информации с грифом «C».
2. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ
Реализацией недекларированных возможностей, в частности, являются программные закладки.
2.2. Программные закладки – преднамеренно внесенные в ПО функциональные объекты, которые при определенных условиях (входных данных) инициируют выполнение не описанных в документации функций ПО, приводящих к нарушению конфиденциальности, доступности или целостности обрабатываемой информации.
2.3. Функциональный объект – элемент программы, осуществляющий выполнение действий по реализации законченного фрагмента алгоритма программы.
В качестве функциональных объектов могут выступать процедуры, функции, ветви, операторы и т.п.
2.5. Маршрут выполнения функциональных объектов – определенная алгоритмом последовательность выполняемых функциональных объектов.
2.6. Фактический маршрут выполнения функциональных объектов – последовательность фактически выполняемых функциональных объектов при определённых условиях (входных данных).
2.7. Критический маршрут выполнения функциональных объектов – такой маршрут, при выполнении которого существует возможность неконтролируемого нарушения установленных правил обработки информационных объектов.
2.8. Статический анализ исходных текстов программ – совокупность методов контроля (не)соответствия реализованных и декларированных в документации функциональных возможностей ПО, основанных на структурном анализе и декомпозиции исходных текстов программ.
2.9. Динамический анализ исходных текстов программ – совокупность методов контроля (не)соответствия реализованных и декларированных в документации функциональных возможностей ПО, основанных на идентификации фактических маршрутов выполнения функциональных объектов с последующим сопоставлением маршрутам, построенным в процессе проведения статического анализа.
3. ТРЕБОВАНИЯ К УРОВНЮ КОНТРОЛЯ
3.1. ПЕРЕЧЕНЬ ТРЕБОВАНИЙ
Требования к документации
Контроль состава и содержания документации
Спецификация (ГОСТ 19.202-78)
Описание программы (ГОСТ 19.402-78)
Описание применения (ГОСТ 19.502-78)
Пояснительная записка (ГОСТ 19.404-79)
Тексты программ, входящих в состав ПО (ГОСТ 19.401-78)
Требования к содержанию испытаний
Контроль исходного состояния ПО
Статический анализ исходных текстов программ
Контроль полноты и отсутствия избыточности исходных текстов
Контроль соответствия исходных текстов ПО его объектному (загрузочному) коду
Контроль связей функциональных объектов по управлению
Контроль связей функциональных объектов по информации
Контроль информационных объектов
Контроль наличия заданных конструкций в исходных текстах
Формирование перечня маршрутов выполнения функциональных объектов
Анализ критических маршрутов выполнения функциональных объектов
Анализ алгоритма работы функциональных объектов на основе блок-схем, диаграмм и т. п., построенных по исходным текстам контролируемого ПО
Динамический анализ исходных текстов программ
Контроль выполнения функциональных объектов
Сопоставление фактических маршрутов выполнения функциональных объектов и маршрутов, построенных в процессе проведения статического анализа
3.2. ТРЕБОВАНИЯ К ЧЕТВЕРТОМУ УРОВНЮ КОНТРОЛЯ
3.2.1.Контроль состава и содержания документации
В состав документации, представляемой заявителем, должны входить:
Спецификация (ГОСТ 19.202-78), содержащая сведения о составе ПО и документации на него;
Описание программы (ГОСТ 19.402-78), содержащее основные сведения о составе (с указанием контрольных сумм файлов, входящих в состав ПО), логической структуре и среде функционирования ПО, а также описание методов, приемов и правил эксплуатации средств технологического оснащения при создании ПО;
Описание применения (ГОСТ 19.502-78), содержащее сведения о назначении ПО, области применения, применяемых методах, классе решаемых задач, ограничениях при применении, минимальной конфигурации технических средств, среде функционирования и порядке работы.
Исходные тексты программ (ГОСТ 19.401-78), входящих в состав ПО.
Для ПО импортного производства состав документации может отличаться от требуемого, однако содержание должно соответствовать требованиям указанных ГОСТ.
3.2.2. Контроль исходного состояния ПО
Контроль заключается в фиксации исходного состояния ПО и сравнении полученных результатов с приведенными в документации.
Результатами контроля исходного состояния ПО должны быть рассчитанные уникальные значения контрольных сумм загрузочных модулей и исходных текстов программ, входящих в состав ПО.
Контрольные суммы должны рассчитываться для каждого файла, входящего в состав ПО.
3.2.3. Статический анализ исходных текстов программ
Статический анализ исходных текстов программ должен включать следующие технологические операции:
— контроль полноты и отсутствия избыточности исходных текстов ПО на уровне файлов;
— контроль соответствия исходных текстов ПО его объектному (загрузочному) коду.
По окончании испытаний оформляется отчет (протокол), содержащий результаты:
— контроля исходного состояния ПО;
— контроля полноты и отсутствия избыточности исходных текстов контролируемого ПО на уровне файлов;
— контроля соответствия исходных текстов ПО его объектному (загрузочному) коду.
3.3.ТРЕБОВАНИЯ К ТРЕТЬЕМУ УРОВНЮ КОНТРОЛЯ
3.3.1.Контроль состава и содержания документации
Требования полностью включают в себя аналогичные требования к четвертому уровню контроля.
Кроме того, должна быть представлена «Пояснительная записка» (ГОСТ 19.404-79), содержащая основные сведения о назначении компонентов, входящих в состав ПО, параметрах обрабатываемых наборов данных (подсхемах баз данных), формируемых кодах возврата, описание используемых переменных, алгоритмов функционирования и т.п.
3.3.2.Контроль исходного состояния ПО
Требования полностью включают в себя аналогичные требования к четвёртому уровню контроля.
3.3.3.Статический анализ исходных текстов программ
Кроме аналогичных требований, предъявляемых к четвёртому уровню контроля, дополнительно предъявляются следующие требования:
— контроль полноты и отсутствия избыточности исходных текстов ПО на уровне функциональных объектов (процедур);
— контроль связей функциональных объектов (модулей, процедур, функций) по управлению;
— контроль связей функциональных объектов (модулей, процедур, функций) по информации;
— контроль информационных объектов различных типов (например, локальных переменных, глобальных переменных, внешних переменных и т.п.);
— формирование перечня маршрутов выполнения функциональных объектов (процедур, функций).
3.3.4. Динамический анализ исходных текстов программ
Динамический анализ исходных текстов программ должен включать следующие технологические операции:
— контроль выполнения функциональных объектов (процедур, функций);
— сопоставление фактических маршрутов выполнения функциональных объектов (процедур, функций) и маршрутов, построенных в процессе проведения статического анализа.
Кроме аналогичных требований, предъявляемых к четвертому уровню контроля, дополнительно отчет (протокол) должен содержать результаты:
— контроля полноты и отсутствия избыточности исходных текстов контролируемого ПО на уровне функциональных объектов (процедур);
— контроля связей функциональных объектов (модулей, процедур, функций) по управлению;
— контроля связей функциональных объектов (модулей, процедур, функций) по информации;
— контроля информационных объектов различных типов (например, локальных переменных, глобальных переменных, внешних переменных и т.п.);
— формирования перечня маршрутов выполнения функциональных объектов (процедур, функций);
— контроля выполнения функциональных объектов (процедур, функций);
— сопоставления фактических маршрутов выполнения функциональных объектов (процедур, функций) и маршрутов, построенных в процессе проведения статического анализа.
3.4. ТРЕБОВАНИЯ КО ВТОРОМУ УРОВНЮ КОНТРОЛЯ
3.4.1.Контроль состава и содержания документации
Требования полностью включают в себя аналогичные требования к третьему уровню контроля.
3.4.2.Контроль исходного состояния ПО
Требования полностью включают в себя аналогичные требования к третьему уровню контроля.
3.4.3. Статический анализ исходных текстов программ
Кроме аналогичных требований, предъявляемых к третьему уровню контроля, дополнительно предъявляются следующие требования:
— контроль полноты и отсутствия избыточности исходных текстов контролируемого программного обеспечения на уровне функциональных объектов (функций);
— синтаксический контроль наличия заданных конструкций в исходных текстах ПО из списка (базы) потенциально опасных программных конструкций;
— формирование перечня маршрутов выполнения функциональных объектов (ветвей);
— анализ критических маршрутов выполнения функциональных объектов (процедур, функций) для заданных экспертом списков информационных объектов;
— построение по исходным текстам контролируемого ПО блок-схем, диаграмм и т.п., и последующий сравнительный анализ алгоритма работы функциональных объектов (процедур, функций) и алгоритма работы, приведенного в “Пояснительной записке”.
3.4.4. Динамический анализ исходных текстов программ
Кроме аналогичных требований, предъявляемых к третьему уровню контроля, дополнительно предъявляются следующие требования:
— контроль выполнения функциональных объектов (ветвей);
— сопоставление фактических маршрутов выполнения функциональных объектов (ветвей) и маршрутов, построенных в процессе проведения статического анализа
Кроме аналогичных требований, предъявляемых к третьему уровню контроля, дополнительно отчет (протокол) должен содержать результаты:
— контроля полноты и отсутствия избыточности исходных текстов контролируемого программного обеспечения на уровне функциональных объектов (функций);
— синтаксического контроля наличия заданных конструкций в исходных текстах ПО из списка (базы) потенциально опасных конструкций;
— формирования перечня маршрутов выполнения функциональных объектов (ветвей);
— анализа критических маршрутов выполнения функциональных объектов (процедур, функций) для заданных экспертом списков информационных объектов;
— построения по исходным текстам контролируемого ПО блок-схем, диаграмм и т.п., и последующего сравнительного анализа алгоритма работы функциональных объектов (процедур, функций) и алгоритма работы, приведённого в “Пояснительной записке”;
— контроля выполнения функциональных объектов (ветвей);
— сопоставления фактических маршрутов выполнения функциональных объектов (ветвей) и маршрутов, построенных в процессе проведения статического анализа.
3.5. ТРЕБОВАНИЯ К ПЕРВОМУ УРОВНЮ КОНТРОЛЯ
3.5.1. Контроль состава и содержания документации
Требования полностью включают в себя аналогичные требования ко второму уровню контроля.
3.5.2. Контроль исходного состояния ПО
Требования полностью включают в себя аналогичные требования ко второму уровню контроля.
3.5.3. Статический анализ исходных текстов программ
Кроме аналогичных требований, предъявляемых ко второму уровню контроля, дополнительно предъявляются следующие требования:
— контроль соответствия исходных текстов ПО его объектному (загрузочному) коду с использованием сертифицированных компиляторов;
— семантический контроль наличия заданных конструкций в исходных текстах ПО из списка (базы) потенциально опасных конструкций.
3.5.4. Динамический анализ исходных текстов программ
Требования полностью включают в себя аналогичные требования ко второму уровню контроля.
Кроме аналогичных требований, предъявляемых ко второму уровню контроля, дополнительно отчет (протокол) должен содержать результаты:
— контроля соответствия исходных текстов ПО его объектному (загрузочному) коду с использованием сертифицированных компиляторов;
— семантического контроля наличия заданных конструкций в исходных текстах ПО из списка (базы) потенциально опасных конструкций.