13.9 Вид деятельности «Тестирование»

Вид деятельности «Тестирование» предназначен для того, чтобы сделать заключение, ведут ли себя ФБО как определено в проектной документации и в соответствии с функциональными требованиями безопасности ОО, определенными в ЗБ. Данную цель достигают путем вынесения заключения о проведении разработчиком тестирования ФБО на их соответствие функциональной спецификации и проекту верхнего уровня, причем уверенность в результатах тестирования повышают путем выборочного выполнения тестов разработчика, а также проведения независимого тестирования некоторого подмножества ФБО.

13.9.1 Замечания по применению

Объем и состав подмножества тестов оценщика зависят от нескольких факторов, рассматриваемых в подвидах деятельности, связанных с независимым тестированием (ATE_IND.2 «Выборочное независимое тестирование»). Один из таких факторов, оказывающих влияние на состав подмножества тестов, — это известные из общедоступных источников слабые места, к информации о которых оценщику необходимо получить доступ (например, в рамках системы оценки).

В ИСО/МЭК 15408 для повышения гибкости применения компонентов семейств вопросы покрытия тестами и глубины тестирования рассмотрены отдельно от функциональных тестов. Тем не менее, требования соответствующих семейств предназначены для совместного применения в целях подтверждения, что ФБО выполняются согласно их спецификации. Такая тесная связь семейств привела к некоторому дублированию работы оценщика по подвидам деятельности. Настоящие замечания по применению позволяют минимизировать повторения текста при описании подвидов деятельности одного и того же вида деятельности и ОУД.

13.9.1.1 Понимание ожидаемого режима функционирования ОО

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

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

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

13.9.1.2 Альтернативные тестированию подходы к верификации ожидаемого режима выполнения функции безопасности

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

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

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

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

13.9.1.3 Верификация адекватности тестов

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

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

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

13.9.2 Оценка покрытия (ATE_COV.2)

13.9.2.1 Цели

Цель данного подвида деятельности — сделать заключение, является ли тестирование (как это документально зафиксировано) достаточным, чтобы установить, что ФБО были систематическим методом протестированы на соответствие функциональной спецификации.

13.9.2.2 Исходные данные

a) ЗБ;

b) функциональная спецификация;

c) тестовая документация;

d) материалы анализа покрытия тестами.

13.9.2.3 Действие ATE_COV.2.1E

13.9.2.3.1 Шаг оценивания 4:ATE_COV.2-1

ИСО/МЭК 15408-3 ATE_COV.2.1C: Анализ покрытия тестами должен демонстрировать соответствие между тестами, идентифицированными в тестовой документации, и описанием ФБО в функциональной спецификации.

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

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

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

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

12.9.2.3.2 Шаг оценивания 4:ATE_COV.2-2

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

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

a) «Понимание ожидаемого режима функционирования ОО»;

b) «Альтернативные тестированию подходы к верификации ожидаемого режима выполнения функции безопасности».

13.9.2.3.3 Шаг оценивания 4:ATE_COV.2-3

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

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

13.9.2.3.4 Шаг оценивания 4:ATE_COV.2-4

ИСО/МЭК 15408-3 ATE_COV.2.2C: Анализ покрытия тестами должен демонстрировать полное соответствие между описанием ФБО в функциональной спецификации и тестами, идентифицированными в тестовой документации.

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

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

Рисунок 13 - Концептуальная структура анализа покрытия тестами

13.9.3 Оценка глубины (ATE_DPT.1)

13.9.3.1 Цели

Цель данного подвида деятельности — сделать заключение, тестировал ли разработчик ФБО на соответствие проекту верхнего уровня.

13.9.3.2 Исходные данные

a) ЗБ;

b) функциональная спецификация;

c) проект верхнего уровня;

d) тестовая документация;

e) материалы анализа глубины тестирования.

13.9.3.3 Действие ATE_DPT.1.1E

13.9.3.3.1 Шаг оценивания 4:ATE_DPT.1-1

ИСО/МЭК 15408-3 ATE_DPT.1.1C: Анализ глубины должен показать достаточность тестов, идентифицированных в тестовой документации, для демонстрации, что ФБО выполняются в соответствии с проектом верхнего уровня.

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

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

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

