Приложение А (информативное). Общие указания по оценке

Приложение А
(информативное)

Общие указания по оценке

А.1 Цели

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

А.2 Выборка

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

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

a) На подмножестве не обнаружено никаких ошибок, что дает оценщику определенную уверенность в том, что совокупность в целом корректна.

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

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

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

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

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

В определенных случаях для оценщика может быть уместно придавать большее значение повторению тестирований, проведенных разработчиком. Например, если независимые тесты, которые осталось провести оценщику, только поверхностно отличаются от включенных в обширный набор проверок, проведенных разработчиком (допустим, что разработчик провёл тестирование в большем объеме, чем необходимо для удовлетворения критериев классов ATE_COV "Покрытие" и ATE_DPT "Глубина"), тогда оценщику целесообразнее сосредоточить усилия на повторении проверок, проведенных разработчиком. Следует отметить, что это не обязательно подразумевает требование большой доли выборки при повторении тестов разработчика; на самом деле, учитывая обширный набор проверок, проведенных разработчиком, оценщик может обосновать необходимость повторения лишь весьма малого процента тестовых испытаний.

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

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

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

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

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

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

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

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

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

А.3 Зависимости

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

А.3.1 Зависимости между видами деятельности

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

А.3.2 Зависимости между подвидами деятельности

Оценщику необходимо учитывать зависимости между компонентами, указанные в ИСО/МЭК 15408-3. Большинство таких зависимостей являются односторонними, например Подвид деятельности по оценке AVA_VAN.1 зависит от Подвидов деятельности по оценке ADV_FSP.1 и AGD_OPE.1. Есть и примеры взаимной зависимости, когда оба компонента зависят друг от друга, например Подвид деятельности по оценке ATE_FUN.1 и Подвид деятельности по оценке ATE_COV.1.

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

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

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

А.3.3 Зависимости между действиями

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

А.4 Посещение объектов

А.4.1 Введение

В класс доверия ALC включены требования к:

a) применению управления конфигурацией. Эти требования обеспечивают сохранение целостности ОО;

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

c) мерам безопасности, используемым для защиты среды разработки.

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

Объекты посещаются для того, чтобы ознакомиться с:

a) использованием системы УК, как описано в плане УК;

b) практическим применением процедур поставки, как описано в документации по поставке;

c) применением мер безопасности во время разработки и поддержания функционирования ОО, как описано в документации по разработке системы безопасности.

Конкретная и подробная информация дается в шагах оценивания для тех действий, когда выполняется посещение объектов:

a) "Возможности УК" (ALC_CMC).n, где n 3 (особенно в шагах оценивания ALC_CMC.3-10 = ALC_CMC.4-13 = АLС_СМС.5-19);

b) "Поставка" (ALC_DEL) - особенно в шаге оценивания ALC_DEL.1-2;

c) "Безопасность разработки" (ALC_DVS) - особенно в шагах оценивания ALC_DVS.1-3 = ALC_DVS.2-4.

А.4.2 Общий подход

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

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

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

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

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

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

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

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

А.4.3 Примерное руководство по подготовке контрольного листа проверок

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

А.4.3.1 Аспекты управления конфигурацией

Базовые аспекты

- Пункты списка конфигурации, включая ОО, исходный код, подключаемые программные библиотеки (библиотеки времени исполнения), проектная документация, средства разработки (ALC_CMC.3-8).

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

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

Тестовые проверки

- Прослеживание планов проведения испытаний и результатов тестирования к конкретным настройкам и версиям ОО.

- Управление доступом к системам разработки

- Политики управления доступом и ведения журналов.

- Политики назначения и изменения прав доступа, специфические для данного проекта.

- Перевод ОО в исходное состояние

- Политики перевода ОО в исходное состояние и руководство пользователя, предоставляемое пользователю ОО.

- Политика для тестирования и одобрения компонентов ОО и самого ОО перед развертыванием.

А.4.3.2 Аспекты безопасности разработки

Инфраструктура

- Меры безопасности при организации физического контроля доступа на участок разработки и обоснование эффективности этих мер.

Организационные меры

- Организационная структура компании по отношению к безопасности среды разработки.

- Организационное разделение процессов разработки, производства, тестирования и обеспечения качества.

Меры безопасности, связанные с персоналом

- Меры по обучению персонала аспектам безопасности разработки.

- Меры и юридические соглашения о неразглашении внутренней конфиденциальной информации.

Управление доступом

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

- Политики и обязанности в отношении управления доступом и обработки аутентифицирующей информации.

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

Ввод, обработка и вывод данных

- Меры безопасности для защиты устройств ввода/вывода (принтеров, плоттеров и мониторов).

- Обеспечение защиты локальной сети и коммуникаций.

Хранение, передача и уничтожение документов и данных

- Политики обращения с документами и данными.

- Политики и обязанности по уничтожению рассортированных документов и занесение в журнал этих событий.

Защита данных

- Политики и обязанности по защите информации (например по выполнению резервных копий).

План непрерывности бизнес-процессов

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

