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

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

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

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

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

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

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

11.8.2.1 Цели

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

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

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

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

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

c) свидетельство о покрытии тестами.

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

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

11.8.2.4 Действие ATE_COV.1.1E

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

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

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

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

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

Рисунок 8 — Концептуальная структура свидетельства покрытия тестами

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

На рисунке 8 функция безопасности ФБ-3 не сопоставлена с какими бы то ни было тестами; следовательно, относительно функциональной спецификации покрытие тестами является неполным. Неполное покрытие, тем не менее, не будет влиять на вердикт по рассматриваемому подвиду деятельности, поскольку свидетельство о покрытии тестами не обязательно должно показывать полное покрытие тестами идентифицированных в функциональной спецификации функций безопасности.

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

11.8.3.1 Цели

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

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

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

a) ЗБ;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

11.8.4.1 Цели

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

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

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

a) ЗБ;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Далее >>>