13.9.3.3.2 Шаг оценивания 4:ATE_DPT.1-2

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

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

a) «Понимание ожидаемого режима функционирования ОО»;

b) «Альтернативные тестированию подходы к верификации ожидаемого режима выполнения функции безопасности».

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

13.9.3.3.3 Шаг оценивания 4:ATE_DPT.1-3

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

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

13.9.3.3.4 Шаг оценивания 4:ATE_DPT.1-4

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

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

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

Рисунок 14 - Концептуальная структура анализа глубины тестирования

13.9.4 Оценка функциональных тестов (ATE_FUN.1)

13.9.4.1 Цели

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

13.9.4.2 Исходные данные

Свидетельствами оценки для этого подвида деятельности являются:

a) ЗБ;

b) функциональная спецификация;

c) тестовая документация;

d) процедуры тестирования.

13.9.4.3 Замечания по применению

Степень требуемого покрытия ФБО тестовой документацией зависит от соответствующего компонента доверия, связанного с покрытием тестами.

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

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

13.9.4.4 Действие ATE_FUN.1.1E

13.9.4.4.1 Шаг оценивания 4:ATE_FUN.1-1

ИСО/МЭК 15408-3 ATE_FUN.1.1C: Тестовая документация должна состоять из планов и описаний процедур тестирования, а также ожидаемых и фактических результатов тестирования.

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

13.9.4.4.2 Шаг оценивания 4:ATE_FUN.1-2

ИСО/МЭК 15408-3 ATE_FUN.1.2C: Планы тестирования должны идентифицировать проверяемые функции безопасности и содержать изложение целей проводимых тестов.

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

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

Для выполнения данного шага оценивания оценщик может избрать стратегию выборки.

Руководство по выборке см. в А.2 «Выборка» (приложение А).

13.9.4.4.3 Шаг оценивания 4:ATE_FUN.1-3

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

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

Для выполнения данного шага оценивания оценщик может избрать стратегию выборки.

Руководство по выборке см. в А.2 «Выборка» (приложение А).

13.9.4.4.4 Шаг оценивания 4:ATE_FUN.1-4

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

ОО, упомянутый в плане тестирования разработчика, должен иметь ту же самую уникальную маркировку, которая установлена в соответствии с подвидом деятельности АСМ_САР.* «Возможности УК».

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

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

13.9.4.4.5 Шаг оценивания 4:ATE_FUN.1-5

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

Для выполнения данного шага оценивания оценщик может избрать стратегию выборки.

Руководство по выборке см. в А.2 «Выборка» (приложение А). Руководство по анализу непротиворечивости см. в А.3 «Анализ непротиворечивости» (приложение А).

13.9.3.4.6 Шаг оценивания 4:ATE_FUN.1-6

ИСО/МЭК 15408-3 ATE_FUN.1.3C: Описания процедур тестирования должны идентифицировать тесты, которые необходимо выполнить, и включать в себя сценарии для тестирования каждой функции безопасности. Эти сценарии должны учитывать любое влияние последовательности выполнения тестов на результаты других тестов.

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

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

Для выполнения данного шага оценивания оценщик может избрать стратегию выборки.

Руководство по выборке см. в А.2 «Выборка» (приложение А).

13.9.4.4.7 Шаг оценивания 4:ATE_FUN.1-7

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

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

Для выполнения данного шага оценивания оценщик может избрать стратегию выборки.

Руководство по выборке см. в А.2 «Выборка» (приложение А).

13.9.4.4.8 Шаг оценивания 4:ATE_FUN.1-8

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

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

Для выполнения данного шага оценивания оценщик может избрать стратегию выборки.

Руководство по выборке см. в А.2 «Выборка» (приложение А).

13.9.4.4.9 Шаг оценивания 4:ATE_FUN.1-9

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

Если описание процедур тестирования — это собственно процедуры тестирования, то рассматриваемый шаг оценивания не применяют и поэтому считают удовлетворенным.

Для выполнения данного шага оценивания оценщик может избрать стратегию выборки.

Руководство по выборке см в А.2 «Выборка» (приложение А). Руководство по анализу непротиворечивости см. в А.3 «Анализ непротиворечивости» (приложение А).

