ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

Информационная технология

МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ

Основы доверия к безопасности информационных

технологий

Часть 2

Методы доверия

ISO/IEC TR 15443-2:2005 Information technology — Security techniques — A framework for IT security assurance — Part 2: Assurance methods (IDT)

Издание официальное

Москва

Стандартинформ

2013

Предисловие

Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. № 184-ФЗ «О техническом регулировании», а правила применения национальных стандартов Российской Федерации — ГОСТ Р 1.0-2004 «Стандартизация в Российской Федерации. Основные положения»

Сведения о стандарте

1    ПОДГОТОВЛЕН Федеральным государственным учреждением «Государственный научно-исследовательский испытательный институт проблем технической защиты информации Федеральной службы по техническому и экспортному контролю» (ФГУ «ГНИИИ ПТЗИ ФСТЭК России»), Обществом с ограниченной ответственностью «Центр безопасности» (ООО «ЦБИ») на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4

2    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 1 декабря 2011 г. № 690-ст

3    Настоящий стандарт идентичен международному документу ISO/IEC TR 15443-2:2005 «Информационная технология. Методы и средства обеспечения безопасности. Основы доверия к безопасности ИТ. Часть 2. Методы доверия» (ISO/IEC TR 15443-2:2005 «Information technology — Security techniques — Aframeworkfor IT security assurance — Part 2: Assurance methods»)

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА

4    ВВЕДЕН ВПЕРВЫЕ

Информация об изменениях к настоящему стандарту публикуется в ежегодно издаваемом информационном указателе «Национальные стандарты», а текст изменений и поправок—в ежемесячно издаваемых информационных указателях «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячно издаваемом информационном указателе «Национальные стандарты». Соответствующая информация, уведомления и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет

© Стандартинформ, 2013

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

Продолжение таблицы 2

Раздел Доверие — фаза-» — подход 4- Проект/ реализация Интеграция/ верификация Ввод в действие/ переход Функционирова ние 6.6 RAMP — фаза поддержки классификации Д ->D-> -И ^о-+ 6.7 ERM — поддержка классификации оценки (в общем) Д ->D-> -и ^0-+ 6.8 ТТАР — программа оценки доверенной технологии Д ->D-> -и 6.9 ТРЕР — программа оценки доверенного продукта Д ->D-> -и 6.10 Рациональный комплексный 1 _. 1 , 1 1 процесс® (RUP®) И ^ В В В 6.11 ИСО/МЭК 15288 — процессы жизненного цикла системы ->D-> -и ^0-+ 6.12 ИСО/МЭК 12207 — процессы жизненного цикла ПО ->D-> -и 6.13 V — модель ->D-> -и-> ->Т-> 6.14 ИСО/МЭК 14598 — оценка программного продукта ->D-> 6.15 Услуги по обеспечению базовой безопасности Х/Open % ->D-> 6.16 SCT — тестирование строгого соответствия -и 6.17 ИСО/МЭК 21827 — проектирование безопасности работы систем — модель зрелости (SSE-CMM®) % D 1 т о 6.18 ТСММ —доверенная модель технологической зрелости Д D 1 6.19 CMMI — интеграция модели технологической зрелости® D 1 т о 6.20 ИСО/МЭК 15504 — оценка программного процесса D 1 т о 6.21 ССМ — модель технологической зрелости® (для ПО) D 1 6.22 SE-CMM® — модель технологической зрелости системного проектирования® D 1 6.23 TSDM — методология разработки выверенного ПО D 1 6.24 SdoC — заявление поставщика о соответствии D 6.25 SA-CMM® — модель зрелости возможностей приобретения программного обеспечения® т 6.26 ИСО серия 9000 — менеджмент Н Н Н I I качества III II

Окончание таблицы 2

Раздел Доверие — фаза-» — подход 1 Проект/ реализация Интеграция/ верификация Ввод в действие/ переход Функционирова ние 6.27 ИСО 13407—сконцентрированный на человеке проект D 6.28 Генеалогия разработчика (в общем) D 6.29 ИСО/МЭК 17025 — доверие к аккредитации D 6.30 ИСО/МЭК 13335 — руководства по управлению безопасностью ИТ (GMITS) £ 1 т о 6.31 BS 7799-2 — системы управления информационной безопасностью. Спецификация с руководством £ о 6.32 ИСО/МЭК 17799 — практические правила управления информационной безопасностью о 6.33 FR — исправление дефектов (в общем) о 6.34 Базовое руководство по защите ИТ £ -*о-» 6.35 Тестирование проникновения £ ->о-» 6.36 Аттестация персонала (не связанная с безопасностью) О 6.37 Аттестация персонала (связанная с безопасностью) £ D 1 т О

5.5 Методология представления

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

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

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

Каждый краткий обзор подразделяют на следующие составные части:

-    цель: краткое отличительное назначение метода;

-    описание: краткое описание метода;

-    источники, описывающие: адрес/ссылку на комитеты и/или организации и документы по методу и/или стандартизации.

6 Методы обеспечения доверия

6.1 ИСО/МЭК15408 — критерии оценки безопасности информационных технологий g

—»D-» -*1-» -Л--+ -»а-»

7

6.1.1    Цель

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

6.1.2    Описание

