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

Приложение А
(обязательное)

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

А.1 Цели

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

А.2 Выборка

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

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

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

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

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

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

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

b) ATE_IND.*.2E: "Оценщик должен протестировать подмножество ФБО как необходимо, чтобы подтвердить, что ОО функционирует в соответствии со спецификациями".

c) ATE_IND.2.3E: "Оценщик должен выполнить выборку тестов из тестовой документации, чтобы верифицировать результаты тестирования, полученные разработчиком".

d) AVA_CCA.*.3E: "Оценщик должен выборочно подтвердить правильность результатов анализа скрытых каналов, применяя тестирование".

e) AVA_MSU.2.2E и AVA_MSU.3.2E: "Оценщик должен повторить все процедуры конфигурирования и установки и выборочно другие процедуры для подтверждения, что ОО можно безопасно конфигурировать и использовать, применяя только представленные руководства".

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

В дополнение к выборке, предусмотренной в ИСО/МЭК 15408, настоящий стандарт определяет следующие действия, для которых выборка применима:

a) Действие АСМ_САР.*.1Е: "Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств".

В этом случае выборка применима для элементов содержания и представления свидетельств АСМ_САР.*.8С и АСМ_САР.*.9С для ОУД3 и ОУД4.

b) Действие ATE_FUN.1.1E: "Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств".

В этом случае выборка применима для элементов содержания и представления свидетельств ATE_FUN.1.3C, ATE_FUN.1.4C и ATE_FUN.1.5C для ОУД2, ОУД3 и ОУД4.

c) Действие ALC_DVS.1.1E: "Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств".

В этом случае выборка применима для элементов содержания и представления свидетельств ALC_DVS.1.2C для ОУД3 и ОУД4.

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

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

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

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

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

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

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

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

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

А.3 Анализ непротиворечивости

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

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

В ИСО/МЭК 15408 различаются несколько типов анализа непротиворечивости.

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

- ADV_FSP.1.2C: "Функциональная спецификация должна быть внутренне непротиворечивой";

- ADV_HLD.1.2C: "Проект верхнего уровня должен быть внутренне непротиворечивым";

- ADV_IMP.1.2C: "Представление реализации должно быть внутренне непротиворечивым";

- ADV_LLD.1.2C: "Проект нижнего уровня должен быть внутренне непротиворечивым".

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

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

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

- AGD_ADM.1.7C: "Руководство администратора должно быть согласовано со всей другой документацией, представленной для оценки";

- AGD_USR.1.5C: "Руководство пользователя должно быть согласовано со всей другой документацией, представленной для оценки".

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

- противоречия с другими руководствами по использованию функций безопасности;

- противоречия с ЗБ (например, в части угроз, предположений безопасного использования, не-ИТ-целей безопасности или функций безопасности ИТ);

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

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

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

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

- AVA_MSU.1.2C: "Руководства должны быть полны, понятны, непротиворечивы и обоснованны".

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

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

- ADV_SPM.1.3C: "Модель ПБО должна включать в себя обоснование, которое демонстрирует, что она согласована и полна относительно всех политик ПБО, которые могут быть смоделированы";

- ADV_SPM.1.4C: "Демонстрация соответствия между моделью ПБО и функциональной спецификацией должна показать, что все функции безопасности в функциональной спецификации являются непротиворечивыми и полными относительно модели ПБО".

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

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

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

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

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

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

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

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

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

Оценщику необходимо учитывать зависимости между компонентами, указанные в ИСО/МЭК 15408-3. Пример такого вида зависимости - AVA_VLA.1 "Анализ уязвимостей разработчиком". В этом компоненте заявлены зависимости от ADV_FSP.1 "Неформальная функциональная спецификация", ADV_HLD.1 "Описательный проект верхнего уровня", AGD_ADM.1 "Руководство администратора" и AGD_USR.1 "Руководство пользователя".

Обычно положительный вердикт по подвиду деятельности можно принять только при успешном завершении всех тех подвидов деятельности, от которых зависит данный подвид деятельности. Например, как правило, положительный вердикт по AVA_VLA.1 может быть принят, если только по подвидам деятельности, относящимся к ADV_FSP.1, ADV_HLD.1, AGD_ADM.1 и AGD_USR.1, также принят положительный вердикт.

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

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

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

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

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

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

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

a) "Автоматизация УК" (ACM_AUT);

b) "Возможности УК" (АСМ_САР).n (при n>2);

c) "Поставка" (ADO_DEL);

d) "Безопасность разработки" (ALC_DVS).

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

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

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

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

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

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

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

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

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

А.6 Границы объекта оценки

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

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

А.6.1 Продукт и система

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

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

А.6.2 Объект оценки

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

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

А.6.3 Функции безопасности объекта оценки

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

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

А.6.4 Оценка

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

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

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

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

2) Межсетевой экран ВЧС, в ЗБ которого все угрозы связаны с доступом к защищаемой сети из незащищенной сети.

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

3) Межсетевой экран ВЧС, в ЗБ которого все угрозы связаны либо с доступом к защищаемой сети из незащищенной сети, либо с конфиденциальностью трафика в незащищенной сети.

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

А.6.5 Сертификация

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

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

Продукт - XYZ межсетевой экран в оцененной конфигурации, определенной в задании по безопасности #АВС

с различными идентификаторами ABC для каждого ЗБ.

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

А.7 Угрозы и требования класса FPT

Автор ПЗ/ЗБ идентифицирует угрозы (не различая при этом угрозы, исходящие от злонамеренных пользователей, и угрозы, проистекающие из некорректностей в реализации, пригодных для использования через внешний интерфейс ФБО) и, исходя из этого, определяет, включать или не включать требования семейств FPT_PHP "Физическая защита ФБО", FPT_SEP "Разделение домена" и/или FPT_RVM "Посредничество при обращениях" в ПЗ/ЗБ. Эти семейства требований предполагают наличие для ОО угрозы физического воздействия, вмешательства пользователей или обхода функций безопасности:

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

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

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

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

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

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

А.7.1 Объекты оценки, для которых необязательны требования класса FPT

Возможно, что к некоторым ОО (типа встроенного ОО без интерфейса пользователя) рассматриваемые угрозы не относятся. Скорее всего, для ОО, предоставляющего пользователю расширенный интерфейс, будет несостоятельным ПЗ/ЗБ, который/которое содержит эти угрозы, но не имеет требований из семейств FPT_PHP, FPT_RVM и FPT_SEP. ОО, для которых, возможно, нет необходимости в требованиях самозащиты из класса FPT, могут быть разделены на три следующих типа.

А.7.1.1 Объект оценки с ограниченным интерфейсом пользователя

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

А.7.1.2 Объект оценки, не осуществляющий соответствующую политику безопасности

Для ОО, не осуществляющего политик управления доступом или информационными потоками, возможно, не имеет никакого значения получение каким-либо пользователем доступа к данным другого пользователя или ФБО. В этом случае нет особой необходимости в разделении пользователей, подразумевающем привлечение FPT_SEP "Разделение домена". Точно так же, если не имеется никаких значительных активов (типа ресурсов ИТ), требующих защиты (например, против отказа в обслуживании), то, возможно, нет смысла в применении требований из класса FPT.

А.7.1.3 Защита обеспечивается средой

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

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

А.7.2 Воздействие на семейства доверия

Включение/исключение в/из ПЗ/ЗБ требований самозащиты из класса FPT затронет следующие требования доверия.

А.7.2.1 ADV

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

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

A.7.2.2 AVA_VLA

Анализ уязвимостей в ИСО/МЭК 15408 определяет влияние уязвимостей на функционирование ОО в его предопределенной среде. Если в ЗБ не идентифицированы никакие угрозы воздействия или обхода, то из поиска уязвимостей разработчиком и оценщиком, где требуется, следует рассмотрение таких атак исключить.

A.7.2.3 ATE_IND

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

А.8 Стойкость функций безопасности и анализ уязвимостей

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

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

Таблица А.1 - Анализ уязвимостей и потенциал нападения

Компонент анализа уязвимостей	ОО противостоит нарушителю с потенциалом нападения	Остаточные уязвимости способен использовать только нарушитель с потенциалом нападения
VLA.4	Высокий	Неприменимо - успешное нападение за пределами практически возможного
VLA.3	Умеренный	Высокий
VLA.2	Низкий	Умеренный

Таблица А.2 - Стойкость функции безопасности ОО и потенциал нападения

Уровень СФБ	Адекватная защита от нарушителя с потенциалом нападения	Недостаточная защита от нарушителя с потенциалом нападения
Высокая СФБ	Высокий	Неприменимо - успешное нападение за пределами практически возможного
Средняя СФБ	Умеренный	Высокий
Базовая СФБ	Низкий	Умеренный

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

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

Общее использование понятия потенциала нападения устанавливает связь между утверждениями о СФБ и оценками уязвимостей, но эту связь не следует рассматривать в качестве обязательной привязки утверждения об уровне СФБ и компонента доверия, выбранного из семейства AVA_VLA "Анализ уязвимостей". Например, выбор компонента AVA_VLA.2 "Независимый анализ уязвимостей", который содержит требование о стойкости к нарушителю с низким потенциалом нападения, не сводит выбор оценки СФБ к базовой СФБ. Учитывая, что уязвимость неотъемлемо присутствует в любой функции, реализованной вероятностным или перестановочным механизмом, и что такие функции являются обычно видимыми свойствами общедоступного интерфейса (например, пароль), автор ПЗ/ЗБ может потребовать более высокого уровня стойкости к соответствующим нападениям и может выбрать более высокий уровень СФБ. Минимальное требование к СФБ как "базовая СФБ" необходимо всегда, когда заявлен компонент из семейства AVA_SOF "Стойкость функций безопасности ОО". Заявленный компонент семейства "Анализ уязвимостей" (AVA_VLA) устанавливает нижний уровень требований к СФБ, и, например, требование к СФБ "базовая СФБ" следует рассматривать как не соответствующее выбору компонента AVA_VLA3 "Умеренно стойкий".

А.8.1 Потенциал нападения

А.8.1.1 Применение потенциала нападения

Потенциал нападения зависит от компетентности, ресурсов и мотивации нарушителя; каждый из этих факторов рассмотрен далее. Потенциал нападения специально рассматривается оценщиком двумя различными способами в процессе оценки ЗБ и при выполнении действий по оценке уязвимостей. В процессе оценки ЗБ оценщик делает заключение, является ли выбор компонентов требований доверия, в особенности компонентов класса AVA "Оценка уязвимостей", соразмерным с потенциалом нападения источника угроз (см. ASE_REQ.1.4C). Случаи, когда требования доверия несоразмерны, могут означать, что либо оценка не будет обеспечивать достаточное доверие, либо оценка будет излишне трудоемкой. В процессе оценки уязвимостей оценщик использует потенциал нападения как способ определения возможности использования идентифицированных уязвимостей в предопределенной среде.

А.8.1.2 Трактовка мотивации

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

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

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

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

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

А.8.2 Вычисление потенциала нападения

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

А.8.2.1 Идентификация и использование

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

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

А.8.2.2 Учитываемые факторы

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

a) идентификация:

1) время, затрачиваемое на идентификацию уязвимости;

2) техническая компетентность специалиста;

3) знание проекта и функционирования ОО;

4) доступ к ОО;

5) аппаратные средства/программное обеспечение ИТ или другое оборудование, требуемое для анализа;

b) использование:

1) время, затрачиваемое на использование уязвимости;

2) техническая компетентность специалиста;

3) знание проекта и функционирования ОО;

4) доступ к ОО;

5) аппаратные средства/программное обеспечение ИТ или другое оборудование, требуемое для использования уязвимости.

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

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

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

