2015-01-21
1273
Первая часть стандарта включает описание рассмотренной выше структуры стандарта в целом, области его применения, список основных сокращений. Далее описывается используемый глоссарий, он представлен в табл.
Таблица
Глоссарий Общих критериев
| № | Термин | Смысловое содержание | Английский эквивалент |
| 1. | Активы | Информация или ресурсы, подлежащие защите контрмерами ОО | Assets |
| 2. | Атрибут безопасности | Информация, связанная с субъектами, пользователями и/или объектами, которая используется для осуществления ПБО | Security attribute |
| 3. | Аутентификаци-онные данные | Информация, используемая для верификации предъявленного идентификатора пользователя | Authentication data |
| 4. | Базовая СФБ | Уровень стойкости функции безопасности ОО, на котором, как показывает анализ, функция предоставляет адекватную защиту от случайного нарушения безопасности ОО нарушителями с низким потенциалом нападения | SOF-basic |
| 5. | Внешний объект ИТ | Любые продукт или система ИТ, доверенные или нет, находящиеся вне ОО и взаимодействующие с ним | External IT entity |
| 6. | Выбор | Выделение одного или нескольких элементов из перечня в компоненте | Selection |
| 7. | Внутренний канал связи | Канал связи между разделёнными частями ОО | Internal communication channel |
| 8. | Высокая СФБ | Уровень стойкости функции безопасности ОО, на котором, как показывает анализ, функция предоставляет адекватную защиту от тщательно спланированного и организованного нарушения безопасности ОО нарушителями с высоким потенциалом нападения | SOF-high |
| 9. | Данные ФБО | Данные, созданные ФБО или для ФБО, которые могут повлиять на выполнение ФБО | TSF data |
| 10. | Данные пользователя | Данные, созданные пользователем и для пользователя, которые не влияют на выполнение ФБО | User data |
| 11. | Доверенный канал | Средство взаимодействия между ФБО и удалённым доверенным продуктом ИТ, обеспечивающее необходимую степень уверенности в поддержании ПБО | Trusted channel |
| 12. | Доверенный маршрут | Средство взаимодействия между пользователем и ФБО, обеспечивающее необходимую степень уверенности в поддержании ПБО | Trusted path |
| 13. | Доверие | Основание для уверенности в том, что сущность отвечает своим целям безопасности | Assurance |
| 14. | Зависимость | Соотношение между требованиями, при котором требование, от которого зависят другие требования, должно быть, как правило, удовлетворено, чтобы и другие требования могли бы отвечать своим целям | Dependency |
| 15. | Задание по безопасности | Совокупность требований безопасности и спецификаций, предназначенная для использования в качестве основы для оценки конкретного ОО | Security target |
| 16. | Идентификатор | Представление уполномоченного пользователя (например, строка символов), однозначно его идентифицирующее. Таким представлением может быть либо полное или сокращённое имя этого пользователя, либо его псевдоним | Identity |
| 17. | Интерфейс функций безопасности ОО | Совокупность интерфейсов, как интерактивных (человеко-машинные интерфейсы), так и программных (интерфейсы прикладных программ), с использованием которых осуществляется доступ к ресурсам ОО при посредничестве ФБО или получение от ФБО какой-либо информации | TOE security functions interface |
| 18. | Итерация | Более чем однократное использование компонента при различном выполнении операций | Iteration |
| 19. | Класс | Группа семейств, объединённых общим назначением | Class |
| 20. | Компонент | Наименьшая выбираемая совокупность элементов, которая может быть включена в ПЗ, ЗБ или пакет | Component |
| 21. | Механизм проверки правомочности обращений | Реализация концепции монитора обращений, обладающая следующими свойствами: защищённостью от проникновения; постоянной готовностью; простотой, достаточной для проведения исчерпывающего анализа и тестирования | Reference validation mechanism |
| 22. | Модель политики безопасности ОО | Структурированное представление политики безопасности, которая должна быть осуществлена ОО | TOE security policy model |
| 23. | Монитор обращений | Концепция абстрактной машины, осуществляющей политику управления доступом ОО | Reference monitor |
| 24. | Назначение | Спецификация определённого параметра в компоненте | Assignment |
| 25. | Неформальный | Выраженный на естественном языке | Informal |
| 26. | Область действия ФБО | Совокупность возможных взаимодействий с ОО или в его пределах, которые подчинены правилам ПБО | TSF scope of control |
| 27. | Объект | Сущность в пределах ОДФ, которая содержит или получает информацию и над которой субъекты выполняют операции | Object |
| 28. | Объект оценки | Подлежащие оценке продукт ИТ или система с руководствами администратора и пользователя | Target of evaluation |
| 29. | Орган оценки | Организация, которая посредством системы оценки обеспечивает реализацию ОК для определённого сообщества и в связи с этим устанавливает стандарты и контролирует качество оценок, проводимых организациями в пределах данного сообщества | Evaluation authority |
| 30. | Оценка | Оценка ПЗ, ЗБ или ОО по определённым критериям | Evaluation |
| 31. | Оценочный уровень доверия | Пакет компонентов доверия из части 3 настоящего стандарта, представляющий некоторое положение на предопределённой в стандарте шкале доверия | Evaluation assurance level |
| 32. | Пакет | Предназначенная для многократного использования совокупность функциональных компонентов или компонентов доверия (например, ОУД), объединённых для удовлетворения совокупности определённых целей безопасности | Package |
| 33. | Передача в пределах ОО | Передача данных между разделёнными частями ОО | Internal TOE transfer |
| 34. | Передача за пределы области действия ФБО | Передача данных сущностям, не контролируемым ФБО | Transfer outside TSF control |
| 35. | Передача между ФБО | Передача данных между ФБО и функциями безопасности других доверенных продуктов ИТ | Inter-TSF transfers |
| 36. | Политика безопасности организации | Одно или несколько правил, процедур, практических приёмов или руководящих принципов в области безопасности, которыми руководствуется организация в своей деятельности | Organizational security policies |
| 37. | Политика безопасности ОО | Совокупность правил, регулирующих управление активами, их защиту и распределение в пределах ОО | TOE security policy |
| 38. | Политика функции безопасности | Политика безопасности, осуществляемая ФБ | Security function policy |
| 39. | Полуфор-мальный | Выраженный на языке с ограниченным синтаксисом и определённой семантикой | Semiformal |
| 40. | Пользователь | Любая сущность (человек-пользователь или внешний объект ИТ) вне ОО, которая взаимодействует с ОО | User |
| 41. | Потенциал нападения | Прогнозируемый потенциал для успешного (в случае реализации) нападения, выраженный в показателях компетентности, ресурсов и мотивации нарушителя | Attack potential |
| 42. | Продукт | Совокупность программных, программно-аппаратных и/или аппаратных средств ИТ, предоставляющая определённые функциональные возможности и предназначенная для непосредственного использования или включения в различные системы | Product |
| 43. | Профиль защиты | Независимая от реализации совокупность требований безопасности для некоторой категории ОО, отвечающая специфическим запросам потребителя | Protection profile |
| 44. | Расширение | Добавление в ЗБ или ПЗ функциональных требований, не содержащихся в части 2 настоящего стандарта, и/или требований доверия, не содержащихся в части 3 настоящего стандарта | Extension |
| 45. | Ресурс ОО | Всё, что может использоваться или потребляться в ОО | TOE resource |
| 46. | Роль | Заранее определённая совокупность правил, устанавливающих допустимое взаимодействие между пользователем и ОО | Role |
| 47. | Связность | Свойство ОО, позволяющее ему взаимодействовать с объектами ИТ, внешними по отношению к ОО. Это взаимодействие включает обмен данными по проводным или беспроводным средствам на любом расстоянии, в любой среде или при любой конфигурации | Connectivity |
| 48. | Секрет | Информация, которая должна быть известна только уполномоченным пользователям и/или ФБО для осуществления определённой ПФБ | Secret |
| 49. | Семейство | Группа компонентов, которые объединены одинаковыми целями безопасности, но могут отличаться акцентами или строгостью | Family |
| 50. | Система | Специфическое воплощение ИТ с конкретным назначением и условиями эксплуатации | System |
| 51. | Система оценки | Административно-правовая структура, в рамках которой в определённом обществе органы оценки применяют ОК | Evaluation scheme |
| 52. | Средняя СФБ | Уровень стойкости функции безопасности ОО, на котором, как показывает анализ, функция предоставляет адекватную защиту от прямого или умышленного нарушения безопасности ОО нарушителями с умеренным потенциалом нападения | SOF-medium |
| 53. | Стойкость функции безопасности | Характеристика функции безопасности ОО, выражающая минимальные усилия, предположительно необходимые для нарушения её ожидаемого безопасного поведения при прямой атаке на лежащие в её основе механизмы безопасности | Strength of function |
| 54. | Субъект | Сущность в пределах ОДФ, которая инициирует выполнение операций | Subject |
| 55. | Уполномочен-ный пользователь | Пользователь, которому в соответствии с ПБО разрешено выполнять какую-либо операцию | Authorized user |
| 56. | Усиление | Добавление одного или нескольких компонентов доверия из части 3 настоящего стандарта в ОУД или пакет требований доверия | Augmentation |
| 57. | Уточнение | Добавление деталей в компонент | Refinement |
| 58. | Функции безопасности ОО | Совокупность всех функций безопасности ОО, направленных на осуществление ПБО | TOE security functions |
| 59. | Функция безопасности | Функциональные возможности части или частей ОО, обеспечивающие выполнение подмножества взаимосвязанных правил ПБО | Security function |
| 60. | Формальный | Выраженный на языке с ограниченным синтаксисом и определённой семантикой, основанной на установившихся математических понятиях | Formal |
| 61. | Человек-пользователь | Любое лицо, взаимодействующее с ОО | Human user |
| 62. | Цель безопасности | Изложенное намерение противостоять установленным угрозам и/или удовлетворять установленной политике безопасности организации и предположениям | Security objective |
| 63. | Элемент | Неделимое требование безопасности | Element |
Хотя ОК не предписывают конкретную методологию разработки или модель жизненного цикла, они, тем не менее представляют некоторые основополагающие предположения о соотношениях между требованиями безопасности и собственно разрабатываемым ОО. В основе данной методологии лежит уточнение требований безопасности, сведенных в краткую спецификацию в составе задания по безопасности, являющегося по сути исходным документом для разработки и последующей оценки (фактически некий аналог ТЗ). Каждый последующий уровень уточнения представляет декомпозицию проекта с его дополнительной детализацией. Наиболее подробным (и наименее абстрактным) представлением в итоге является непосредственно реализация ОО.
|
|
|
|
|
|
|
|
|
|
|
|
Количество уровней детализации при этом зависит от уровня доверия, который требуется обеспечить. В ОК предусмотрены следующие промежуточные этапы детализации, формируемые на основе задания по безопасности: функциональная спецификация, проект верхнего уровня, проект нижнего уровня и реализация.
С методологией создания ОО тесно связан процесс его оценки, который может проводиться как параллельно с разработкой, так и после ее окончания. Основными исходными материалами для оценки ОО являются:
совокупность материалов, характеризующих ОО, включая прошедшее оценку ЗБ в качестве основы;
сам ОО, безопасность которого требуется оценить;
критерии, методология и система оценки.
Кроме того, в качестве исходных материалов для оценки возможно также использование вспомогательных материалов и специальных знаний в области безопасности ИТ, которыми располагает оценщик и сообщество участников оценок.
Ожидаемым результатом оценки является подтверждение удовлетворения объектом оценки требований безопасности, изложенных в его ЗБ, а также один или несколько отчетов, документирующих выводы оценщика относительно ОО, сделанные в соответствии с критериями оценки. Такие отчеты, помимо разработчика, очевидно, будут полезны также реальным и потенциальным потребителям продукта или системы.
Таким образом, основой разработки и эксплуатации любого ОО в Общих критериях провозглашается совокупность требований безопасности.
В ОК определены 3 группы конструкций для описания требований безопасности: пакет, профиль защиты (ПЗ) и задание по безопасности (ЗБ).
Пакет представляет собой некую промежуточную комбинацию компонентов безопасности. Он предназначен для многократного использования и определяет требования, которые известны как полезные и эффективные для достижения некоторых установленных целей. Допускается применение пакета при создании более крупных пакетов, профилей защиты и заданий по безопасности.
Профиль защиты содержит совокупность требований безопасности, взятых из ОК или сформулированных в явном виде. ПЗ позволяет выразить независимые от конкретной реализации требования безопасности для некоторой совокупности ОО, которые полностью согласуются с набором целей безопасности. ПЗ также предназначен для многократного использования и определения как функциональных требований, так и требований доверия к ОО, которые полезны и эффективны для достижения установленных целей. ПЗ также содержит логическое обоснование требований и целей безопасности.
Задание по безопасности содержит совокупность требований безопасности, которые могут быть определены ссылками на ПЗ, непосредственно на функциональные компоненты или компоненты доверия или же сформулированы в явном виде. ЗБ позволяет выразить требования безопасности для конкретного ОО, которые по результатам оценки ЗБ признаны полезными и эффективными для достижения установленных целей безопасности. ЗБ является основой для соглашения между всеми сторонами относительно того, какую безопасность предлагает ОО.
В первой части ОК подробно описан и процесс формирования требований безопасности, поскольку данные требования, выраженные в итоге в ЗБ, должны быть обоснованы и непротиворечивы, достаточны, после чего только на их основе производится оценка ОО.
В соответствии с ОК на основании исследования политик безопасности, угроз и рисков должны быть сформированы следующие материалы, относящиеся к безопасности:
изложение предположений, которым удовлетворяла бы среда разрабатываемой ИТ для того, чтобы она считалась безопасной;
изложение угроз безопасности активов, в котором были бы идентифицированы все угрозы, при этом угрозы раскрываются через понятия агента угрозы (нарушителя), предполагаемого метода нападения, любых уязвимостей, которые являются предпосылкой для нападения, и идентификации активов, которые являются целью нападения;
изложение политики безопасности, применяемой в организации, для системы ИТ такая политика может быть описана достаточно точно, тогда как для продуктов ИТ общего предназначения или класса продуктов о политике безопасности организации могут быть сделаны, при необходимости, только рабочие предположения.
Результаты анализа среды безопасности затем должны использоваться для установления целей безопасности, которые направлены на противостояние установленным угрозам, а также проистекают из установленной политики безопасности организации и сделанных предположений. Необходимо, чтобы цели безопасности были согласованы с определенными ранее целями применения или предназначением продукта, а также со сведениями о физической среде.
Требования безопасности являются результатом преобразования целей безопасности в совокупность требований безопасности для объекта оценки и требований безопасности для среды, которые, в случае их удовлетворения, обеспечат для него способность достижения его целей безопасности.
Имеется две различные категории требований безопасности – функциональные требования и требования доверия.
Функциональные требования налагаются на те функции, которые предназначены для поддержания безопасности ОО и определяют желательный безопасный режим функционирования. Примерами функциональных требований являются требования к идентификации, аутентификации, аудиту безопасности и т.д.
Требования доверия налагаются на действия разработчика, представленные свидетельства и действия оценщика. Примерами требований доверия являются требования к строгости процесса разработки, по поиску потенциальных уязвимостей и анализу их влияния на безопасность.
Требования безопасности обычно включают как требования наличия желательных режимов функционирования, так и требования отсутствия нежелательных режимов. Наличие желательного режима обычно можно продемонстрировать путем непосредственного применения или испытаний (тестирования). Не всегда удается убедительно продемонстрировать отсутствие нежелательного режима. Уменьшению риска наличия нежелательного режима в значительной мере способствуют испытания (тестирование), экспертиза проекта и окончательной реализации.