Общие критерии разработаны по поручению правительственных учреждений, связанных с информационной безопасностью, как способ независимой оценки характеристик безопасности продуктов и систем ИКТ. Критерии были разработаны во взаимодействии с совместным техническим комитетом 1, подкомитет 27, «Методы и средства обеспечения безопасности» (СТК1 ПК 27) и опубликованы как международный стандарт ИСО/МЭК15408.

Общие критерии разделяют понятия «функциональные возможности безопасности» и «доверие к безопасности» и детально специфицируют методы, средства и функции, которые могут способствовать созданию уверенности в соответствии продукта безопасности целям безопасности. Конкретные методы, средства и функции доверия определены в ИСО/МЭК 15408-3 и в первую очередь (но не исключительно в этих целях) предназначены для получения доверия посредством независимой оценки или верификации. Планируется возможность верификации согласованного применения критериев оценки посредством схем национальной сертификации.

В рамках ИСО/МЭК 15408-3 методы и средства обеспечения доверия разделены на четыре области применения, называемые «классами». В пределах каждого класса определены различные методы, называемые «семействами». В каждом семействе имеются один или более уровней строгости. Уровни строгости, по которым могут применяться методы, называются «компонентами». Каждый компонент обозначает необходимые точные действия и элементы доказательства.

В рамках ИСО/МЭК 15408-3 определены несколько пакетов компонентов доверия, работающих вместе на взаимно дополняющей основе. Пакеты компонентов доверия, работающих вместе на взаимно дополняющей основе, называют «оценочными уровнями доверия».

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

6.1.3    Источники

ИСО/МЭК 15408-1; ИСО/МЭК 15408-2; ИСО/МЭК 15408-3.

Примечание — ИСО/МЭК 15408 является результатом деятельности ИСО/МЭК с совместным техническим комитетом 1, подкомитет 27, рабочая группа 3 (СТК 1/ПК 27/РГ 3) «Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности»

6.2 TCSEC — критерии оценки безопасности доверенных компьютерных систем g

-»D->

-►I-*-

-►О-*

6.2.1    Цель

Классификация или определение класса безопасности продукта компьютерной системы.

6.2.2    Описание

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

Продукт «соответствует» TCSEC при условии его оценки по «Программе оценивания доверенного продукта» (ТРЕР) или «Программе оценки доверенной технологии» (ТТАР) на соответствие требованиям установленного класса TCSEC или если независимая оценка выявила у продукта наличие характеристик и доверия этого класса.

Класс является специфической совокупностью требований TCSEC, которым соответствует оцениваемая система. В TCSEC имеется семь классов в порядке убывания характеристик и доверия: А1, ВЗ, В2, В1, С2, С1 и D. Следовательно, система, оцененная по классу ВЗ, имеет больше характеристик безопасности и/или больше уверенности в должном функционировании характеристик безопасности, чем система, оцененная по классу В1. Требования для более высокого класса всегда являются расширенной

ГОСТ Р 54582-2011/ISO/IEC/TR 15443-2:2005

версией более низшего класса. Таким образом, система класса В2 соответствует каждому функциональному требованию класса С2 и имеет более высокий уровень доверия.

Уровнем доверия является совокупность классов (см. вопрос 11) из TCSEC [см. FAQ (часто задаваемые вопросы) концепций критериев, вопрос 1]. В «Оранжевой книге» определены четыре уровня доверия в порядке убывания доверия и уменьшения характеристик: А, В, С и D. Следовательно, система, оцененная по конкретному классу уровня доверия В, имеет больше характеристик безопасности и/или больше уверенности в должном функционировании характеристик безопасности, чем система, оцененная по конкретному классу уровня доверия С. Хотя интерпретация подсистем компьютерной безопасности (CSSI) TCSEC специфицирует критерии для различных классов D, они не отражены в самих TCSEC, которые не предъявляют требований к системам уровня доверия D. По умолчанию неклассифицированной системой является уровень доверия D.

Требованиями к различным классам являются:

Класс D: минимальная защита — резервируют оцененные системы, которые не отвечают требованиям более высокого класса.

Класс С1: необязательная защита — доверенная вычислительная база (ТСВ) системы класса С1 номинально удовлетворяет требования необязательной защиты посредством разделения пользователей и данных. ТСВ объединяет несколько видов надежных мер управления, способных осуществлять ограничения доступа на индивидуальной основе, т. е. позволяющих пользователям защищать информацию о проекте или персональные данные или предотвращать случайное считывание или разрушение своих данных другими пользователями. Предполагается, что класс С1 объединяет пользователей, обрабатывающих данные на одинаковом уровне конфиденциальности.

Класс С2: управляемая защита доступа — системы этого класса осуществляют более тщательное необязательное управление доступом, чем системы класса С1, делая пользователей индивидуально ответственными за свои действия посредством регистрационных процедур, проверки событий, связанных с безопасностью, и изоляции ресурсов.

Класс В1: мандатная защита — для систем класса В1 требуются все характеристики, необходимые для класса С2. Кроме того, должны быть в наличии: неофициальная модель политики безопасности, маркировка данных (например, секретной или частной информации) и обязательный контроль доступа к указанным субъектам или объектам. Необходимо существование потенциальных возможностей точной маркировки выдаваемой информации.

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

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

