13.10 Вид деятельности «Оценка уязвимостей»

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

13.10.1 Оценка неправильного применения (AVA_MSU.2)

13.10.1.1 Цели

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

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

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

a) ЗБ;

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

c) проект верхнего уровня;

d) проект нижнего уровня;

e) подмножество представления реализации;

f) модель политики безопасности ОО;

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

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

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

j) материалы анализа неправильного применения руководств;

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

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

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

Использование термина «руководства» в этом подвиде деятельности относится к руководству пользователя, руководству администратора и процедурам безопасной установки, генерации и запуска. Здесь к процедурам установки, генерации и запуска относятся все процедуры перевода ОО из состояния при поставке в состояние функционирования, ответственным за выполнение которых является администратор.

Этот компонент включает в себя требование к анализу, выполняемому разработчиком, которое не присутствует в AVA_MSU.1 «Экспертиза руководств». Проверку правильности этого анализа не следует использовать как замену собственного исследования оценщиком руководств, но следует использовать, чтобы предоставить свидетельство, что разработчик также явным образом учел проблему неправильного применения.

13.10.1.4 Действие AVA_MSU.2.1E

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

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

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

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

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

13.10.1.4.2 Шаг оценивания 4:AVA_MSU.2-2

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

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

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

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

13.10.1.4.3 Шаг оценивания 4:AVA_MSU.1-3

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

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

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

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

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

13.10.1.4.4 Шаг оценивания 4:AVA_MSU.2-4

ИСО/МЭК 15408-3 AVA_MSU.2.3C: Руководства должны содержать список всех предположений относительно среды эксплуатации.

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

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

13.10.1.4.5 Шаг оценивания 4:AVA_MSU.2-5

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

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

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

13.10.1.4.6 Шаг оценивания 4:AVA_MSU.2-6

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

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

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

13.10.1.5 Действие AVA_MSU.2.2E

13.10.1.5.1 Шаг оценивания 4:AVA_MSU.2-7

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

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

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

Работа, выполненная для удовлетворения данного шага оценивания, может также способствовать удовлетворению действия оценщика ADO_IGS.1.2E.

13.10.1.5.2 Шаг оценивания 4:AVA_MSU.2-8

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

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

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

a) ясность руководства. Любое потенциально непонятное руководство следует включить в выборку;

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

c) сложность руководства. Сложное руководство следует включать в выборку;

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

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

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

13.10.1.6 Действие AVA_MSU.2.3E

13.10.1.6.1 Шаг оценивания 4:AVA_MSU.2-9

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

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

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

13.10.1.7 Действие AVA_MSU.2.4E

13.10.1.7.1 Шаг оценивания 4:AVA_MSU.2-10

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

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

13.10.2 Оценка стойкости функций безопасности ОО (AVA_SOF.1)

13.10.2.1 Цели

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

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

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

a) ЗБ;

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

c) проект верхнего уровня;

d)проект нижнего уровня;

e) подмножество представления реализации;

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

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

h) материалы анализа стойкости функций безопасности ОО.

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

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

Хотя анализ СФБ выполняют на базе отдельных механизмов, общее заключение о СФБ базируется на функциях. Если для обеспечения некоторой функции безопасности применяют более одного вероятностного или перестановочного механизма, проанализирован должен быть каждый отдельный механизм. Способ объединения этих механизмов для обеспечения функции безопасности определит общий уровень СФБ для этой функции. Оценщику необходима информация о проекте, чтобы понять, как механизмы работают вместе, чтобы обеспечить функцию, и минимальный уровень для такой информации предоставляют через зависимость от ADV_HLD.1 «Описательный проект верхнего уровня». Фактическая проектная информация, доступная оценщику, определяется ОУД, и эту доступную информацию, когда требуется, следует использовать для поддержки анализа, выполняемого оценщиком.

О СФБ в отношении многодоменных ОО см. в 9.3.6 «Оценка раздела «Требования безопасности ИТ» (ASE_REQ.1).

13.10.2.4 Действие AVA_SOF.1.1E

13.10.2.4.1 Шаг оценивания 4:AVA_SOF.1-1

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

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

Если утверждения о СФБ выражены исключительно в метрике СФБ, то данный шаг оценивания не применяют и поэтому считают удовлетворенным.

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

Руководство по определению потенциала нападения, необходимого для осуществления нападения, и, следовательно, определению СФБ как некоторого уровня см. в А.8 «Стойкость функций безопасности и анализ уязвимостей» (приложение А).

Материалы анализа СФБ включают в себя логическое обоснование утверждения о СФБ, приведенного в ЗБ.

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

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

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

Если утверждения о СФБ выражены исключительно как уровни СФБ, то данный шаг оценивания не применяют и поэтому считают удовлетворенным.

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