13.9.4.4.10 Шаг оценивания 4:ATE_FUN.1-10

ИСО/МЭК 15408-3 ATE_FUN.1.4C: Ожидаемые результаты тестирования должны показать прогнозируемые выходные данные успешного выполнения тестов.

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

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

Для выполнения данного шага оценивания оценщик может избрать стратегию выборки.

Руководство по выборке см. в А.2 «Выборка» (приложение А).

13.9.4.4.11 Шаг оценивания 4:ATE_FUN.1-11

ИСО/МЭК 15408-3 ATE_FUN.1.5C: Результаты выполнения тестов разработчиком должны демонстрировать, что каждая проверенная функция безопасности выполнялась в соответствии со спецификациями.

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

Сравнение представленных разработчиком фактических и ожидаемых результатов тестирования выявит какие бы то ни было несоответствия результатов.

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

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

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

Для выполнения данного шага оценивания оценщик может избрать стратегию выборки.

Руководство по выборке см. в А.2 «Выборка» (приложение А).

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

13.9.4.4.12 Шаг оценивания 4:ATE_FUN.1-12

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

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

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

a) тестируемые конфигурации ОО. Конкретные конфигурации ОО, которые были протестированы;

b) подход к тестированию. Описание общей стратегии тестирования, которую применил разработчик;

c) объем тестирования, выполненного разработчиком. Описание степени покрытия тестами и глубины тестирования разработчиком;

d) результаты тестирования. Описание общих результатов тестирования разработчиком.

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

13.9.5 Оценка путем независимого тестирования (ATE_IND.2)

13.9.5.1 Цели

Цель данного подвида деятельности состоит в том, чтобы путем независимого тестирования подмножества ФБО сделать заключение, соответствуют ли спецификациям режимы функционирования ОО, и повысить уверенность в результатах тестирования разработчиком путем выполнения выборки тестов разработчика.

13.9.5.2 Исходные данные

Свидетельствами оценки для данного подвида деятельности являются:

a) ЗБ;

b) функциональная спецификация;

c) руководство пользователя;

d) руководство администратора;

e) процедуры безопасной установки, генерации и запуска;

f) тестовая документация;

g) материалы анализа покрытия тестами;

h) материалы анализа глубины тестирования;

i) ОО, пригодный для тестирования.

13.9.5.3 Действие ATE_IND.2.1E

13.9.5.3.1 Шаг оценивания 4:ATE_IND.2-1

ИСО/МЭК 15408-3 ATE_IND.2.1C: ОО должен быть пригоден для тестирования.

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

ОО, используемый оценщиком для тестирования, должен иметь ту же самую уникальную маркировку, которая установлена в соответствии с подвидом деятельности АСМ_САР.* «Возможности УК».

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

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

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

13.9.5.3.2 Шаг оценивания 4:ATE_IND.2-2

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

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

Если оценщику необходимо выполнить процедуры установки вследствие того, что ОО находится в неизвестном состоянии, то при успешном завершении данный шаг оценивания мог бы удовлетворить шаг оценивания ADO_IGS.1-2.

13.9.5.3.3 Шаг оценивания 4:ATE_IND.2-3

ИСО/МЭК 15408-3 ATE_IND.2.2C: Разработчик должен представить набор ресурсов, эквивалентных использованным им при функциональном тестировании ФБО.

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

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

13.9.5.4 Действие ATE_IND.2.2E

13.9.5.4.1 Шаг оценивания 4:ATE_IND.2-4

Оценщик должен определить тестируемое подмножество ФБО.

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

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

При выборе подмножества тестируемых ФБО оценщику необходимо рассмотреть следующие факторы:

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

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

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

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

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

Оценщик выбирает определенные функции безопасности для формирования соответствующего подмножества. Этот выбор будет зависеть от ряда факторов, и рассмотрение этих факторов также может влиять на выбор размера тестируемого подмножества ФБО:

a) строгость тестирования разработчиком функций безопасности. Все функции безопасности, идентифицированные в функциональной спецификации, должны иметь относящиеся к ним свидетельства тестирования разработчиком, как это требуется в ATE_COV.2 «Анализ покрытия». Те функции безопасности, которые оценщик определил как требующие дополнительного тестирования, следует включить в тестируемое подмножество ФБО;

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

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

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