Класс А1: верифицированный проект — системы класса А1 функционально эквивалентны системам класса ВЗ в отсутствие дополнительных архитектурных особенностей или требований к политике безопасности. Отличительной характеристикой систем этого класса является анализ, следующий из формальной спецификации проекта и методов верификации, и полученная высокая степень доверия к правильности реализации ТСВ. По своему характеру это доверие является экспериментальным (опытным), начиная с официальной модели политики безопасности и официальной высокоуровневой спецификации (FTLS) проекта. FTLS является высокоуровневой спецификацией системы, записанной на формальном математическом языке для формирования гипотез из теорем (демонстрирующих соот-

9

ветствие спецификации системы ее формальным требованиям) и их формального доказательства. Для соответствия расширенному проекту и анализу проекта ТСВ, необходимых для систем класса А1, требуется более строгое конфигурационное управление и формирование процедур безопасного распределения системы по местам эксплуатации. Администратору безопасности системы должна быть оказана поддержка.

6.2.3 Источники

См. [45].

Примечание — Все TCSEC, их интерпретации и руководства имеют разноцветные обложки и иногда называются «Радужной серией». TCSEC являются внутренним стандартом и продуктом Министерства обороны США.

6.3 ITSEC/ITSEM — методология и критерии оценивания безопасности информационных технологий Д

->D->

->1->

6.3.1    Цель

Предоставление структуры критериев и методологии оценивания безопасности ИТ для европейского рынка.

6.3.2    Описание

«Критерии оценивания безопасности информационных технологий (ITSEC)» и «Руководство по оцениванию безопасности информационных технологий (ITSEM)» находятся среди документов, предшествующих общим критериям и общей методологии оценки. Они были разработаны четырьмя европейскими странами: Францией, Германией, Нидерландами и Великобританией.

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

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

-    способность функций и механизмов обеспечения безопасности ОО объединяться на основе взаимной поддержки и формировать интегрированное и эффективное целое;

-    способность механизмов обеспечения безопасности ОО противостоять прямым атакам;

-    возможность на практике компрометации безопасности известными уязвимостями безопасности в конструкции ОО;

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

-    возможность компрометации на практике безопасности известными уязвимостями безопасности при функционировании ОО.

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

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

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

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

ГОСТ Р 54582-2011/ISO/IEC/TR 15443-2:2005

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

Дополнительно ITSEC в общих чертах намечает взаимосвязь уровней оценивания с классами ITSEC.

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

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

6.3.3 Источники

См. [40], [41].

Примечание — ITSEC/ITSEM являются результатом разработок Европейской комиссии, Директората главного информационного общества, отделения информации и коммуникации, BU 24 0/41, Rue de la Loi, В-1049 Брюссель.

С Директоратом главного информационного общества можно связаться через универсальный указатель ресурса http:/europa. eu. i nt/po l/i nfso/i nd ex en.htm.

6.4 CTCPEC — канадские критерии оценивания доверенного продукта %

->D->

-И->-

6.4.1    Цель

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

6.4.2    Описание

Канадские критерии оценивания доверенного продукта (СТСРЕС) были разработаны со следующими тремя целями:

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

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

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

При доверенной обработке дается определение двум типам требований:

1)    специфические требования к сервисам безопасности;

2)    требования доверия.

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

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

Требования доверия могут применяться ко всему спектру продуктов обработки электронных данных или сред обработки прикладных программ без специальной интерпретации.

11

6.4.3 Источники

См. [31].

Примечание — СТСРЕС является стандартом для внутреннего пользования и результатом разработки Института коммуникационной безопасности (CSE), P.O.Box 9703, Terminal, Ottawa, Ontario K1G 3Z4, Canada.

6.5 KISEC/KISEM — корейские критерии и методология оценивания информационной безопасности g

-»D->

-►I-*-

-Ю-»

6.5.1    Цель

Предоставление структуры критериев и методологии оценивания безопасности для межсетевых экранов и систем обнаружения вторжения в Корее.

6.5.2    Описание

«Корейские критерии оценивания безопасности информации» (KISEC) и «Корейская методология оценивания безопасности информации» (KISEM) были разработаны в 1998 г. стремя целями:

-    обеспечение иерархической оценочной шкалы для оценивания функций безопасности межсетевых экранов и систем обнаружения вторжения;

-    обеспечение метода специфицирования высоконадежных межсетевых экранов и систем обнаружения вторжения при закупке;

-    накопление знаний, связанных с оцениванием безопасности, путем эксплуатации собственных критериев и методологии оценивания.

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

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

Ниже приведены характеристики каждого оценочного уровня:

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

-    уровень К2 должен соответствовать требованиям уровня К1 и быть способным создавать и сохранять записи аудита деятельности, связанной с безопасностью. Также может потребоваться документация архитектурного проекта. Необходимо провести анализ уязвимостей и неправильного применения межсетевых экранов и систем обнаружения вторжения;

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

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

-    уровень К5 должен соответствовать всем требованиям уровня К4 и обеспечивать функцию взаимной аутентификации. Необходима также формальная модель политики безопасности межсетевого экрана или системы обнаружения вторжения. Функциональные характеристики, документация по архитектурному проектированию и рабочему проекту должна оформляться в полуформальном виде;

ГОСТ Р 54582-2011/ISO/IEC/TR 15443-2:2005

-    уровень Кб должен соответствовать требованиям уровня К5. На этом уровне должна верифицироваться согласованность между документацией рабочего проекта, исходным кодом и/или документацией по проектированию оборудования;

-    уровень К7 должен соответствовать всем требованиям уровня Кб. На этом уровне функциональные спецификации и документация по архитектурному проектированию должны быть записаны в формате для его синхронизации с формальной моделью политики безопасности системы.

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

6.5.3 Источники

6.6 RAMP — фаза поддержания классификации Д

См. [50], [51]. Примечание — KISEC/KISEM является результатом разработки Агентства по информационной безопасности Кореи, 78, Karakdong, SonOna-Gu, Seoul 138-160, Korea.

-»D-> -и->-

6.6.1    Цель

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

6.6.2    Описание

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

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

6.6.3    Источники

См. [32].

6.7 ERM — поддержание классификации при оценивании (в общем Д)

Примечание — RAMP является результатом разработки National Computer Security Center (NCSC), 9800 Savage Road, Fort George G. Meade, Maryland 20755-6000, USA.

-»D-> ->1-> ->о->

6.7.1    Цель

Распространение полученного доверия за рамки жизненного цикла и/или периода времени, особенно после модификации.

6.7.2    Описание

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

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

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

13

мость метода обеспечения доверия, называемого «поддержание классификации при оценивании», от обеих фаз доверия — проектирование/разработка и эксплуатация.

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

-    применяемые требования: требования, по которым продукт должен оцениваться;

-    аудит ERM: анализ доказательства RAMP, основанный на подходящем типичном образце и предназначенный для обеспечения реализации только утвержденных изменений и удовлетворительного проведения анализа безопасности. В дополнение к необходимым аудитам RAMP, проводимым VSA, группой анализа безопасности могут выполняться апериодические аудиты RAMP;

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

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

Операторами RAMP обычно являются:

-    группа анализа безопасности: отдельные лица (например, VSA, дополнительные оценщики), ответственные за проведение анализа, а также за представление и защиту доказательства RAMP перед комитетом по техническому надзору;

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

В США ERM было формализовано как RAMP и применялось для классификации в ТРЕР и ИСО/МЭК21827 (SSE-CMM).

В Великобритании ERM было формализовано каксхема поддержания сертификатов и основано на ранжировании ITSEC.

Критерии оценивания ИСО/МЭК 15408 признают ERM, но предоставляют поддержание на должном уровне оценивания национальным органам, надзирающим за схемами оценивания.

6.7.3 Источники

Программу поддержания на должном уровне оценивания США см. 6.6.

Программу поддержания на должном уровне оценивания Великобритании см. [44].

Примечание — Система поддержания сертификатов является результатом разработки Senior Executive, UK IT Security Evaluation and Certification Scheme, Certification Body, PO Box 152, Cheltenham Glos GL 52 5UF.

6.8 TTAP — программа оценки доверенных технологий g

-»D->

-►I-*-

6.8.1    Цель

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

6.8.2    Описание

Программа оценки доверенных технологий (ТТАР) является совместной разработкой Агентства национальной безопасности (АНБ) и Национального института стандартов и технологий (НИСТ) по созданию коммерческих предприятий для оценивания доверенных продуктов. ТТАР формирует, утверждает коммерческие предприятия по оцениванию и надзирает за ними. В начальной стадии программа направлена на продукты со свойствами и степенями доверия, характеризуемыми общими критериями оценки безопасности информационных технологий (CCITSE).

Для проведения оценивания по ТТАР организация должна быть аттестована какорган по оцениванию по ТТАР (TEF). Сначала будущее TEF обращается к Совету по надзору ТТАР за временным разрешением. В положительном случае будущему TEF даются полномочия на проведение пробного оценивания и данные о нем помещаются в список перспективныхTEF. Затем перспективное TEF заключает договор с поставщиком и проводит пробное оценивание доверенного продукта. После пробного

ГОСТ Р 54582-2011/ISO/IEC/TR 15443-2:2005

оценивания статус «временное» аннулируется и TEF может проводить оценивания в соответствии с ТТАР.

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

6.8.3 Источники

См. [28].

Примечание — ТТАР является внутренним стандартом правительства США и является разработкой Совета по надзору ТТАР для передачи Агентству национальной безопасности, 9800 Savage Road, Suite 6740, Ft. Meade, Md. 20755-7640.

6.9 TPEP — программа оценивания доверенного продукта Д

6.9.1    Цель

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

6.9.2    Описание

По программе оценивания доверенного продукта (ТРЕР) поставщики обращаются в Агентство национальной безопасности со своим коммерческим продуктом обеспечения компьютерной безопасности с запросом на его оценивание, нацеленное на определенный уровень ранжирования доверия. Оценщики, работающие по ТРЕР, используют TCSEC и его интерпретации для оценки качества соответствия продукта требованиям целевого ранжирования. Результаты оценивания по ТРЕР публикуются ежеквартально в перечне оцененных продуктов (EPL) в разделе 4 Каталога услуг и продуктов по обеспечению безопасности информационных систем.

