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

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

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

11.9.1.1 Цели

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

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

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

a) ЗБ;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

11.9.2.1 Цели

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

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

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

a) ЗБ;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

11.9.2.4 Действие AVA_VLA.1.1E

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

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

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

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

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

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

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

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

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

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

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

a) были ли при анализе разработчиком рассмотрены все поставляемые для оценки материалы;

b) приняты ли соответствующие меры для предотвращения использования явных уязвимостей в предопределенной среде;

c) остались ли некоторые явные уязвимости неидентифицированными.

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

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

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

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

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

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

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

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

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

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

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

11.9.2.5 Действие AVA_VLA.1.2E

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

c) описание;

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

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

Далее >>>