Вы можете открыть актуальную версию документа прямо сейчас.
Если вы являетесь пользователем интернет-версии системы ГАРАНТ, вы можете открыть этот документ прямо сейчас или запросить по Горячей линии в системе.
Приложение А
(информативное)
Общие указания по оценке
А.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 Аспекты безопасности разработки
Инфраструктура
- Меры безопасности при организации физического контроля доступа на участок разработки и обоснование эффективности этих мер.
Организационные меры
- Организационная структура компании по отношению к безопасности среды разработки.
- Организационное разделение процессов разработки, производства, тестирования и обеспечения качества.
Меры безопасности, связанные с персоналом
- Меры по обучению персонала аспектам безопасности разработки.
- Меры и юридические соглашения о неразглашении внутренней конфиденциальной информации.
Управление доступом
- Назначение защищаемых объектов (для ОО, исходного кода, подключаемым программным библиотекам (библиотекам времени исполнения), проектной документации, средств разработки, пользовательского руководства) и политик безопасности.
- Политики и обязанности в отношении управления доступом и обработки аутентифицирующей информации.
- Политики занесения в журнал факта любого доступа к участку разработки и защиты данных этих журналов.
Ввод, обработка и вывод данных
- Меры безопасности для защиты устройств ввода/вывода (принтеров, плоттеров и мониторов).
- Обеспечение защиты локальной сети и коммуникаций.
Хранение, передача и уничтожение документов и данных
- Политики обращения с документами и данными.
- Политики и обязанности по уничтожению рассортированных документов и занесение в журнал этих событий.
Защита да
Если вы являетесь пользователем интернет-версии системы ГАРАНТ, вы можете открыть этот документ прямо сейчас или запросить по Горячей линии в системе.