Контроль отсутствия недекларированных возможностей программного обеспечения является одним из видов испытаний, выполняемых испытательной лабораторией при сертификации изделий в системе сертификации Министерства Обороны Российской Федерации в соответствии с приказом 1996 года № 058.
В соответствии с определением, приведенным в «Толковом словаре современной компьютерной лексики» (В. Дорот, Ф. Новиков, Спб.: БХВ - Санкт-Петербург, 1999. – 384 с.,ил.) под программным обеспечением (далее по тексту – ПО) понимается совокупность входящих в состав вычислительной системы программных средств, т.е. программ, данных и документов к ним.
Под программным средством (далее по тексту ПС) в соответствии с ГОСТ 28195-89 «Оценка качества программных средств. Общие положения» понимается программа, предназначенная для многократного применения на различных объектах, разработанная любым способом и снабженная комплектом программных документов.
Целью контроля является формирование на основании анализа результатов проверочных действий заключения об отсутствии (наличии) недекларированных возможностей (далее по тексту – НДВ) программного обеспечения, в том числе отсутствия (наличия) программных закладок. Перечень проверочных действий, подлежащих выполнению в рамках конкретного уровня контроля, определяется положениями руководящего документа Гостехкомиссии России «Защита от несанкционированного доступа к информации. Часть 1. Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия недекларированных возможностей» (введен в действия Приказом Председателя Гостехкомиссии России № 114 от 04.06.1999 г., далее по тексту – РД НДВ).
РД НДВ устанавливает четыре уровня контроля программного обеспечения, отличающихся глубиной, объемом и условиями проведения испытаний. Наличие нескольких уровней контроля ПО при проведении испытаний на отсутствие НДВ, с одной стороны, регламентирует степень конфиденциальности информации, защита которой осуществляется ПО, проверенным по тому или иному уровню. С другой стороны, разные уровни контроля позволяют дифференцировать степень вероятности отсутствия в исследуемом ПО недекларированных возможностей.
Самый низкий уровень контроля - четвертый. Данный уровень предусмотрен для проверки ПО, используемого при защите (обработке, хранении, передаче и т.п.) конфиденциальной информации. Для ПО, используемого для защиты информации, отнесенной к государственной тайне, при проведении испытаний должен быть обеспечен уровень контроля не ниже третьего. Причем, в соответствии с требованиями отечественного законодательства для программных средств, предназначенных для обработки информации, составляющей государственную тайну, проведение испытаний по соответствующим уровням контроля отсутствия НДВ обязательно.
В соответствии с пунктом 2.1 РД НДВ под недекларированными возможностями понимаются функциональные возможности программного обеспечения (далее по тексту – ПО), не описанные или не соответствующие описанным в документации, при использовании которых возможно нарушение конфиденциальности, доступности или целостности обрабатываемой информации. Реализацией недекларированных возможностей, в частности, являются программные закладки.
В соответствии с пунктом 2.2 РД НДВ под программными закладками понимаются преднамеренно внесенные в ПО функциональные объекты, которые при определенных условиях (входных данных) инициируют выполнение не описанных в документации функций ПО, приводящих к нарушению конфиденциальности, доступности или целостности обрабатываемой информации.
Контроль отсутствия недекларированных возможностей программного обеспечения предполагает глубокое исследование программного обеспечения и связан с анализом как исполняемого кода, так и исходных текстов программ. Методологической основой таких исследований являются общие принципы анализа программ с учетом аспектов, связанных с информационной безопасностью.
РД НДВ не требует определения количественных характеристик программного обеспечения. Пример перечня качественных характеристик, оцениваемых при выполнении 3 уровня контроля в соответствии с РД НДВ, приведен в таблице 1.
Таблица 1 - Качественные характеристики, оцениваемые при выполнении испытаний
| № п/п | Требование РД НДВ | Пункт РД НДВ | Качественная характеристика | Метод исследований | Метод оценки |
| 1. | Контроль состава и содержания документации | 3.2.1 3.3.1 |
Соответствие требованиям, предъявляемым к составу и содержанию документации | Экспертиза документации | Заключение эксперта |
| 2. | Контроль исходного состояния ПО | 3.2.2 | Соответствие полученных результатов расчета контрольных сумм и фиксации файлов исходных текстов и дистрибутивов анализируемого ПО данным, приведенным в документации | Расчет контрольных сумм и фиксация размеров файлов исходных текстов и дистрибутивов компонентов ПО | Сравнительный анализ результатов расчета и фиксации с данными документации |
| 3. | Статический анализ исходных текстов программ | ||||
| 3.1. | Контроль полноты и отсутствия избыточности исходных текстов ПО на уровне файлов | 3.2.3 | Полнота и отсутствие избыточности исходных текстов ПО на уровне файлов | Выполнение контрольной сборки ПО. Выявление файлов, не участвующих в процессе сборки ПО | Заключение эксперта |
| 3.2. | Контроль соответствия исходных текстов ПО объектному (загрузочному) коду | 3.2.3 | Соответствие исходных текстов ПО объектному (загрузочному) коду | Анализ соответствия результатов контрольной сборки ПО исходным текстам ПО и данными документации | Заключение эксперта |
| 3.3. | Контроль полноты и отсутствия избыточности исходных текстов ПО на уровне функциональных объектов (процедур, функций) | 3.3.3 | Полнота и отсутствие избыточности исходных текстов ПО на уровне функциональных объектов (процедур, функций) | Выявление процедур (функций), которые в ПО только объявлены, но к которым нет обращений из функциональных объектов | Заключение эксперта |
| 3.4. | Контроль связей функциональных объектов (модулей, процедур, функций) по управлению | 3.3.3 | Отсутствие недекларированных в документации связей функциональных объектов (модулей,процедур, функций) по управлению | Выявление отношений по передачам управления между функциональ-ными объектами | Сравнительный анализ выявленных отношений с данными документации |
| 3.5. | Контроль полноты и отсутствия избыточности исходных текстов ПО на уровне типов информационных объектов | 3.3.3 | Полнота и отсутствие избыточности исходных текстов ПО на уровне типов информационных объектов | Выявление типов информационных объектов, которые только объявлены, но нигде не используются | Заключение эксперта |
| 3.6. | Контроль полноты и отсутствия избыточности исходных текстов ПО на уровне информационных объектов (переменных) | 3.3.3 | Полнота и отсутствие избыточности исходных текстов ПО на уровне информационных объектов (переменных) | Выявление переменных, которые только объявлены, но нигде не используются | Заключение эксперта |
| 3.7. | Контроль связей функциональных объектов (модулей, процедур, функций) по информации | 3.3.3 | Отсутствие недекларированных в документации связей функциональных объектов по информации | Выявление отношений по использованию информационных объектов различными функциональными объектами | Сравнительный анализ выявленных отношений с данными документации |
| 3.8. | Контроль информационных объектов различных типов | 3.3.3 | Отсутствие недекларированных в документации обращений к переменным | Формирование перечня информационных объектов, подлежащих контролю. Анализ всех участков кода, в которых осуществляется обращение к указанным в перечне информационным объектам | Заключение эксперта |
| 3.9. | Формирование перечня маршрутов выполнения функциональных объектов (процедур, функций) | 3.3.3 | Для данного требования РД НДВ качественная характеристика оценки результатов не вводится, данный этап испытаний рассматривается как технологический, результат которого используется совместно с результатом динамического анализа (см. ниже) | Построение по исходным кодам цепочки вызовов функциональных объектов (маршрутов) | |
| 4. | Динамический анализ исходных текстов программ | ||||
| 4.1. | Контроль выполнения функциональных объектов (процедур, функций) | 3.3.4 | Соответствие реальных обращений (вызовов, передачи управления) функциональных объектов описанию, приведенному в документации | Контроль процесса выполнения программного обеспечения | Сравнительный анализ данных файла результатов контроля выполнения функциональных объектов и данных документации |
| 4.2 | Сопоставление фактических маршрутов выполнения функциональных объектов и маршрутов, построенных в процессе проведения статического анализа | 3.3.4 | Соответствие фактических маршрутов выполнения функциональных объектов (процедур, функций) и маршрутов, построенных в процессе проведения статического анализа | Выявление расхождений в маршрутах выполнения функциональных объектов, полученных на этапах статического и динамического анализа | Сравнительный анализ |
Контроль состава и содержания документации подразумевает, что на программное обеспечение сертифицируемого изделия выпущена следующая документация: спецификация в соответствии с ГОСТ19.202-78, описание программы в соответствии с ГОСТ 19.402-78, описание применения в соответствии с ГОСТ 19.502-78, исходные тексты программ в соответствии с ГОСТ 19.401-78, пояснительная записка в соответствии с ГОСТ 19.404-79.
Контроль исходного состояния ПО подразумевает, что при идентификации объекта сертификации, заключающейся в расчете указанным разработчиком способом (технологическим средством) контрольных сумм модулей исполняемого кода и исходных текстов программного средства, полученные данные расчетов при последующем сравнении совпадут с данными, приведенными в документации на сертифицируемое программное средство.
Контроль полноты и отсутствия избыточности исходных текстов ПО на уровне файлов подразумевает, что контролируемое программное средство не содержит в своем составе программных модулей (файлов), явно не используемых другими программными модулями.
Контроль соответствия исходных текстов ПО объектному (загрузочному) коду подразумевает мониторинг сборки исполняемого кода из исходного с последующим побайтным сравнением результата сборки с исполняемым кодом, представленным заявителем для проведения сертификационных испытаний.
Контроль полноты и отсутствия избыточности исходных текстов ПО на уровне функциональных объектов (процедур, функций) подразумевает отсутствие в составе исходных текстов контролируемого программного обеспечения функциональных объектов (процедур, функций, задач и защищенных объектов), явно не используемых множеством исполнений контролируемого программного обеспечения.
Контроль связей функциональных объектов (модулей, процедур, функций) по управлению подразумевает построение взаимосвязей указанных объектов контролируемого программного обеспечения по управлению и сравнение построенных взаимосвязей с взаимосвязями, описанными в программной документации.
Контроль связей функциональных объектов (модулей, процедур, функций) по информации подразумевает построение взаимосвязей указанных объектов контролируемого программного обеспечения по информации и сравнение построенных взаимосвязей с взаимосвязями, описанными в программной документации.
Контроль информационных объектов различных типов подразумевает выявление избыточности программного обеспечения на уровне переменных (локальных, глобальных), а также контроль использования объявленных переменных. Перечень контролируемых информационных объектов формируется экспертом, исходя из следующих соображений:
Эксперт может внести в перечень также и другие информационные объекты, субъективно показавшиеся ему существенными. В результате выполнения контроля формируется список информационных объектов и ссылки на участки исходного текста, в которых эти информационные объекты используются. Результат контроля считается положительным, если список информационных объектов и ссылки на участки исходного текста, в которых эти информационные объекты используются, соответствуют данным, представленным в документах «Описание программы», «Описание применения» и «Пояснительная записка».
Синтаксический и семантический контроль наличия заданных конструкций в исходных текстах ПО из списка потенциально опасных программных конструкций подразумевает контроль использования потенциально опасных конструкций (например, импортируемых функций языка С, использования переменной до присвоения начального значения и др.) в исходных текстах контролируемого программного обеспечения.
Формирование перечня маршрутов выполнения функциональных объектов (процедур, функций, ветвей) подразумевает формирование перечня всех возможных маршрутов выполнения контролируемого программного обеспечения для последующего сравнения с наблюдаемым при динамическом анализе маршрутом выполнения контролируемого программного обеспечения.
Анализ критических маршрутов выполнения функциональных объектов (процедур, функций) для заданных экспертом списков информационных объектов подразумевает определение маршрутов выполнения функциональных объектов контролируемого программного обеспечения, зависящих от состояния некоторых информационных объектов, а также маршрутов выполнения, производящих изменения указанных (определенных экспертом) информационных объектов. При этом, непосредственно под критическим маршрутом выполнения функциональных объектов понимается такой маршрут, при выполнении которого существует возможность неконтролируемого нарушения установленных правил обработки информационных объектов.
Построение по исходным текстам контролируемого ПО блок-схем, диаграмм и т.п., и последующий сравнительный анализ алгоритма работы функциональных объектов (процедур, функций) и алгоритма работы, приведенного в "Пояснительной записке" подразумевает построение по исходным текстам программного обеспечения реализованных алгоритмов и последующий их анализ соответствия имеющемуся в документации описанию.
Контроль выполнения функциональных объектов (процедур, функций, ветвей) подразумевает внесение так называемых мониторов активности по определенному алгоритму в исходный код программы, анализ результатов выполнения программы, в том числе сравнение данных, полученных в процессе динамического анализа, с соответствующими данными, полученными в процессе статического анализа. Таким образом, обеспечивается сравнение реального маршрута выполнения программы с теоретически предсказанным маршрутом.
Преимущества сертифицированного на соответствие требованиям отсутствия недекларированных возможностей программного средства (ПС) условно можно разделить на два вида: технологические и потребительские (маркетинговые).
Суть технологических преимуществ обусловлена самой спецификой проведения сертификационных испытаний такого рода. Технологические операции, присущие контролю отсутствия НДВ, такие, как идентификация объекта сертификации, мониторинг сборки исполняемого кода из исходного, мониторинг начальной инсталляции программного средства, статический анализ исходного кода позволяют получить большой объем полезной аналитической информации. Как уже упоминалось ранее, возможно четко соотнести исходный и исполняемый код ПС, выявить и устранить избыточность представленного на испытания исходного кода (которая присуща многим проектам, особенно большим по объему и разработанным разными программистами), однозначно определить действия ПС в процессе начальной инсталляции и деинсталляции по отношению к системным областям операционной системы ЭВМ, получить ряд других характеристик ПС. Полученные результаты испытаний могут быть использованы разработчиком для проведения углубленного анализа своего продукта, планирования и реализации корректирующих воздействий по отношению к ПС в части усовершенствования процессов его разработки и сопровождения.
Характерная для более высоких уровней контроля по отсутствию НДВ технологическая операция по динамическому анализу ПС предусматривает фактическое его тестирование. Причем, такое тестирование является углубленным, учитывающим не только функциональные возможности исследуемого ПС, но и его технологические и структурные особенности. Это объясняется необходимостью инициирования отработки программой тех логических маршрутов ее выполнения, которые были определены как потенциальные на этапе статического анализа исходного кода. Не вызывает сомнения полезность для разработчика таких результатов тестирования, выполненных независимой организацией. Дополнительно разработчик ПС получает исчерпывающую информацию о степени соответствия представленной на сертификационные испытания программной документации требованиям соответствующих нормативных документов. Понятно, что такая информация также не бесполезна для разработчика при сопровождении своего продукта, разработке новых версий или новых программных продуктов.
Следующий важный момент - процесс испытаний, выполняемых в рамках контроля отсутствия НДВ, объективно предполагает постоянный тесный контакт испытателя и разработчика, что зачастую позволяет разработчику оперативно улучшать функциональные и потребительские свойства ПС непосредственно в процессе испытаний.
К числу потребительских или маркетинговых преимуществ можно отнести следующие преимущества:
