LINEBURG


<< Пред. стр.

страница 19
(всего 26)

ОГЛАВЛЕНИЕ

След. стр. >>

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

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

свидетельствовать либо о том, что ОО не функционирует в соответствии со
спецификацией, либо о том, что тестовая документация оценщика может быть
некорректной. Не соответствующие ожидаемым фактические результаты тестирования
могут потребовать внесения корректив в ОО или тестовую документацию, а также,
возможно, повторного выполнения вызвавших коллизию тестов, модификации размера и
состава выборки тестов. Это решение, как и его строгое обоснование, остается за
оценщиком.
8.6.2.3.3 Действие ATE_IND.2.3E
ATE_IND.2-9 Оценщик должен провести тестирование, используя выборку тестов,
находящихся в плане и процедурах тестирования разработчика.
Общая цель данного шага оценивания состоит в выполнении тестов разработчика в
759

количестве, достаточном для подтверждения правильности результатов тестирования

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

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

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

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

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

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

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

найти в соответствующем разделе ТОО, включает:

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

того, чтобы дать некоторое представление о типе информации, касающейся тестирования,
выполненного оценщиком в течение оценки, которую следует представить в ТОО.
8.6.3 Подвид деятельности ATE_IND.3
8.6.3.1 Цели
Цель данного подвида деятельности состоит в том, чтобы путем независимого
768

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

а) ЗБ;
б) функциональная спецификация;
в) руководство пользователя;
г) руководство администратора;
д) процедуры безопасной установки, генерации и запуска;
е) тестовая документация;
ж) материалы анализа покрытия тестами;
з) материалы анализа глубины тестирования;
и) ОО, пригодный для тестирования.
8.6.3.3 Действия оценщика
Этот подвид деятельности включает три элемента действий оценщика из части 3 ОК:
770

а) ATE_IND.3.1E;
б) ATE_IND.3.2E;
в) ATE_IND.3.3E.
8.6.3.3.1 Действие ATE_IND.3.1E
ATE_IND.3.1C
ATE_IND.3-1 Оценщик должен исследовать ОО, чтобы сделать заключение, согласуется ли
тестируемая конфигурация с оцениваемой конфигурацией, определенной в ЗБ.
ОО, используемый оценщиком для тестирования, должен иметь ту же самую уникальную
771

маркировку, которая установлена системой УК.

131
В ЗБ может быть определено более одной подлежащих оценке конфигураций. ОО может
772

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

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

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

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

находится в неизвестном состоянии, то при успешном завершении данный шаг оценивания
мог бы удовлетворить шаг оценивания ADO_IGS.1-2.
ATE_IND.3.2C
ATE_IND.3-3 Оценщик должен исследовать набор ресурсов, предоставленных разработчиком,
чтобы сделать заключение, эквивалентны ли они набору ресурсов,
использовавшимся разработчиком для функционального тестирования ФБО.
Рассматриваемый набор ресурсов может, кроме всего прочего, включать доступное
777

лабораториям и специальное испытательное оборудование. Ресурсы, которые не являются
идентичными ресурсам, использовавшимся разработчиком, должны быть эквивалентны им
с точки зрения любого влияния, которое они могут оказать на результаты тестирования.
8.6.3.3.2 Действие ATE_IND.3.2E
ATE_IND.3-4 Оценщик должен продумать тестируемое подмножество ФБО.
Оценщик выбирает тестируемое подмножество и стратегию тестирования, которая является
778

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

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

факторы:
a) свидетельства тестирования разработчиком. Свидетельства тестирования разработчиком
включают: анализ покрытия тестами, анализ глубины тестирования и тестовую
документацию. Свидетельства тестирования разработчиком должны обеспечить понимание
того, каким образом разработчиком в ходе тестирования опробовались функции
безопасности. Оценщик будет использовать данную информацию при разработке новых
тестов для независимого тестирования ОО. Оценщику следует, в особенности, рассмотреть:
1) усиление тестирования, выполненного разработчиком, для определенной функции
(функций) безопасности. Оценщик может захотеть выполнить большее количество тестов
того же самого типа, чтобы путем изменения параметров более строго протестировать
функцию безопасности;
2) дополнение стратегии тестирования, применявшейся разработчиком, для
определенной функции (функций) безопасности. Оценщик может захотеть изменить подход
к тестированию определенной функции безопасности, тестируя ее с использованием другой
стратегии тестирования;
б) число функций безопасности, из которых необходимо сформировать тестируемое
подмножество. В тех случаях, когда у ОО только небольшое число функций безопасности,
может быть практичным строгое тестирование всех функций безопасности. Для ОО с
большим числом функций безопасности это будет нерентабельно и потребуется
осуществление выборки;
в) поддержание некоторого баланса между видами деятельности по оценке. Усилия
оценщика, затраченные на вид деятельности по тестированию, должны быть соразмерны с
усилиями, затраченными на любой другой вид деятельности по оценке.
Оценщик выбирает определенные функции безопасности для формирования
781

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