Конечной целью ТРЕР является стимулирование широкой доступности доверенных продуктов обеспечения компьютерной безопасности для владельцев данных и пользователей, желающих защитить свою секретную и/или конфиденциальную информацию. Дополнительными целями являются:

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

-    обеспечение использования доверенных продуктов при конструировании внедряемой доверенной системы;

-    обеспечение специального руководства по практичности доверенных продуктов;

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

-    стимулирование открытых и скоординированных деловых отношений с национальными и оборонными информационными инфраструктурами.

6.9.3    Источники

См. [46].

Примечание — ТРЕР была заменена программой оценки доверенных технологий. В настоящее время новые оценки с помощью TCSEC не проводятся. См. TCSEC.

ТРЕР является внутренним стандартом правительства США и разработкой Агентства национальной безопасности, 9800 Savage Road, Suite 6740, Ft. Meade, Md. 20755-7640.

6.10 Рациональный универсальный процесс® (RUP®)

|    ->D->    |    ->l->    |    ->T->    |

6.10.1 Цель

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

ГОСТ Р 54582-2011/ISO/IEC/TR 15443-2:2005

Содержание

1 Область применения...................................................1

1.1    Назначение......................................................1

1.2    Область применения................................................1

1.3    Ограничения.....................................................2

2    Нормативные ссылки..................................................2

3    Термины, определения и сокращения........................................4

4    Краткий обзор и представление методов обеспечения доверия........................4

5    Фаза жизненного цикла доверия и условные обозначения...........................4

5.1    Подход к обеспечению доверия и условные обозначения.........................4

5.2    Актуальность и условные обозначения....................................5

5.3 Значимость безопасности и условные обозначения............................5

5.4    Обзор методов обеспечения доверия.....................................5

5.5    Методология представления...........................................7

6    Методы обеспечения доверия.............................................7

6.1    ИСО/МЭК 15408 — критерии оценки безопасности информационных технологий Д........7

6.2    TCSEC — критерии оценки безопасности доверенных компьютерных систем    Д..........8

6.3    ITSEC/ITSEM — методология и критерии оценивания безопасности информационных технологий Д .........................................................10

6.4    СТСРЕС — канадские критерии оценивания доверенного продукта Д................11

6.5    KISEC/KISEM — корейские критерии и методология оценивания информационной безопасности Д.......................................................12

6.6    RAMP — фаза поддержания классификации Д..............................13

6.7    ERM — поддержание классификации при оценивании (в общем Д).................13

6.8    ТТАР — программа оценки доверенных технологий Д..........................14

6.9    ТРЕР — программа оценивания доверенного продукта Д........................15

6.10    Рациональный универсальный процесс® (RUP®)............................15

6.11 ИСО/МЭК 15288 — процессы жизненного цикла системы.......................16

6.12 ИСО/МЭК12207 — процессы жизненного цикла программного обеспечения...........17

6.13    V-модель......................................................18

6.14    ИСО/МЭК14598 — оценивание программного продукта........................19

6.15    Основные услуги по безопасности базовой структуры Х/Open Д...................20

6.16    SCT — строгое тестирование соответствия................................21

6.17    ИСО/МЭК 21827 — Проектирование безопасности систем — Модель зрелости процесса

(SSE-CMM®)...................................................22

6.18    ТСММ — доверенная модель зрелости процесса Д...........................23

6.19    CMMI — интеграция модели зрелости процесса®............................24

6.20    ИСО/МЭК 15504 — оценка программного процесса...........................25

6.21    СММ — модель СММ® (для программного обеспечения).......................25

6.22    SE-CMM® — модель зрелости процесса системного проектирования®..............26

6.23    TSDM — методология разработки доверенного программного обеспечения...........27

6.10.2    Описание

Рациональный универсальный процесс®, или RUP®, является схемой процесса разработки коммерческого серийного ПО, разработанного и поддерживаемого ПО Rational®. Схема постоянно обновляется и улучшается для отражения самого последнего опыта и развития лучших практик.

В отличие, например, от ИСО 12207 «пустая» схема RUP заполнена руководством, процессами, методами, средствами, шаблонами, инструментарием и примерами, из которых можно создать конкретную схему процесса, управлять ею и улучшать ее.

Подобно производимым им программным продуктам сам RUP спроектирован и документирован с помощью универсального языка моделирования (UML). Объектной моделью RUP является универсальная модель программного процесса (USPM).

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

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

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

В RUP объединены, в частности, шесть основных лучших практик:

-    интерактивная разработка ПО;

-    управление требованиями;

-    использование основанных на компонентах архитектур;

-    визуальное моделирование ПО;

-    верификация качества ПО;

-    контроль за внесением изменений в ПО.

С точки зрения управления процессом и его улучшения RUP согласовывается с СММ и требованиями ИСО/МЭК 15504 на проектном уровне. При правильной реализации RUP соответствует организационным уровням 2 и 3 СММ. Он пригоден для более высокой зрелости процесса вследствие хорошего определения программного процесса и знания руководством организации технического прогресса во всех проектах.

6.10.3    Источники

См. [52].

Примечание — RUP® является разработкой группы по ПО фирмы Rational, дочерней компании корпорации IBM, Route 100, Somers, NY 10589, USA.

6.11 ИСО/МЭК 15288 — процессы жизненного цикла системы

-►I-*-

->т->

->о->

6.11.1    Цель

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

