Методология оценки безопасности информационных технологий по общим критериям

Марк Кобзарь, Алексей Сидак
Jet Info Online №6 2004

Процесс оценки

Общая модель оценки

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

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

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

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

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

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

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

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

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

Особенности выполнения количественных оценок

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

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

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

Анализ стойкости функций безопасности, как пример выполнения количественных оценок

В ОК и ОМО применение количественных показателей предусматривается при анализе стойкости функций безопасности ОО, реализованных вероятностными и/или перестановочными механизмами.

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

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

Потенциал нападения является функцией от мотивации, компетентности и ресурсов нарушителя.

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

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

1. Идентификация:
   1. время, затрачиваемое на идентификацию уязвимости;
   2. техническая компетентность специалиста;
   3. знание проекта и функционирования ОО;
   4. доступ к ОО;
   5. аппаратные средства/программное обеспечение ИТ или другое оборудование, требуемое для анализа.
2. Использование:
   1. время, затрачиваемое на использование уязвимости;
   2. техническая компетентность специалиста;
   3. знание проекта и функционирования ОО;
   4. доступ к ОО;
   5. аппаратные средства/программное обеспечение ИТ или другое оборудование, требуемое для использования уязвимости.

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

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

1. "Эксперты" хорошо знакомы с основными алгоритмами, протоколами, аппаратными средствами, структурами и т.п., реализованными в типе продукта или системы, а также с применяемыми принципами и концепциями безопасности;
2. "Профессионалы" хорошо осведомлены в том, что касается режима безопасности продукта или системы данного типа;
3. "Непрофессионалы" слабо осведомлены, по сравнению с экспертами или профессионалами, и не обладают специфической компетентностью.

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

1. "Отсутствие информации" об ОО, кроме его назначения;
2. "Общедоступная информация" об ОО (например, полученная из руководства пользователя);
3. "Чувствительная информация" об ОО (например, сведения о внутреннем содержании проекта).

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

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

В качестве значений данного фактора рассматриваются следующие виды оборудования:

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

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

При определении потенциала нападения для данной уязвимости из каждого столбца (столбцы 2 и 3 Таб. 2) для каждого фактора следует выбрать определенное значение (10 значений). При выборе значений должна учитываться предопределенная среда ОО. Выбранные 10 значений суммируются, давая итоговое значение. Это значение затем сверяется с Таб. 3 для определения рейтинга уязвимости и соответственно по Таб. 1 — уровня СФБ. Полученный уровень стойкости функции безопасности говорит о том, нарушителю с каким потенциалом противостоит ОО.

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

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

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

Пример анализа стойкости функции безопасности

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

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

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

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

1. Допуская самый плохой вариант сценария, когда пользователь выбирает число, состоящее только из четырех цифр, число перестановок цифрового пароля (предполагая, что каждая цифра уникальна) равно: 7*8*9*10 = 5040
2. Число возможных увеличивающихся рядов — семь, как и число убывающих рядов. После отбрасывания этих рядов число возможных значений цифровых паролей равно: 5040 — 14 = 5026

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

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

2513 мин / (60 мин/час) ~ 42 часа

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

Поскольку механизм цифрового пароля является стойким к нарушителю с низким потенциалом, то этот механизм цифрового пароля соответствует уровню "базовая СФБ" (Таб. 1).

Правила формирования заключения по результатам оценки

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

В ОМО различаются три взаимоисключающих вида заключения:

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

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

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

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

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

Оформление результатов оценки

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

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

Подготовка СП

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

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

Оформляя СП, оценщик должен привести в нем следующую информацию:

1. идентификатор оцениваемого ПЗ или ОО;
2. ссылку на задачу/подвид деятельности по оценке, при выполнении которой/которого была выявлена проблема;
3. суть проблемы;
4. оценку серьезности проблемы (например, приводит к отрицательному заключению, задерживает выполнение оценки или требует решения до завершения оценки);
5. идентификационную информацию организации, ответственной за решение проблемы;
6. рекомендуемые сроки решения проблемы;
7. влияние на оценку отрицательного результата решения проблемы.

Адресаты рассылки СП и процедуры обработки ими сообщений зависят от характера содержания конкретных сообщений и от указаний со стороны системы оценки.

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

Подготовка ТОО

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

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

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

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

В ОМО предусмотрены две разновидности ТОО:

• ТОО по результатам оценки ПЗ;
• ТОО по результатам оценки ОО.

Рассмотрим их подробнее.

Технический отчет об оценке профиля защиты

Содержание ТОО, отражающего результаты оценки ПЗ, представлено на Рис. 5.

В разделе "Введение" ТОО оценщик должен привести следующую информацию:

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

В разделе "Оценка" ТОО оценщик должен привести следующую информацию:

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

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

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

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

Результат оценки ПЗ в целом должен формулироваться как "соответствие/несоответствие" [4].

При положительном результате оценки должна быть указана степень, с которой можно доверять тому, что ПЗ соответствуют требованиям ОК. Должно поясняться соотношение с функциональными требованиям из части 2 ОК, требованиями доверия из части 3 ОК, как это указано ниже:

1. соответствие части 2 ОК — ПЗ соответствует части 2 ОК, если функциональные требования основаны только на функциональных компонентах из части 2 ОК;
2. расширение части 2 ОК — ПЗ соответствует расширению части 2, если функциональные требования включают функциональные компоненты, не содержащиеся в части 2;
3. соответствие части 3 ОК — ПЗ соответствует части 3 ОК, если требования доверия представлены в виде ОУД из части 3 ОК или пакета требований доверия, включающего только компоненты доверия из части 3 ОК;
4. усиление части 3 ОК — ПЗ соответствует усилению части 3 ОК, если требования доверия представлены в виде ОУД или пакета требований доверия и включают другие компоненты доверия из части 3 ОК;
5. расширение части 3 ОК — ПЗ соответствует расширению части 3 ОК, если требования доверия представлены в виде ОУД, дополненного требованиями доверия не из части 3 ОК, или пакета требований доверия, который включает требования доверия, не содержащиеся в части 3 ОК, или полностью состоит из них.

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

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

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

Технический отчет об оценке объекта оценки (продукта или системы ИТ)

Содержание ТОО, отражающего результаты оценки ОО, представлено на Рис. 6.

В разделе "Введение" ТОО оценщик должен привести следующую информацию:

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

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

Основное назначение рассматриваемого раздела ТОО состоит в указании степени архитектурного разделения главных компонентов ОО.

В разделе "Оценка" ТОО оценщик должен привести следующую информацию:

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

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

В разделе "Результаты оценки" ТОО для каждого вида деятельности по оценке ОО оценщик должен привести следующую информацию:

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

В разделе "Выводы и рекомендации" ТОО оценщик должен изложить выводы по результатам оценки ОО об удовлетворении ОО требованиям ЗБ.

Результат оценки ОО в целом должен формулироваться как "соответствие/несоответствие".

При положительном результате оценки должна быть указана степень, с которой можно доверять тому, что ОО соответствуют требованиям ОК. Должно поясняться соотношение с функциональными требованиями из части 2 ОК, требованиями доверия из части 3 ОК или же непосредственно с ПЗ, как это указано ниже [4]:

1. соответствие части 2 ОК — ОО соответствует части 2 ОК, если функциональные требования основаны только на функциональных компонентах из части 2 ОК;
2. расширение части 2 ОК— ОО соответствует расширению части 2 ОК, еслифункциональные требования включают функциональные компоненты, не содержащиеся в части 2 ОК;
3. соответствие части 3 ОК — ОО соответствует части 3 ОК, если требования доверия представлены в виде ОУД из части 3 ОК или пакета требований доверия, включающего только компоненты доверия из части 3 ОК;
4. усиление части 3 ОК — ОО соответствует усилению части 3 ОК, если требования доверия представлены в виде ОУД или пакета требований доверия и включают другие компоненты доверия из части 3 ОК;
5. расширение части 3 ОК — ОО соответствует расширению части 3 ОК, если требования доверия представлены в виде ОУД, дополненного требованиями доверия не из части 3 ОК, или пакета требований доверия, который включает требования доверия, не содержащиеся в части 3 ОК, или полностью состоит из них;
6. соответствие ПЗ — ОО соответствует ПЗ только в том случае, если он соответствует всем частям этого ПЗ.

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

В разделе "Перечень свидетельств оценки" оценщик должен привести следующую информацию относительно каждого свидетельства оценки:

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

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

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

Управление выходными материалами оценки

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

Назад Оглавление Вперед