133
в) известные из общедоступных источников слабые места безопасности, обычно
ассоциируемые с конкретным типом ОО (например, с операционной системой, межсетевым
экраном). Известные из общедоступных источников слабые места, ассоциируемые с
конкретным типом ОО, будут влиять на процесс выбора тестируемого подмножества.
Оценщику следует включить в тестируемое подмножество те функции безопасности,
которые связаны с известными из общедоступных источников слабыми местами для
данного типа ОО (известные из общедоступных источников слабые места в данном случае
относятся не к уязвимостям как таковым, а к несоответствиям или проблемным вопросам,
которые были обнаружены для данного конкретного типа ОО). Если такие слабые места не
известны, то может быть более приемлемым общий подход, связанный с выбором широкого
диапазона функций безопасности;
г) значимость функций безопасности. Те функции безопасности, которые более значимы,
чем другие, с точки зрения целей безопасности для ОО, следует включить в тестируемое
подмножество;
д) утверждение о СФБ, сделанное в ЗБ. Все функции безопасности, для которых было
сделано конкретное утверждение о СФБ, следует включить в тестируемое подмножество
ФБО;
е) сложность функции безопасности. Для сложных функций безопасности может
потребоваться выполнение сложных тестов, налагающих обременительные требования на
разработчика или оценщика, которые, в свою очередь, не будут способствовать
рентабельным оценкам. С другой стороны, сложные функции безопасности – это вероятная
область поиска ошибок и подходящие кандидаты для включения в подмножество.
Оценщику необходимо достигнуть баланса между этими соображениями;
ж) неявное тестирование. Тестирование некоторых функций безопасности может зачастую
сопровождаться неявным тестированием других функций безопасности, и их включение в
подмножество может максимизировать (хотя и не в явном виде) число тестируемых
функций безопасности. Некоторые интерфейсы обычно могут использоваться для
обеспечения нескольких функциональных возможностей безопасности, и их следует
сделать объектом эффективного подхода к тестированию;
з) типы интерфейсов ОО (например, программный интерфейс, командная строка, протокол).
Оценщику следует рассмотреть вопрос о включении тестов для всех различных типов
интерфейсов, которые поддерживает данный ОО;
и) инновационные или необычные функции. В тех случаях, когда в ОО включены
инновационные или необычные функции безопасности, которые могут широко быть
представлены в маркетинговой литературе, они должны быть прямыми кандидатами на
тестирование.
В данном руководстве сформулированы факторы, которые необходимо рассмотреть в
782

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

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


134
Уяснив из ЗБ и функциональной спецификации ожидаемый режим выполнения функции
784

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

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

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

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


135
Уровень детализации должен быть таким, чтобы другой оценщик мог повторить тесты и
788

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

представленную на этом шаге оценивания (например, фактические результаты
тестирования могут не требовать какого бы то ни было анализа до их сравнения с
ожидаемыми результатами). Это решение, как и его строгое обоснование, остается за
оценщиком.
ATE_IND.3-8 Оценщик должен проверить, что все фактические результаты тестирования
согласуются с ожидаемыми результатами тестирования.
Любые различия в фактических и ожидаемых результатах тестирования могут
790

свидетельствовать либо о том, что ОО не функционирует в соответствии со
спецификацией, либо о том, что тестовая документация оценщика может быть
некорректной. Не ожидаемые фактические результаты тестирования могут потребовать
внесения корректив в ОО или тестовую документацию, а также, возможно, повторного
выполнения вызвавших коллизию тестов, модификации размера и состава выборки тестов.
Решение опустить эту информацию, как и его строгое обоснование, остается за оценщиком.
8.6.3.3.3 Действие ATE_IND.3.3E
ATE_IND.3-9 Оценщик должен провести тестирование по всем тестам, находящимся в плане и
процедурах тестирования разработчика.
Общая цель данного шага оценивания состоит в выполнении всех тестов разработчика,
791

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

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

<< Пред. стр.

страница 19
(всего 26)

ОГЛАВЛЕНИЕ

След. стр. >>

Copyright © Design by: Sunlight webdesign