6.11.2    Описание

ИСО/МЭК 15288 является первым стандартом ИСО, связанным с процессами жизненного цикла в основном сложных систем, состоящих из аппаратных средств, человеко-машинного интерфейса и ПО.

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

ГОСТ Р 54582-2011/ISO/IEC/TR 15443-2:2005

6.24    SdoC — декларация поставщика о соответствии.............................28

6.25    SA-CMM® — модель зрелости возможностей приобретения программного обеспечения® . . 28

6.26 Серия ИСО 9000 — менеджмент качества.................................29

6.27 ИСО 13407 — ориентированное на человека проектирование (HCD)................30

6.28    Характеристика разработчика (в общем)..................................31

6.29 ИСО/МЭК 17025 — доверие к аттестации.................................32

6.30    ИСО/МЭК 13335 — менеджмент безопасности информационных и телекоммуникационных

технологий....................................................33

6.31    BS 7799-2 — системы менеджмента информационной безопасности. Спецификация с руководством по применению &............................................34

6.32    ИСО/МЭК 17799 — практические правила менеджмента информационной безопасности & . . 34

6.33    FR — исправление дефектов (в общем)..................................35

6.34    Руководство по базовой защите информационных технологий %..................36

6.35    Испытание проникновением %........................................37

6.36    Аттестация персонала (в общем).......................................38

6.37    Аттестация персонала (в части безопасности) %.............................39

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов ссылочным национальным стандартам Российской Федерации................41

Библиография........................................................43

IV

ГОСТ Р 54582-2011/ISO/IEC/TR 15443-2:2005

Введение

В настоящем стандарте представлено описание методов обеспечения доверия и подходов, которые можно применить к безопасности информационных и коммуникационных технологий (ИКТ), предложенных или используемых различными типами организаций, независимо от того, утверждены ли они, одобрены неофициально или стандартизированы, а также их привязка к модели доверия по ГОСТ Р 54581-2011/ISO/IEC/TR 15443-1:2005. Акцент делается на идентификацию качественных характеристик методов, способствующих обеспечению доверия, и на их ранжирование. Настоящий стандарт предназначен для разъяснения специалистам в области безопасности ИКТ способов получения доверия на любом этапе жизненного цикла продукта или услуги.

В настоящем стандарте также приводятся цель и описание методов обеспечения доверия, а также указывается их место в структуре, определенной в ГОСТ Р 54581-2011/ISO/IEC/TR 15443-1:2005.

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

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

Настоящий стандарт предназначен для совместного использования с ГОСТ Р 54581-2011 /ISO/IEC/TR 15443-1:2005.

В настоящем стандарте также проведен анализ методов обеспечения доверия, не уникальных для безопасности ИКТ; однако руководство, приведенное в настоящем стандарте, ограничено требованиями безопасности ИКТ. В него включены также термины и понятия, получившие определение вдругихини-циативах международной стандартизации (например, CASCO) и международных справочниках (ИСО/МЭК Руководство 2); однако руководство, приведенное в настоящем стандарте, будет связано исключительно с областью безопасности ИКТ и не предназначено для общего менеджмента и оценки качества, а также согласованности ИКТ.

V

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационная технология

МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ

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

Часть 2 Методы доверия

Information technology. Security techniques. A framework for IT security assurance. Part 2. Assurance methods

Дата введения — 2012—12—01

1 Область применения

1.1    Назначение

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

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

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

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

1.2    Область применения

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

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

Предполагаемыми пользователями настоящего стандарта являются:

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

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

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

Издание официальное

4)    обслуживающее лицо (конкретное лицо или организация, осуществляющая деятельность по обслуживанию);

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

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

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

1.3 Ограничения

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

Требования к инфраструктуре поддержки верификации подхода к обеспечению доверия и требования к персоналу проведения верификации в настоящем стандарте не рассматриваются.

2 Нормативные ссылки

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

ИСО 9000 Системы менеджмента качества. Основные положения и словарь (ISO 9000, Quality management systems — Fundamentals and vocabulary)

ИСО 9001 Системы менеджмента качества. Требования (ISO 9001, Quality management systems — Requirements)

ИСО/МЭК 9126-1 ^ Программотехника. Качество продукта. Часть 1. Модель качества (ISO/IEC 9126-1, Software engineering — Product quality — Part 1: Quality model)

ИСО/МЭК 12207¹) Информационная технология. Процессы жизненного цикла программного обеспечения (ISO/IEC 12207, Information technology — Software life cycle processes)

ИСО/МЭК 13335-1³) Информационная технология. Методы и средства обеспечения безопасности. Менеджмент безопасности информационных и телекоммуникационныхтехнологий. Часть 1. Концепция и модели управления безопасностью информационных и коммуникационных технологий (ISO/IEC 13335-1, information technology — Security techniques — Management of information and communications technology security — Part 1: Concepts and models for information and communications technology security management)

ИСО/МЭК TO 13335-2⁴) Информационная технология. Руководство по менеджменту безопасности информационныхтехнологий. Часть 2. Планирование и менеджмент безопасности информационных технологий (ISO/IEC TR 13335-2, Information technology — Guidelines for the management of IT Security — Part 2: Managing and planning IT Security)