e) утверждение о СФБ, сделанное в ЗБ. Все функции безопасности, для которых было сделано конкретное утверждение о СФБ, следует включить в тестируемое подмножество ФБО;

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

g) неявное тестирование. Тестирование некоторых функций безопасности может зачастую сопровождаться неявным тестированием других функций безопасности, и их включение в подмножество может максимизировать (хотя и не в явном виде) число тестируемых функций безопасности. Некоторые интерфейсы могут обеспечивать несколько функциональных возможностей безопасности, и их следует сделать объектом эффективного подхода к тестированию;

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

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

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

Руководство по выборке см. в А.2 «Выборка» (приложение А).

13.9.5.4.2 Шаг оценивания 4:ATE_IND.2-5

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

Установив из ЗБ и функциональной спецификации ожидаемый режим выполнения функции безопасности, оценщик должен определить наиболее подходящий способ тестирования данной функции. Оценщик, в особенности, рассматривает:

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

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

c) начальные условия, которые будут необходимы для выполнения теста (т.е. любые конкретные объекты или субъекты. которые будут необходимы, и атрибуты безопасности, которые им необходимо будет иметь);

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

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

В тестовой документации оценщика следует определить происхождение каждого теста, прослеживая его к соответствующей спецификации проекта и, если необходимо, к ЗБ.

13.9.5.4.3 Шаг оценивания 4:ATE_IND.2-6

Оценщик должен провести тестирование.

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

13.9.5.4.4 Шаг оценивания 4:ATE_IND.2-7

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

a) идентификационную информацию тестируемого режима выполнения функции безопасности;

b) инструкции по подключению и настройке всего необходимого оборудования для тестирования, как это требуется для выполнения конкретного теста;

c) инструкции по установке всех предварительных условий выполнения теста;

d) инструкции по инициированию функции безопасности;

e) инструкции по наблюдению режима выполнения функции безопасности;

f) описание всех ожидаемых результатов и необходимого анализа, проводимого по отношению к наблюдаемому режиму выполнения для сравнения с ожидаемыми результатами;

g) инструкции по завершению теста и установке необходимого посттестового состояния ОО;

h) фактические результаты тестирования.

Уровень детализации должен быть таким, чтобы другой оценщик мог повторить тесты и получить эквивалентный результат. Хотя некоторые специфические детали результатов выполнения теста могут различаться (например, поля времени и даты в записи аудита), общие результаты должны быть идентичными.

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

13.9.5.4.5 Шаг оценивания 4:ATE_IND.2-8

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

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

13.9.5.5 Действие ATE_IND.2.3E

13.9.5.5.1 Шаг оценивания 4:ATE_IND.2-9

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

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

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

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

Руководство по выборке см. в А.2 «Выборка» (приложение А).

13.9.5.5.2 Шаг оценивания 4:ATE_IND.2-10

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

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

Если удовлетворительное объяснение или устранение противоречий не может быть достигнуто, то уверенность оценщика в результатах тестирования разработчиком может уменьшиться; у оценщика даже может возникнуть необходимость в увеличении объема выборки, чтобы восстановить уверенность в результатах тестирования разработчиком. Если увеличение объема выборки не оправдает ожиданий оценщика, может потребоваться повторение всей совокупности тестов разработчика. В конечном счете, для адекватного тестирования подмножества ФБО, идентифицированного на шаге оценивания ATE_IND.2-4, недостаточность тестов разработчика приведет к необходимости корректировки тестов разработчика или разработки оценщиком новых тестов.

13.9.5.5.3 Шаг оценивания 4:ATE_IND.2-11

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

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

Информация, относящаяся к усилиям оценщика по тестированию, которую обычно можно найти в соответствующем разделе ТОО, включает в себя:

a) тестируемые конфигурации ОО. Конкретные конфигурации ОО, которые были протестированы;

b) выбранный размер подмножества. Число протестированных в течение оценки функций безопасности и логическое обоснование этого размера;

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

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

e) выполненные тесты разработчика. Число выполненных тестов разработчика и краткое описание критериев, использованных для выбора данных тестов;

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

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

Далее >>>