6 Основных принципов программно-аппаратной защиты, заложенной в скзи «Аккорд»:

1. Мультипликативная парадигма. Уровень защищенности АС не выше уровня защищенности самого слабого звена.

2. Основной вопрос ИБ: что первично — железо или софт? Точка опоры — железо.

3. Синдром Мюнхаузена: преодоление синдрома Мюнхаузена состоит в последовательном отказе от программных методов контроля как очевидно не надежных.

4. Принцип Архимеда: состоит в переносе наиболее критичных контрольных процедур на аппаратный уровень, то есть создание точки опоры.

5. Шаг за шагом: корректность процедуры контроля целостности на очередном уровне может основываться только на корректных результатах контроля на предыдущем уровне. Результат корректной реализации пошагового алгоритма контроля целостности — это создание изолированной программной среды.

6. Отчуждай и властвуй: разделение программ и данных способствует повышению конфиденциальности.

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

Настоящий документ устанавливает классификацию программного обеспечения как отечественного, так и импортного производства средств защиты информации, в том числе и встроенных в общесистемное и прикладное программное обеспечение. Действие данного документа не распространяется на криптографические средства защиты информации. Классификация распространяется на программное обеспечение, предназначенное для защиты информации ограниченного доступа. Всего устанавливается 4 уровня контроля отсутствия недекларированных возможностей. Для ПО, которое используется при ЗИ, отнесенной к государственной тайне, должен быть обеспечен уровень контроля не ниже 3. Самый высокий уровень контроля — 1, который достаточен для ПО, используемого при ЗИ с грифом «особой важности».

2 уровень контроля достаточен для ПО, используемого при ЗИ с грифом «совершенно секретно».

3 уровень контроля достаточен для ПО, которое используется при ЗИ с грифом «секретно».

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

Недекларированные возможности — это функциональные возможности ПО, не описанные или недостаточно описанные в документации и при использовании которых возможно нарушение как конфиденциальности, доступности, так и целостности информации.

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

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

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

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

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

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

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

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

Требования к 4 уровню контроля:

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

   1. Спецификация, которая должна содержать сведения о составе ПО и документации на него.

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

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

   4. Исходные тексты программ, входящих в состав данного ПО.

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

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

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

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

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

Требования к 3 уровню контроля:

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

2. Контроль исходного состояния ПО. Аналогично 4 классу.

3. Статический анализ исходных текстов программ. Аналогично 4 уровню, дополнительно:

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

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

      1. Контроль выполнения функциональных объектов.

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

4. Отчетность. Аналогично 4 классу, дополнительно должны присутствовать следующие результаты:

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

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

   3. Контроль информационных объектов различных типов.

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

   5. Контроль выполнения функциональных объектов.

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

Требования ко 2 уровню контроля:

1. Контроль содержания документации. Аналогично 3 уровню.

2. Контроль исходного состояния ПО. Аналогично 3 уровню.

3. Статический анализ исходных текстов программ. Аналогично 3 уровню, дополнительно:

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

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

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

   4. Динамический анализ исходных текстов программ. Аналогично 3 уровню, дополнительно:

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

4. Отчетность. Аналогично 3 уровню, дополнительно:

   1. Протокол должен содержать результаты:

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

      2. синтаксического контроля, наличия заданных конструкций в исходных текстах ПО из базы потенциально-опасных конструкций;

      3. результат формирования перечня маршрутов выполнения функциональных объектов;

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

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

      6. результаты контроля выполнения функциональных объектов;

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

Требования к 1 уровню контроля:

1. Контроль содержания и состава документации. Аналогично 2 уровню.

2. Контроль исходного состояния ПО. Аналогично 2 уровню.

3. Статический анализ исходных текстов программ. Аналогично 2 уровню, дополнительно:

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

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

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

5. Отчетность. Аналогично 2 классу, дополнительно протокол должен содержать следующие результаты:

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

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