ИСО/МЭК TO 13335-3⁵) Информационная технология. Руководство по менеджменту безопасности информационныхтехнологий. Часть 3. Методы менеджмента безопасности информационныхтехнологий (ISO/IEC TR 13335-3, Information technology — Guidelines for the management of IT Security — Part3: Techniques for the management of IT Security)

Заменен на ИСО/МЭК 25010—2011 «Проектирование систем и разработка программного обеспечения. Требования к качеству систем и программного обеспечения и их оценка (SQuaRE). Модели качества систем и программного обеспечения (ISO/IEC 25010 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models)».

Заменен на ИСО/МЭК 12207 «Информационные технологии. Процессы жизненного цикла программного обеспечения» (ISO/IEC 12207, Systems and software engineering — Software life cycle processes).

Отменен.

^ Отменен.

Заменен на ИСО/МЭК 27005 «Информационная технология. Методы и средства обеспечения безопасности. Менеджмент риска информационной безопасности» (ISO/IEC 27005 Information technology — Security techniques — Information security risk management).

ГОСТ Р 54582-2011/ISO/IEC/TR 15443-2:2005

ИСО/МЭК ТО 13335-4¹) Информационная технология. Руководство по менеджменту безопасности информационных технологий. Часть 4. Выбор защитных мер (ISO/IEC TR 13335-4, Information technology — Guidelines for the management of IT Security — Part 4: Selection of safeguards)

ИСО/МЭК TO 13335-5²) Информационная технология. Руководство по менеджменту безопасности информационных технологий. Часть 5. Руководство по менеджменту безопасности сети (ISO/IEC TR 13335-5, Information technobgy — Guidelines for the management of IT Security — Part 5: Management guidance on network security)

ИСО/МЭК TO 14598-1 Информационная технология. Оценка программного продукта. Часть 1. Общий обзор (ISO/IEC 14598-1, Information technology — Software product evaluation — Part 1: General overview)

ИСО/МЭК 15939 Технология программного обеспечения. Процесс измерения (ISO/IEC 15939, Software engineering — Software measurement process)

ИСО/МЭК 15288 Системное проектирование. Процессы жизненного цикла систем (ISO/IEC 15288, Systems engineering — System life cycle processes)

ИСО/МЭК 15408-1 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 1. Введение и общая модель (ISO/EC15408-1, Information technology — Security techniques — Evaluation criteria for ITsecurity — Parti: Introduction and general model)

ИСО/МЭК 15408-2²) Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные требования безопасности (ISO/EC 15408-2, Information technology — Security techniques — Evaluation criteria for IT security — Part 2: Security functional requirements)

ИСО/МЭК 15408-3 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Требования доверия к безопасности (ISO/EC 15408-3, Information technology — Security techniques — Evaluation criteria for IT security — Part 3: Security assurance requirements)

ИСО/МЭК 15504-1 Информационная технология. Оценка процессов. Часть 1. Концепции и словарь (ISO/EC 15504-1, Information technology — Process assessment — Part 1: Concepts and vocabulary) ИСО/МЭК 15504-2 Информационная технология. Оценка процессов. Часть 2. Проведение оценки (ISO/EC 15504-2, Information technology — Process assessment — Part 2: Performing and assessment) ИСО/МЭК 15504-3 Информационная технология. Оценка процессов. Часть 3. Руководство по проведению оценки (ISO/EC 15504-3, Information technology — Process assessment — Part 3: Guidance on performing an assessment)

ИСО/МЭК 15504-4 Информационная технология. Оценка процессов. Часть 4. Руководство по использованию для усовершенствования и определения возможностей процесса (ISO/EC 15504-4, Information technology — Process assessment — Part 4: Guidance on use for process improvement and process capability determination)

ИСО/МЭК 15504-5 Информационная технология. Оценка процессов программного обеспечения. Часть 5. Пример модели оценки и руководство по указателям (ISO/IEC TR 15504-5, Information technology — Software Process Assessment — Part5: An assessment model and indicator guidance)

ИСО/МЭК 17799⁴) Информационная технология. Методы и средства обеспечения безопасности. Практические правила управления информационной безопасностью (ISO/EC 17799, Information technology — Security techniques — Code of practice for information security management)

ИСО/МЭК 21827 Информационная технология. Проектирование безопасности работы систем. Модель технологической зрелости (SSE-CMM®) (ISO/EC 21827, Information technology — Systems Security Engineering — Capability Maturity Model (SSE-CMM®))

ИСО/МЭК 90003 Техника программного обеспечения. Рекомендации по применению ИСО 9001:2000 к компьютерному программному обеспечению (ISO/EC 90003, Software engineering — Guidelines for the application of ISO 9001:2000 to computer software)

Заменен на ИСО/МЭК 27005 «Информационная технология. Методы и средства обеспечения безопасности. Менеджмент риска информационной безопасности» (ISO/IEC 27005 Information technology — Security techniques — Information security risk management).

^ Отменен.

³⁾ Заменен на ИСО/МЭК 15504-2 Информационная технология. Методы и средства обеспечения безопасности. Менеджмент риска информационной безопасности (ISO/IEC 27005 Information technology — Security techniques — Information security risk management).