Анализ СФБ включает в себя логическое обоснование утверждения о СФБ, приведенного в ЗБ.

13.10.2.4.3 Шаг оценивания 4:AVA_SOF.1-3

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

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

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

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

13.10.2.4.4 Шаг оценивания 4:AVA_SOF.1-4

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

Характер данного шага оценивания сильно зависит от типа рассматриваемого механизма. В А.8 «Стойкость функций безопасности и анализ уязвимостей» (приложение А) представлен пример анализа СФБ для функции идентификации и аутентификации, которая реализована с использованием механизма пароля; при анализе рассмотрена максимальная область значений пароля, чтобы, в конечном счете, прийти к некоторому уровню СФБ. Для биометрии при анализе рассматривают разрешающую способность и другие факторы, влияющие на чувствительность механизма к обману.

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

Руководство по определению потенциала нападения см. в А.8 «Стойкость функций безопасности и анализ уязвимостей» (приложение А).

13.10.2.4.5 Шаг оценивания 4:AVA_SOF.1-5

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

Руководство по ранжированию утверждений о СФБ см. в А.8 «Стойкость функций безопасности и анализ уязвимостей» (приложение А).

13.10.2.4.6 Шаг оценивания 4:AVA_SOF.1-6

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

13.10.2.5 Действие AVA_SOF.1.2E

13.10.2.5.1 Шаг оценивания 4:AVA_SOF.1-7

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

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

13.10.2.5.2 Шаг оценивания 4:AVA_SOF.1-8

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

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

13.10.3 Оценка анализа уязвимостей (AVA_VLA.2)

13.10.3.1 Цели

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

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

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

a) ЗБ;

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

c) проект верхнего уровня;

d) проект нижнего уровня;

e) подмножество представления реализации;

f) модель политики безопасности ОО;

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

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

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

j) материалы анализа уязвимостей;

k) материалы анализа стойкости функций безопасности ОО;

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

Дополнительным исходным материалом для данного подвида деятельности является:

a) текущая информация о явных уязвимостей (например, от органа оценки).

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

Использование термина «руководства» в этом подвиде деятельности относится к руководству пользователя, руководству администратора и процедурам безопасной установки, генерации и запуска.

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

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

Следующие термины использованы в данном руководстве с конкретным значением:

a) уязвимость — слабость в ОО, которая может быть использована, чтобы нарушить политику безопасности в некоторой среде;

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

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

d) потенциальная уязвимость — уязвимость, существование которой в ОО предположено (на основании теоретически допускаемого маршрута нападения), но не подтверждено;

e) пригодная для использования уязвимость — уязвимость, которая может быть использована в предопределенной среде ОО;

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

g) остаточная уязвимость — непригодная для использования уязвимость, которая могла бы быть использована нарушителем с более высоким потенциалом нападения, чем ожидается в предопределенной среде ОО;

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

13.10.3.4 Действие AVA_VLA.2.1E

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

ИСО/МЭК 15408-3 AVA_VLA.2.1C: Документация анализа уязвимостей должна содержать описание анализа поставляемых материалов ОО, выполненного для поиска явных способов, которыми пользователь может нарушить ПБО.

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

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

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

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

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

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

13.10.3.4.2 Шаг оценивания 4:AVA_VLA.2-2

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

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

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

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

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

Руководство по определению потенциала нападения, необходимого для использования уязвимости, см. в А.8 «Стойкость функций безопасности и анализ уязвимостей» (приложение А).

13.10.3.4.3 Шаг оценивания 4:AVA_VLA.2-3

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

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

13.10.3.5 Действие AVA_VLA.2.2E

13.10.3.5.1 Шаг оценивания 4:AVA_VLA.2-4

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

Оценщик готовит к тестированию проникновения:

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

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

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

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

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

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

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

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

13.10.3.5.2 Шаг оценивания 4:AVA_VLA.2-5

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

a) идентификацию тестируемой уязвимости ОО;

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

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

d) инструкции по инициированию ФБО;

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

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

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

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

13.10.3.5.3 Шаг оценивания 4:AVA_VLA.2-6

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

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

13.10.3.5.4 Шаг оценивания 4:AVA_VLA.2-7

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

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

13.10.3.5.5 Шаг оценивания 4:AVA_VLA.2-8

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

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

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

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

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

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

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

13.10.3.6 Действие AVA_VLA.2.3E

13.10.3.6.1 Шаг оценивания 4:AVA_VLA.2-9

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

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

Руководство по определению потенциала нападения, необходимого для использования уязвимости, см. в А.8 «Стойкость функций безопасности и анализ уязвимостей» (приложение А).

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

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

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

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

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

b) обход;