a) эксперты хорошо знакомы с основными алгоритмами, протоколами, аппаратными средствами, структурами и т.п., реализованными в типе продукта или системы, а также с применяемыми принципами и концепциями безопасности;

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

c) непрофессионал слабо осведомлен по сравнению с экспертом или профессионалом и не обладает специфической компетентностью.

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

a) отсутствие информации об ОО, кроме его назначения;

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

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

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

Доступ к ОО также является важным обстоятельством и имеет отношение к фактору "время". Идентификация или использование уязвимости может требовать продолжительного доступа к ОО, что может увеличить вероятность обнаружения. Некоторые нападения могут требовать значительных автономных усилий и лишь краткого доступа к ОО для использования уязвимости. Может также потребоваться непрерывный доступ или доступ в виде нескольких сеансов. Применительно к данному рассмотрению, "за минуты" означает, что требуется доступ менее получаса; "за часы" означает, что требуется доступ менее чем сутки; "за сутки" означает, что требуется доступ менее чем месяц, и "за месяцы" означает, что требуется доступ, по меньшей мере, в течение месяца. Когда доступ к ОО не увеличивает вероятность обнаружения (например, смарт-карта в распоряжении нарушителя), этот фактор следует игнорировать.

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

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

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

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

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

А.8.2.3 Подход к вычислению

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

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

Если значение фактора оказывается близким к границе диапазона, оценщик может использовать значение, усредняющее табличные. Например, если для использования уязвимости требуется доступ к ОО в течение одного часа или если доступ обнаруживается очень быстро, то для этого фактора может быть выбрано значение между 0 и 4. Таблица А.3 предназначена для руководства.

Таблица А.3 - Вычисление потенциала нападения

Фактор	Диапазон	Значение при идентификации уязвимости	Значение при использовании уязвимости
Затрачиваемое время	< 0,5 ч	0	0
	< 1 сут	2	3
	< 1 мес	3	5
	> 1 мес	5	8
	Непрактично	*	*
Компетентность	Непрофессионал	0	0
	Профессионал	2	2
	Эксперт	5	4
Знание ОО	Отсутствие информации	0	0
	Общедоступная информация	2	2
	Чувствительная информация	5	4
Доступ к ОО	< 0,5 ч или необнаруживаемый доступ	0	0
	< 1 сут	2	4
	< 1 мес	3	6
	> 1 мес	4	9
	Непрактично	*	*
Оборудование	Отсутствует	0	0
	Стандартное	1	2
	Специализированное	3	4
	Заказное	5	6
______________________________ * Означает, что нападение невозможно в пределах тех временных рамок, которые были бы приемлемы для нарушителя. Любое значение "*" указывает на "высокий" рейтинг.

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

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

Затем для получения рейтинга уязвимости следует использовать таблицу А.4.

Таблица А.4 - Рейтинг уязвимостей

Диапазон значений	ОО противостоит нарушителю с потенциалом нападения	Уровень СФБ
< 10	Нет рейтинга	-
10 - 17	Низкий	Базовый
18 - 24	Умеренный	Средний
> 24	Высокий	Высокий

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

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

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

А.8.3 Пример анализа стойкости функции

Ниже представлен анализ СФБ для гипотетического механизма цифрового пароля.

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

a) цифровой пароль должен быть не менее четырех и не более шести цифр длиной;

b) последовательные числовые ряды (типа 7, 6, 5, 4, 3) не допускаются;

c) повторение цифр не допускается (каждая цифра должна быть уникальной).

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

Число возможных значений цифровых паролей рассчитывают следующим образом:

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

7(8)(9)(10) = 5040.

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

5040 - 14 = 5026.

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

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

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

Уровни СФБ определены в терминах потенциала нападения в ИСО/МЭК 15408-1, раздел 2. Поскольку для того, чтобы утверждать о базовой СФБ, механизм должен противодействовать нарушителю с низким потенциалом нападения и поскольку механизм цифрового пароля является стойким к нарушителю с низким потенциалом, то этот механизм цифрового пароля, в лучшем случае, соответствует уровню "базовая СФБ".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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