⁴⁾ Заменен на ИСО/МЭК 27002 Информационные технологии. Свод правил по управлению защитой информации. ((ISO/IEC Information technology — Security techniques — Code of practice for information security management).

3    Термины, определения и сокращения

В настоящем стандарте применены термины, определения и сокращения по ИСО/МЭКТ0 15443-1.

4    Краткий обзор и представление методов обеспечения доверия

В ИСО/МЭКТО 15443-1 представлена схема распределения по категориям существующих методов обеспечения доверия, перечислены и представлены существующие методы обеспечения доверия, представляющие интерес и непосредственно связанные с областью безопасности ИКТ. В настоящем разделе эти методы классифицируются по следующей схеме:

-    в соответствии с различными фазами доверия — описание аспектов жизненного цикла: проектирование, реализация, интеграция, верификация, ввод в действие, перемещение или эксплуатация;

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

В ИСО/МЭК ТО 15443-1 указано, что метод обеспечения доверия может включать в себя комбинацию подхода кдоверию и фазы доверия.

В качестве дополнительного руководства для пользователя в таблице 2 подраздела 5.4 настоящего стандарта представлено распределение по категориям:

-    со значимостью отдельных методов для безопасности ИКТ;

-    с актуальностью отдельных методов.

5    Фаза жизненного цикла доверия и условные обозначения

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

Представляющие наибольший интерес фазы жизненного цикла представлены графически четырьмя столбцами таблицы. В соответствии с требованиями ИСО/МЭК 15288 и ИСО 9000 технологические процессы жизненного цикла сгруппированы в четыре стадии, по одной на каждый столбец, и сокращенно обозначены:

-    D (Design) — проектирование, включая процессы определения требований заинтересованных сторон, анализа требований, архитектурного проектирования и реализации;

-    I (Integration) — интеграция, включая процессы интеграции и верификации;

-    Т (Transition) — переход, включая процессы дублирования, перемещения, ввода в действие и приемочные испытания;

-    О (Operation) — эксплуатация, включая процессы эксплуатации, обслуживания и ликвидации.

Примечания

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

2    Процессы жизненного цикла D-I-T-0 применимы к любой конкретной системе ИКТ и ее компонентам, т. е. к аппаратным средствам и ПО. Разработка и улучшение процессов жизненного цикла являются вторым измерением, которое можно представить графически, но в настоящее время это измерение не представлено. В области безопасности ИКТ это измерение имеет особое значение из-за методов управления безопасностью, примененных к системам ИКТ на фазе функционирования в соответствии с ИСО/МЭК 17799 и BS 7799-2. По существу разработка и улучшение процессов жизненного цикла включает в себя оценку и документирование, разработку, измерение, улучшение и сертификацию процессов. Это второе измерение является прямоугольным (ортогональным) по отношению кизмерению D-I-T-0.

5.1 Подход к обеспечению доверия и условные обозначения

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

Категории методов обеспечения доверия наглядно представлены в таблице 1:

-    доверие к продукту: обозначено заглавной буквой названия фазы жизненного цикла между стрелками, например,

-    доверие к процессу: обозначено заглавной буквой названия фазы жизненного цикла на темном фоне, например, D;

-    доверие к среде: обозначено заглавной буквой названия фазы жизненного цикла с полосками слева и справа, например,|D |.

4

Таблица 1 — Структура методов обеспечения доверия — условные обозначения

Раздел Доверие — фаза-» — подход 1 Проект/ реализация Интеграция/ верификация Ввод в действие/ переход Эксплуатация Продукт [/Система/Услуга][ Д ] Процесс[Д ] -»D-> -и-> —»Т—» ^<Э-+ D 1 т О Среда III | [/Организация/ 1 D 1 1 1 Т 1 О Персонал][Д] | | | |

Примечания

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

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

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

5.2    Актуальность и условные обозначения

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

-    в настоящее время действующие и широко применяемые методы представлены в таблице 2 полужирным шрифтом;

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

Примечание — Эта легенда не повторяется в названии отдельного перечня данного подраздела.

5.3    Значимость безопасности и условные обозначения

Из-за очень большого числа методов пользователю настоящего стандарта дано указание в отношении безопасности их ИКТ. В таблице 2 это состояние отражено следующим образом:

-    ориентированные непосредственно на обеспечение безопасности ИКТ методы обозначены символом (Д) («замок»),

5.4    Обзор методов обеспечения доверия

В таблице 2 представлен обзор рассматриваемых методов обеспечения доверия наряду с их классификацией в соответствии со структурой, разработанной в ИСО/МЭКТ0 15443-1.

Таблица 2 — Структура методов обеспечения доверия. Краткий обзор

Раздел Доверие — фаза-» — ПОДХОД i Проект/ реализация Интеграция/ верификация Ввод в действие/ переход Функционирова ние 6.1 ИСО/МЭК 15408 — критерии оценки безопасности ИТ Д ->D-> -»т-+ -»о-» 6.2 TCSEC — критерии оценки доверенной компьютерной системы Д ->D-> -»о-» 6.3 ITSEC/ITSEM — критерии оценки безопасности ИТ и методология Д -»D-» -»о-» 6.4 СТСРЕС — Канадские критерии оценки доверенного продукта Д H»D-> 6.5 KISEC/KISEM — критерии оценки информационной безопасности и методология Кореи Д -»D-* -Н- -»о-»

5

1

2