c) вмешательство;

d) прямые нападения;

e) неправильное применение.

Перечисления b) — e) далее объяснены более детально.

13.10.3.6.1.1 Обход

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

a) использования возможностей интерфейсов ОО или утилит, взаимодействующих с ОО;

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

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

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

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

1) изменение предопределенной последовательности вызова функций;

2) выполнение дополнительной функции;

3) использование некоторого компонента в непредусмотренном контексте или с непредусмотренной цепью;

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

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

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

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

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

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

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

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

1) выполнение данных, не предназначенных для выполнения, или преобразование их в возможные для выполнения;

2) генерация непредусмотренных исходных данных для некоторого компонента;

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

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

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

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

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

1) сбор «мусора» на диске;

2) доступ к незащищенной памяти;

3) использование доступа к совместно используемым по записи файлам или другим совместно используемым ресурсам (например, к файлам подкачки);

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

13.10.3.6.1.2 Вмешательство

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

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

b) вынуждения ОО функционировать в необычных или непредусмотренных условиях;

c) отключения или задержки обеспечения безопасности.

В ходе независимого анализа уязвимостей оценщику следует рассмотреть (когда это уместно) каждый из следующих факторов:

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

1) чтение, запись или модификация внутренних данных прямо или косвенно;

2) использование некоторого компонента в непредусмотренном контексте или с непредусмотренной целью;

3) использование взаимного влияния компонентов, которые невидимы на более высоком уровне абстракции;

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

1) чтение «секретов», хранимых внутри ОО, таких как пароли пользователей;

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

3) изменение переменных среды (например, логических имен) или данных в файлах конфигурации или временных файлах;

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

d) оценщику необходимо также рассмотреть следующие «опасные характеристики»:

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

2) интерактивный отладчик и средства внесения изменений (например, возможно изменение исполняемого образа);

3) возможность внесения изменений на уровне контроллеров устройств, на котором файловой защиты не существует;

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

5) инструментальные средства разработчика, оставленные в ОО;

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

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

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

1) генерация непредусмотренных исходных данных для некоторого компонента;

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

h) генерация непредусмотренных исходных данных для компонента включает в себя исследование режима функционирования ОО, когда имеет место:

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

2) ввод неправильных команд или параметров (включая установку параметра в состояние «только для чтения» для интерфейса, который предполагает выдачу данных через этот параметр);

3) вставка маркера конца файла (например, CTRL/Z или CTRL/D) или нулевого символа в журнал аудита;

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

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

1) изменение дат (например, исследования, как ведет себя ОО при переходе датой критического порога);

2) переполнение дисков;

3) превышение максимального числа пользователей;

4) заполнение журнала аудита;

5) переполнение очередей сигналов безопасности, выдаваемых на консоль;

6) перегрузка различных частей многопользовательского ОО, который сильно зависит от компонентов связи;

7) забивание сети или отдельных хостов трафиком;

8) заполнение буферов или полей;

k) нападения, основанные на отключении или задержке обеспечения безопасности, включают в себя:

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

2) нарушения при параллельном выполнении;

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

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

1) прерывании команды (по CTRL/C, CTRL/Y и т.п.);

2) порождении второго прерывания до того, как будет распознано первое;

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

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

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

13.10.3.6.1.3 Прямые нападения

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

13.10.3.6.1.4 Неправильное применение

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

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

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

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

13.10.3.7 Действие AVA_VLA.2.4E

13.10.3.7.1 Шаг оценивания 4:AVA_VLA.2-10

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

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

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

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

a) интерфейсы функции безопасности, которые будут использованы для инициирования выполнения ФБО и наблюдения их реакции;

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

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

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

13.10.3.7.2 Шаг оценивания 4:AVA_VLA.2-11

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

a) идентификацию явной уязвимости, на предмет которой тестируется ОО;

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

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

d) инструкции по инициированию ФБО;

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

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

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

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

13.10.3.7.3 Шаг оценивания 4:AVA_VLA.2-12

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

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

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

13.10.3.7.4 Шаг оценивания 4:AVA_VLA.2-13

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

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

13.10.3.7.5 Шаг оценивания 4:AVA_VLA.2-14

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

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

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

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

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

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

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

13.10.3.8 Действие AVA_VLA.2.5E

13.10.3.8.1 Шаг оценивания 4:AVA_VLA.2-15

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

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

13.10.3.8.2 Шаг оценивания 4:AVA_VLA.2-16

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

a) ее источник (например, стала известна при выполнении действий ОМО, известна оценщику, прочитана в публикации);

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

c) описание;

d) пригодна ли она для использования в предопределенной среде или нет (т.е. пригодная ли для использования или является остаточной уязвимостью);

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

Далее >>>