- Документация мер управления доступом в условиях чрезвычайной ситуации.

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

А.4.4 Пример контрольного листа проверки

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

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

В контрольном списке выделяют три подраздела согласно темам, обозначенным во Введении (пункт А.4.1 данного приложения):

a) Система управления конфигурацией.

b) Процедуры поставки.

c) Меры безопасность во время разработки.

Эти разделы соответствуют классу ALC актуального ИСО/МЭК 15408, в особенности семействам "Возможности УК" (ALC_CMC).n, где n 3, "Поставка" (ALC_DEL) и "Безопасность разработки" (ALC_DVS).

Далее эти подразделы разделяются в ряды, соответствующие шагам оценивания данного стандарта.

Колонки в таблице, которую представляет собой контрольный список, содержат в свою очередь:

- последовательный номер,

- шаг оценивания, на который ссылаются при проверке,

- ссылки на соответствующую документацию разработчика,

- явное воспроизведение мер, предпринятых разработчиком,

- особые примечания и вопросы, которые требуется прояснить во время посещения объекта (помимо стандартной задачи оценщика по проверке применения обозначенных мер),

- результат проверки во время посещения.

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

Таблица А.1. Пример контрольного списка проверки по ОУД 4 (фрагмент)

N	Шаг оценивания	Документация разработчика	Меры	Вопросы и примечания	Результат
А. Проверка системы УК (ALC_CMC.4 и ALC_CMS.4)
А.1	ALC_CMC.4-11, ALC_CMC.4-12	"Система управления конфигурацией", главы...	Система, автоматически управляющая файлами исходного кода, способна администрировать профили пользователей и права доступа, а также проверять правильность идентификации и аутентификации пользователей	Требуется ли прохождение пользователем процедуры аутентификации при чтении или изменении файлов исходного кода?	Если у пользователя нет прав доступа к конфиденциальному документу, он даже не видит этот документ в списке файлов
В. Проверка процедур поставки (ALC_DEL.1)
В.1	ALC_DEL.1-1, ALC_DEL.1-2	"Поставка ОО", главы...	Программное обеспечение передается заказчику с зашифрованной средствами PGP подписью и расшифровывается заказчиком		Процесс проверен оценщиками, принято решение, что он правильно описан, кроме того, передается и контрольная сумма
С. Проверка организационной и инфраструктурной безопасности среды разработки (ALC_DVS.1, ALC_LCD.1, АLС_ТАТ.1)
С.1	ALC_DVS.1-1, ALC_DVS.1-2	"Безопасность среды разработки", главы... (Территория)	Территория, на которой ведется разработка, по периметру защищена ограждениями	Достаточно ли прочное и высокое заграждение для того, чтобы предотвратить возможность проникновения на территорию?	Оценщиками принято решение, что ограждение является достаточно прочным и высоким
С.2	ALC_DVS.1-1, ALC_DVS.1-2	"Безопасность среды разработки", главы... (Здания и сооружения)	Возможны следующие пути доступа в здание: главный вход, где есть проходная (вход закрыт, если на проходной нет сотрудников) и вход через проходную, где осуществляется приемка товара (проход через турникет)	Является ли список возможных путей доступа полным?	Помимо указанных путей доступа в здание, есть также аварийный выход, дверь которого не может быть открыта снаружи. Упомянутые в описании турникеты управляются только изнутри, находящимся на проходной сотрудником

А.5 Сфера ответственности системы оценки

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

К вопросам, которые могут определяться в конкретной системе оценки, относятся:

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

b) процесс распоряжения свидетельствами оценки после завершения оценки;

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

d) действия, предпринимаемые при возникновении проблем в процессе оценки (после решения проблемы процесс оценки либо возобновляется, либо немедленно прекращается и исправленный продукт необходимо заново представить для оценки);

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

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

g) дополнительные отчеты (помимо ТОО), требуемые от оценщиков, например отчеты о тестировании;

h) любые специфические СП, которые могут потребоваться в соответствии с системой, включая структуру, получателей и т.д. для таких СП;

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

j) любая требуемая дополнительно информация по идентификации ПЗ/ЗБ;

k) любые виды деятельности по принятию решения о пригодности сформулированных в явном виде требований в ЗБ;

l) любые требования по подготовке свидетельства оценщика для поддержки переоценки и повторного применения свидетельств;

m) любые конкретные способы применения идентификаторов, эмблем, торговых марок и т.д. системы оценки;

n) любые конкретные указания по применению криптографии;

o) способы трактовки и применения системы оценки, национальных и международных интерпретаций;

p) перечень или описание приемлемых альтернатив тестированию там, где тестирование неосуществимо;

q) механизм, посредством которого орган оценки может определить, какие шаги оценщик предпринял при тестировании;

r) предпочтительный подход при тестировании (если таковой имеется): на внутреннем интерфейсе или на внешнем интерфейсе;

s) перечень или характеристика приемлемых способов (средств) проведения оценщиком анализа уязвимостей (например методология гипотез о недостатках);

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