LINEBURG


<< Пред. стр.

страница 26
(всего 26)

ОГЛАВЛЕНИЕ

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

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

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

10.5 Посещение объектов
В данном подразделе представлено общее руководство по посещению объектов.
1006

Конкретная и подробная информация дана в шагах оценивания тех подвидов деятельности,
где предусмотрены такие посещения:
а) ACM_AUT;
б) ACM_CAP.n (при n>2);
в) ADO_DEL;

180
г) ALC_DVS.
Посещение объектов разработки – полезный способ определения оценщиком, выполняются
1007

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

а) использованием системы УК, как описано в плане УК;
б) практическим применением процедур поставки;
в) применением мер безопасности во время разработки.
Во время оценки часто необходимы несколько встреч оценщика с разработчиком, и один из
1009

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

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

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

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

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




181
Приложение A Глоссарий
В данном приложении приведены сокращения и словарь терминов, которые используются в
1014

ОМО, но не представлены в ОК. Кроме этого, в данном приложении приведены названия
документов, на которые даются ссылки.


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

ТОО технический отчет об оценке
1016

СП сообщение о проблеме
1017



А.2 Словарь терминов
Для всех терминов, выделенных в тексте определений полужирным шрифтом, в данном
1018

подразделе даны собственные определения.
Вердикт (Verdict): Вывод оценщика «положительно», «отрицательно» или
1019

«неокончательно» применительно к некоторому элементу действий оценщика, компоненту
или классу доверия из ОК. См. также общий вердикт.
Вердикт органа по сертификации (Authority Verdict): Вывод органа по сертификации,
1020

подтверждающий или отклоняющий общий вердикт, который основан на результатах
деятельности по надзору за оценкой.
Зафиксировать (Record): Сохранить в документальной форме описания процедур,
1021

событий, данных наблюдений, предположений и результатов на уровне детализации,
достаточном для обеспечения возможности воспроизведения в будущем процесса
выполнения оценки.
Интерпретация (Interpretation): Разъяснение или расширение требования ОК, ОМО или
1022

системы оценки.
Исследовать (Examine): Вынести вердикт на основе анализа с использованием
1023

специальных знаний и опыта оценщика. Формулировка, в которой используется этот
глагол, указывает на то, что конкретно и какие свойства подвергаются анализу.
Методология (Methodology): Система принципов, процедур и процессов, применяемых
1024

для оценки безопасности ИТ.
Недостаток безопасности (Security flaw): Условие, которое само по себе или совместно с
1025

другими условиями определяет пригодную для использования уязвимость. Те нарушения
ПБО, которые возникают не из-за проблем, связанных с аппаратной, программной или
программно-аппаратной составляющей ОО, а из-за проблем, связанных с содержанием
руководств ОО, также признаются недостатками безопасности. Любые способы
эксплуатации продукта или системы вне предопределенной среды, приводящие к
нарушениям ПБО, не предполагаются для использования и поэтому не рассматриваются
как недостатки безопасности.
Общий вердикт (Overall Verdict): Положительный или отрицательный вывод оценщика
1026

по результатам оценки.
Отслеживание недостатка безопасности (Tracking a security flaw): Знание текущего
1027

состояния недостатка безопасности и его истории.

182
Пользователь ОО (TOE user): Служба эксплуатации или уполномоченное лицо,
1028

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

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

по сертификации требует от заявителя или разработчика для выполнения одного или
нескольких видов деятельности по проведению оценки или по надзору за оценкой.
Привести в отчете (сообщении) (Report): Включить результаты оценки и
1031

вспомогательные материалы в технический отчет об оценке или в сообщение о проблеме.
Проверить (Check): Вынести вердикт посредством простого сравнения. Специальные
1032

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

сущностей, которая показывает, какие сущности в первой совокупности каким сущностям
из второй соответствуют.
Релиз ОО (Release of a TOE): Продукт или система, являющаяся релизом
1034

сертифицированного ОО, в который вносились изменения. (Примечание: действие
выданного ранее сертификата не распространяется на те версии, в которые внесены
изменения, независимо от причин изменений).
Руководства ОО (TOE guidance): Руководства, предназначенные для администраторов и
1035

пользователей, в том числе руководство по устранению недостатков, процедуры поставки,
процедуры установки, генерации и запуска.
Свидетельство оценки (Evaluation Evidence): Фактическая поставка для оценки.
1036

Сертифицированный ОО (Certified TOE): Продукт или система и связанные с ними
1037

руководства, являвшиеся объектом оценки, оценка которого завершена, а ЗБ, отчет о
сертификации и сертификат официально выпущены.
Система оценки (Scheme): Совокупность правил, установленных органом по
1038

сертификации и определяющих среду оценки, включая критерии и методологию,
требуемые для проведения оценки безопасности ИТ.
Сообщение о проблеме (Observation Report): Сообщение, документально оформленное
1039

оценщиком, в котором он просит разъяснений или указывает на возникшую при оценке
проблему.
Технический отчет об оценке (Evaluation Technical Report): Отчет, выпущенный
1040

оценщиком и представленный в орган по сертификации, в котором приводится общий
вердикт и его строгое обоснование.


183
А.3 Ссылки
1. ГОСТ Р ИСО/МЭК 15408-2002. Информационная технология. МЕТОДЫ И
СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ. КРИТЕРИИ ОЦЕНКИ БЕЗОПАСНОСТИ
ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ. Часть 1. Введение и общая модель.
2. ГОСТ Р ИСО/МЭК 15408-2002. Информационная технология. МЕТОДЫ И
СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ. КРИТЕРИИ ОЦЕНКИ БЕЗОПАСНОСТИ
ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ. Часть 2. Функциональные требования безопасности.
3. ГОСТ Р ИСО/МЭК 15408-2002. Информационная технология. МЕТОДЫ И
СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ. КРИТЕРИИ ОЦЕНКИ БЕЗОПАСНОСТИ
ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ. Часть 3. Требования доверия к безопасности.
4. Гостехкомиссия России. Руководящий документ. «Безопасность информационных
технологий. Критерии оценки безопасности информационных технологий» - Москва, 2002.
5. ФСТЭК России. «Безопасность информационных технологий. Типовая методика
оценки профилей защиты и заданий по безопасности», 2005 (проект).
6. Common Methodology for Information Technology Security Evaluation.– Evaluation
Methodology for the Common Criteria for Information Technology Security Evaluation, Version 1.1a,
April 2002.
7. Common Methodology for Information Technology Security Evaluation, CEM-99/045, Part
2: Evaluation Methodology, Version 1.0, August 1999.




184

<< Пред. стр.

страница 26
(всего 26)

ОГЛАВЛЕНИЕ

Copyright © Design by: Sunlight webdesign