Гост р исо мэк 15408 кратко
Обновлено: 04.07.2024
Функции системы информационной безопасности обеспечивают выполнение требований конфиденциальности, целостности, достоверности и доступности информации. Все функции представлены в виде четырехуровневой иерархической структуры: класс — семейство — компонент — элемент. По аналогии представлены требования качества. Подобная градация позволяет описать любую систему информационной безопасности и сопоставить созданную модель с текущим положением дел. В стандарте выделены 11 классов функций: аудит, идентификация и аутентификация, криптографическая защита, конфиденциальность, передача данных, защита пользовательских данных, управление безопасностью, защита функций безопасности системы, использование ресурсов, доступ к системе, надежность средств.
Оценка информационной безопасности базируется на моделях системы безопасности, состоящих из перечисленных в стандарте функций. В ISO 15408 содержится ряд предопределенных моделей (так называемых профилей), описывающих стандартные модули системы безопасности. С их помощью можно не создавать модели распространенных средств защиты самостоятельно, изобретая велосипед, а пользоваться уже готовыми наборами описаний, целей, функций и требований к этим средствам. Простым примером профилей может служить модель межсетевого экрана или СУБД.
Сертифицированный профиль представляет собой полное описание определенной части (или функции) системы безопасности. В нем содержится анализ внутренней и внешней среды объекта, требования к его функциональности и надежности, логическое обоснование его использования, возможности и ограничения развития объекта.
Стандарт ISO 15408 выгодно отличает открытость. Описывающий ту или иную область системы безопасности профиль можно создать самостоятельно с помощью разработанной в ISO 15408 структуры документа. В стандарте определена также последовательность действий для самостоятельного создания профилей.
Процедуры и требования к сертификации
Кроме того, в документе изложены требования к различным межсетевым экранам и дано подробное описание показателей защищенности для каждого класса.
Профили средств безопасности могут использоваться не только в системе государственной сертификации, но и в деятельности коммерческих организаций. Так, например, для организации с территориально-распределенной инфраструктурой целесообразно установить единые правила по обеспечению защиты данных. В этом случае может быть разработан профиль, описывающий правила доступа и информационного обмена с удаленными объектами.
Павел Рудаков — консультант по аналитике и маркетингу компании NV Consulting. С ним можно связаться по электронной почте
Почувствуйте разницу
Особенности ISO 15408 по сравнению с другими стандартами в области безопасности
Стандарт позволяет определить полный перечень требований к средствам безопасности, а также критерии их оценки (показатели защищенности информации)
Стандарт определяет полный перечень объектов анализа и требований к ним, не заостряя внимания на методах создания, управления и оценки системы безопасности
Стандарт позволяет оценить полноту системы информационной безопасности с технической точки зрения, не рассматривая при этом комплекс организационных мер по обеспечению защиты информации
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ. КРИТЕРИИ ОЦЕНКИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ
Введение и общая модель
Information technology. Security techniques. Evaluation criteria for IT security. Part 1. Introduction and general model
Дата введения 2013-12-01
1 ПОДГОТОВЛЕН Обществом с ограниченной ответственностью "Центр безопасности информации" (ООО "ЦБИ"), Федеральным автономным учреждением "Государственный научно-исследовательский испытательный институт проблем технической защиты информации Федеральной службы по техническому и экспортному контролю" (ФАУ "ГНИИИ ПТЗИ ФСТЭК России"), Федеральным государственным унитарным предприятием "Ситуационно-кризисный Центр Федерального агентства по атомной энергии" (ФГУП "СКЦ Росатома")
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 362 "Защита информации"
* Доступ к международным и зарубежным документам, упомянутым в тексте, можно получить, обратившись в Службу поддержки пользователей. - Примечание изготовителя базы данных.
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА
Введение
Настоящая часть ИСО/МЭК 15408 обеспечивает сопоставимость результатов независимых оценок безопасности. В ИСО/МЭК 15408 это достигается предоставлением единого набора требований к функциональным возможностям безопасности продуктов ИТ и к мерам доверия, применяемым к этим продуктам ИТ при оценке безопасности. Данные продукты ИТ могут быть реализованы в виде аппаратного, программно-аппаратного или программного обеспечения.
В процессе оценки достигается определенный уровень уверенности в том, что функциональные возможности безопасности таких продуктов ИТ, а также меры доверия, предпринятые по отношению к таким продуктам ИТ, отвечают предъявляемым требованиям. Результаты оценки могут помочь потребителям решить, отвечают ли продукты ИТ их потребностям в безопасности.
ИСО/МЭК 15408 (здесь и далее, если не указывается конкретная часть стандарта, то ссылка относится ко всем частям стандарта) полезен в качестве руководства при разработке, оценке и/или приобретении продуктов ИТ с функциональными возможностями безопасности.
В ИСО/МЭК 15408 предусмотрена гибкость, допускающая применение множества методов оценки по отношению к множеству свойств безопасности множества продуктов ИТ. Поэтому пользователи настоящего стандарта должны исключить возможность неправильного использования указанной гибкости стандарта. Например, использование ИСО/МЭК 15408 в сочетании с неподходящими методами оценки, неприменимыми свойствами безопасности или ненадлежащими продуктами ИТ может привести к незначимым результатам оценки.
Следовательно, тот факт, что продукт ИТ был оценен, имеет значимость только в контексте свойств безопасности, которые были оценены, и методов оценки, которые использовались. Органам оценки рекомендуется тщательно проверить продукты, свойства и методы, чтобы сделать заключение, что оценка обеспечивает значимые результаты. Кроме того, покупателям оцененных продуктов рекомендуется тщательно рассмотреть этот контекст, чтобы сделать заключение, является ли оцененный продукт соответствующим и применимым для их конкретной ситуации и потребностей.
ИСО/МЭК 15408 направлен на защиту информации от несанкционированного раскрытия, модификации или потери возможности ее использования. Категории защиты, относящиеся к этим трем типам нарушения безопасности, обычно называют конфиденциальностью, целостностью и доступностью соответственно. ИСО/МЭК 15408 может быть также применим к тем аспектам безопасности ИТ, которые выходят за пределы этих трех понятий. ИСО/МЭК 15408 применим к рискам, возникающим в результате действий человека (злоумышленных или иных), и к рискам, возникающим не в результате действий человека. Кроме области безопасности ИТ, ИСО/МЭК 15408 может быть применим и в других областях ИТ, но в нем не утверждается о применимости в этих областях.
Некоторые вопросы рассматриваются как лежащие вне области действия ИСО/МЭК 15408, поскольку они требуют привлечения специальных методов или являются смежными по отношению к безопасности ИТ. Часть из них перечислена ниже:
a) ИСО/МЭК 15408 не содержит критериев оценки безопасности, касающихся административных мер безопасности, непосредственно не относящихся к функциональным возможностям безопасности ИТ. Известно, однако, что безопасность в значительной степени может быть достигнута или поддерживаться административными мерами, такими как организационные меры, меры управления персоналом, меры управления физической защитой и процедурные меры.
b) Оценка некоторых специальных физических аспектов безопасности ИТ, таких как контроль электромагнитного излучения, прямо не затрагивается, хотя многие концепции ИСО/МЭК 15408 применимы и в этой области.
c) В ИСО/МЭК 15408 не рассматривается методология оценки, в рамках которой могут применяться конкретные критерии. Данная методология приведена в ИСО/МЭК 18045.
d) В ИСО/МЭК 15408 не рассматривается административно-правовая структура, в рамках которой критерии могут применяться органами оценки. Тем не менее, ожидается, что ИСО/МЭК 15408 будет использоваться для целей оценки в контексте такой структуры.
e) Процедуры использования результатов оценки при аттестации находятся вне области действия ИСО/МЭК 15408. Аттестация является административным процессом, посредством которого предоставляются полномочия на использование продукта ИТ (или их совокупности) в конкретной среде функционирования, включая все его части, не связанные с ИТ. Результаты процесса оценки являются исходными данными для процесса аттестации. Однако, поскольку для оценки не связанных с ИТ свойств, а также их соотнесения с аспектами безопасности ИТ более приемлемы другие способы, аттестующим следует предусмотреть для этих аспектов особый подход.
f) Критерии для оценки специфических качеств криптографических алгоритмов не входят в ИСО/МЭК 15408. Если требуется независимая оценка математических свойств криптографии, то в системе оценки, в рамках которой применяют ИСО/МЭК 15408, должен быть предусмотрен порядок проведения таких оценок.
Терминология ИСО, такая как "может" (can), "справочный" (informative), "должен" (shall) и "следует" (should), используемая в настоящем стандарте, определена в Директивах ИСО/МЭК, часть 2. У термина "следует" (should) имеется дополнительное значение, применимое при использовании настоящего стандарта. См. примечание ниже. Для использования в ИСО/МЭК 15408 дано следующее определение термина "следует" (should).
"следует" (should): В пределах нормативного текста "следует" (should) указывает, что "среди нескольких возможностей одна рекомендована в качестве наиболее подходящей, без упоминания или исключения других, или что определенный способ действия является предпочтительным, но не обязательно требуемым" (Директивы ИСО/МЭК, часть 2).
Примечание - ИСО/МЭК 15408 интерпретирует "не обязательно требуемый" для отражения того, что выбор другой возможности требует логического обоснования, почему не была выбрана предпочтительная возможность.
1 Область применения
Настоящий стандарт устанавливает основные понятия и принципы оценки безопасности ИТ, а также определяет общую модель оценки, которой посвящены различные части стандарта, предназначенного в целом для использования в качестве основы при оценке характеристик безопасности продуктов ИТ.
В данном стандарте представлен краткий обзор и описание всех частей ИСО/МЭК 15408; определены термины и сокращения, используемые во всех частях ИСО/МЭК 15408; установлено основное понятие объекта оценки (ОО), контекста оценки, описана целевая аудитория, которой адресованы критерии оценки. Представлены основные положения, необходимые для оценки продуктов ИТ.
В данном стандарте определяются ключевые понятия профилей защиты (ПЗ), пакетов требований безопасности, а также рассматриваются вопросы, связанные с утверждениями о соответствии; описываются выводы и результаты оценки. В данном стандарте даны инструкции по спецификации заданий по безопасности (ЗБ) и описание структуры компонентов в рамках всей модели. Также дана общая информация о методологии оценки, приведенной в ИСО/МЭК 18045, и области действия системы оценки.
2 Нормативные ссылки
Следующие нормативные документы* необходимы для применения настоящего стандарта. Для датированных ссылок применяется только то издание, на которое дается ссылка. Для недатированных ссылок применяется самое последнее издание нормативного ссылочного документа (включая любые изменения).
* Таблицу соответствия национальных стандартов международным см. по ссылке. - Примечание изготовителя базы данных.
ИСО/МЭК 18045 Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий
3 Термины и определения
Применительно к настоящему документу используются следующие термины и определения.
Примечание - Данный раздел содержит только те термины, которые используются во всем тексте ИСО/МЭК 15408. Некоторые комбинации общих терминов, используемые в ИСО/МЭК 15408 и не вошедшие в данный раздел, поясняются непосредственно в тексте по месту использования.
3.1 Термины и определения, общие для всех частей ИСО/МЭК 15408
3.1.1 негативные действия (adverse actions): Действия, выполняемые источником угрозы по отношению к активам.
3.1.2 активы (assets): Сущности, предположительно представляющие ценность для владельца ОО.
3.1.3 назначение (assignment): Спецификация определенного параметра в компоненте или требовании.
3.1.4 доверие (assurance): Основание для уверенности в том, что ОО отвечает конкретным ФТБ.
3.1.5 потенциал нападения (attack potential): Мера усилий, затрачиваемых при атаке на ОО, выраженная в показателях компетентности, ресурсов и мотивации нарушителя.
3.1.6 усиление (augmentation): Добавление одного или нескольких требований к пакету.
3.1.7 аутентификационные данные (authentication data): Информация, используемая для верификации предъявленного идентификатора пользователя.
3.1.8 уполномоченный пользователь (authorised user): Пользователь ОО, которому в соответствии с ФТБ разрешено выполнять некоторую операцию.
3.1.9 класс (class): Совокупность семейств, объединенных общим назначением.
3.1.10 четкий (coherent): Логически упорядоченный и имеющий понятное значение.
Примечание - В случае с документацией это относится как к имеющемуся тексту, так и к структуре документа в том смысле, понятен ли он его целевой аудитории.
3.1.11 полный (complete): Свойство, обеспеченное наличием всех необходимых частей некоторой сущности.
Примечание - По отношению к документации это означает, что вся необходимая информация отражена в документации на уровне детализации, не требующем на данном уровне абстракции дальнейших пояснений.
3.1.12 компонент (component): Наименьшая выбираемая совокупность элементов, на которой могут основываться требования.
3.1.13 составной пакет доверия (composed assurance package): Пакет доверия, представляющий некоторое положение на предопределенной составной шкале доверия.
3.1.14 подтвердить (confirm): Декларировать, что что-то детально проверено с независимым определением достаточности.
Примечание - Требуемый уровень строгости зависит от типа рассматриваемого предмета. Данный термин применим только к действиям оценщика.
3.1.15 внешняя связность (connectivity): Свойство ОО, позволяющее ему взаимодействовать с сущностями ИТ, внешними по отношению к ОО.
Примечание - Это взаимодействие включает обмен данными по проводным или беспроводным средствам на любом расстоянии, в любой среде или при любой конфигурации.
3.1.16 непротиворечивый (consistent): Характеризует связь между двумя или более сущностями, указывая, что между этими сущностями нет никаких явных противоречий.
3.1.17 противостоять (counter): Характеризует противостояние некоторому нападению, при котором негативные последствия реализации некоторой конкретной угрозы уменьшаются, но не обязательно полностью ликвидируются.
3.1.18 демонстрируемое соответствие (demonstrable conformance): Связь между ЗБ и ПЗ, при которой ЗБ обеспечивает решение общей проблемы безопасности, определенной в ПЗ.
Примечание - ПЗ и ЗБ могут содержать совершенно разные утверждения, относящиеся к разным сущностям, использующие разные понятия и т.д. Демонстрируемое соответствие также является подходящим для типа ОО, для которого уже существует несколько сходных ПЗ, позволяя разработчику ЗБ утверждать о соответствии одновременно всем этим ПЗ и, таким образом, экономить трудозатраты.
3.1.19 демонстрировать (demonstrate): Предоставить заключение, полученное в процессе анализа, который является менее строгим, чем "доказательство" ("proof").
3.1.20 зависимость (dependency): Соотношение между компонентами, при котором, если некоторое требование, основанное на зависимом компоненте, включается в ПЗ, ЗБ или пакет, то и требование, основанное на компоненте, от которого зависит указанный выше компонент, должно быть, как правило, включено в ПЗ, ЗБ или пакет.
3.1.21 описывать (describe): Представить конкретные подробности о некоторой сущности.
3.1.22 делать заключение (determine): Подтвердить некоторое заключение, основанное на независимом анализе для достижения этого заключения.
Примечание - Использование данного термина подразумевает выполнение действительно независимого анализа, обычно в условиях отсутствия какого бы то ни было предшествующего анализа. Термин "делать заключение" отличается от терминов "подтверждать" ("confirm") или "верифицировать" ("verify"), которые предполагают необходимость проверки ранее выполненного анализа.
3.1.23 среда разработки (development environment): Среда, в которой осуществляется разработка ОО.
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ. КРИТЕРИИ ОЦЕНКИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ
Функциональные компоненты безопасности
Information technology. Security techniques. Evaluation criteria for IT security. Part 2. Security functional components
Дата введения 2014-09-01
1 ПОДГОТОВЛЕН Обществом с ограниченной ответственностью "Центр безопасности информации" (ООО "ЦБИ"), Федеральным автономным учреждением "Государственный научно-исследовательский испытательный институт проблем технической защиты информации Федеральной службы по техническому и экспортному контролю" (ФАУ "ГНИИИ ПТЗИ ФСТЭК России")
2 ВНЕСЕН Техническим комитетом по стандартизации "Защита информации" ТК 362
* Доступ к международным и зарубежным документам, упомянутым в тексте, можно получить, обратившись в Службу поддержки пользователей. - Примечание изготовителя базы данных.
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА
Введение
Международный стандарт ISO/IEC 15408:2008 был подготовлен Совместным техническим комитетом ISO/IEC JTC 1 "Информационные технологии", Подкомитетом SC 27 "Методы и средства обеспечения безопасности ИТ". Идентичный ISO/IEC 15408 текст опубликован организациями-спонсорами проекта "Общие критерии" как "Общие критерии оценки безопасности информационных технологий".
Третья редакция стандарта отменяет и заменяет вторую редакцию (ISO/IEC 15408:2005), которая подверглась технической переработке.
ИСО/МЭК 15408, идентичный ISO/IEC 15408:2008, состоит из следующих частей под общим заголовком "Информационная технология - Методы и средства обеспечения безопасности - Критерии оценки безопасности информационных технологий":
- Часть 1: Введение и общая модель;
- Часть 2: Функциональные компоненты безопасности;
- Часть 3: Компоненты доверия к безопасности.
Функциональные компоненты безопасности, которые определены в данной части ИСО/МЭК 15408, являются основой для функциональных требований безопасности, отражаемых в профиле защиты (ПЗ) или задании по безопасности (ЗБ). Эти требования описывают необходимый режим функционирования объекта оценки (ОО) и направлены на достижение целей безопасности, определяемых в ПЗ или ЗБ. Эти требования описывают свойства безопасности, которые могут выявить пользователи путем непосредственного взаимодействия с ИТ (т.е. при вводе, выводе информации) или по отклику ИТ на некоторое воздействие.
Функциональные компоненты безопасности отражают требования безопасности, направленные на противодействие угрозам в предполагаемой среде функционирования ОО и выполнение принятых в организации политик и предположений безопасности.
b) разработчики, которые при производстве ОО учитывают существующие предполагаемые требования безопасности потребителей, могут найти в данной части ИСО/МЭК 15408 стандартизованный метод понимания этих требований. Также они могут использовать данную часть ИСО/МЭК 15408 как основу для дальнейшего определения функциональных возможностей и механизмов безопасности ОО, соответствующих этим требованиям;
c) оценщики могут использовать функциональные требования, определенные в данной части ИСО/МЭК 15408 для подтверждения того, что функциональные требования к ОО, отраженные в ПЗ и ЗБ, удовлетворяют целям безопасности ИТ, а все зависимости учтены и продемонстрировано их удовлетворение. Также оценщикам следует использовать данную часть ИСО/МЭК 15408 при вынесении заключения о том, удовлетворяет ли данный ОО предъявляемым к нему требованиям.
1 Область применения
Настоящий стандарт устанавливает структуру и содержание компонентов функциональных требований безопасности для оценки безопасности. Он также включает в себя каталог функциональных компонентов, отвечающих общим требованиям к функциональным возможностям безопасности многих продуктов ИТ.
2 Нормативные ссылки
Указанные в данном разделе документы являются необходимыми для применения настоящего стандарта*. Для датированных ссылок используют только указанное издание. Для недатированных ссылок - последнее издание со всеми изменениями и дополнениями.
* Таблицу соответствия национальных стандартов международным см. по ссылке. - Примечание изготовителя базы данных.
3 Термины и определения, обозначения и сокращения
4 Краткий обзор
ИСО/МЭК 15408 и соответствующие функциональные требования безопасности, описанные ниже, не предназначены для окончательного решения всех задач безопасности ИТ. Скорее, настоящий стандарт предлагает совокупность хорошо продуманных функциональных требований безопасности, которые могут применяться при создании доверенных продуктов ИТ, отвечающих потребностям рынка. Эти функциональные требования безопасности представляют современный уровень спецификации требований и оценки.
В настоящий стандарт не предполагалось включать все возможные функциональные требования безопасности, а только те из них, которые на дату издания стандарта были известны и одобрены его разработчиками.
4.1 Структура данной части ИСО/МЭК 15408
В разделе 5 описывается парадигма, используемая в функциональных компонентах безопасности данной части ИСО/МЭК 15408.
Раздел 6 представляет каталог функциональных компонентов.
В разделах 7-17 приведено описание функциональных классов.
Приложение А содержит пояснительную информацию для потенциальных пользователей функциональных компонентов, включая таблицы перекрестных ссылок зависимостей функциональных компонентов.
Приложения В - М представляют пояснительную информацию для функциональных классов. Этот материал должен рассматриваться в качестве нормативных инструкций по применению соответствующих операций и выбору необходимой информации для аудита и документирования; использование вспомогательного глагола "следует" означает, что конкретная инструкция является предпочтительной, но и другие могут быть обоснованы. Когда даются различные варианты, выбор остается за автором ПЗ/ЗБ.
5 Парадигма функциональных требований
* В бумажном оригинале обозначения и номера стандартов и нормативных документов приводятся обычным шрифтом, кроме отмеченных в разделе "Предисловие" знаком "**". - Примечание изготовителя базы данных.
Настоящий стандарт содержит каталог функциональных компонентов безопасности, которые могут быть предъявлены к объекту оценки (ОО). ОО - это набор программных, аппаратно-программных и/или аппаратных средств, сопровождаемый руководствами пользователя и администратора. ОО может включать ресурсы в виде электронных носителей данных (таких, как основная память, дисковое пространство), периферийных устройств (таких, как принтеры) и вычислительных возможностей (таких, как процессорное время), которые могут использоваться для обработки и хранения информации и являются предметом оценки.
Оценка прежде всего подтверждает, что в отношении ресурсов ОО применяется определенный набор функциональных требований безопасности (ФТБ). ФТБ определяют правила, по которым ОО управляет использованием и доступом к своим ресурсам и, таким образом, к информации и сервисам, контролируемым ОО.
ФТБ могут определять различные политики функций безопасности (ПФБ). Каждая такая ПФБ должна специфицировать свою область действия, определяющую субъекты, объекты, ресурсы или информацию и операции, по отношению к которым она применяется. Все ПФБ реализуются ФБО (см. ниже), чьи механизмы осуществляют правила, определенные в ФТБ, и предоставляют необходимые возможности.
В совокупности те части ОО, которые направлены на корректную реализацию ФТБ, определяются как функции безопасности объекта оценки (ФБО). ФБО объединяют функциональные возможности всех аппаратных, программных и программно-аппаратных средств ОО, на которые как непосредственно, так и косвенно возложено обеспечение безопасности.
ОО может быть единым продуктом, включающим аппаратные, программно-аппаратные и программные средства.
В ином случае ОО может быть распределенным, состоящим из нескольких разделенных частей. Каждая часть ОО обеспечивает выполнение конкретного сервиса для ОО и взаимодействуют с другими частями ОО через внутренний канал связи. Этот канал может быть всего лишь шиной процессора, а может являться внутренней сетью для ОО.
Если ОО состоит из нескольких частей, то каждая часть может иметь собственное подмножество ФБО, которое обменивается данными ФБО и пользователей через внутренние каналы связи с другими подмножествами ФБО. Это взаимодействие называется внутренней передачей ОО. В этом случае части ФБО формируют объединенные ФБО, которые реализуют ФТБ для этого ОО.
Интерфейсы ОО могут быть локализованы в конкретном ОО или же могут допускать взаимодействие с другими продуктами ИТ по внешним каналам связи. Внешние взаимодействия с другими продуктами ИТ могут принимать две формы:
a) ФТБ другого "доверенного продукта ИТ" и ФТБ рассматриваемого ОО скоординированы и оценены в административном порядке, и предполагается, что рассматриваемый другой "доверенный продукт ИТ" реализует свои ФТБ корректно (например, был отдельно оценен). Обмен информацией в этом случае назван передачей между ФБО, поскольку он осуществляется между ФБО различных доверенных продуктов;
b) другой продукт ИТ может быть недоверенным, он может быть обозначен как "недоверенный продукт ИТ". Поэтому его ФТБ либо неизвестны, либо их реализация не рассматривается как в достаточной степени доверенная. Опосредованный ФБО обмен информацией в этом случае назван передачей за пределы ОО, так как рассматриваемый другой продукт ИТ не имеет ФБО (или характеристики его политики безопасности неизвестны).
Совокупность интерфейсов как интерактивных (человеко-машинный интерфейс), так и программных (интерфейс программных приложений), через которые могут быть получены доступ к ресурсам при посредничестве ФБО или информация от ФБО, называется интерфейсом ФБО (ИФБО). ИФБО определяет границы функциональных возможностей ОО, которые предоставлены для реализации ФТБ.
Пользователи не включаются в состав ОО. Однако пользователи взаимодействуют с ОО, который является предметом применения правил, определенных в ФТБ, через ИФБО при запросе услуг, которые будут выполняться ОО. Существуют два типа пользователей, учитываемых в настоящем стандарте: человек-пользователь и внешняя сущность ИТ. Человека-пользователя можно далее дифференцировать как локального человека-пользователя, взаимодействующего непосредственно с ОО через устройства ОО (такие, как рабочие станции), и как удаленного человека-пользователя, взаимодействующего с ОО через другой продукт ИТ.
Период взаимодействия пользователя и ФБО называется сеансом пользователя. Открытие сеансов пользователей может контролироваться на основе ряда условий, таких как аутентификация пользователя, время суток, метод доступа к ОО, число разрешенных параллельных сеансов (для каждого пользователя или в целом).
В настоящем стандарте используется термин уполномоченный для обозначения пользователя, который обладает правами и/или привилегиями, необходимыми для выполнения операций. Поэтому термин уполномоченный пользователь указывает, что пользователю разрешается выполнять конкретную операцию или совокупность операций в соответствии с ФТБ.
Для выражения требований разделения административных обязанностей соответствующие функциональные компоненты безопасности (из семейства FMT_SMR) явно устанавливают обязательность административных ролей. Роль - это заранее определенная совокупность правил, устанавливающих допустимые взаимодействия пользователя, действующего в данной роли, и ОО. ОО может поддерживать определение произвольного числа ролей. Например, роли, связанные с операциями безопасности ОО, могут включать в себя роли "Администратор аудита" и "Администратор учета пользователей".
ОО содержит ресурсы, которые могут использоваться для обработки и хранения информации. Основной целью ФБО является полная и правильная реалиация ФТБ для ресурсов и информации, которыми управляет ОО.
Ресурсы ОО могут иметь различную структуру и использоваться различными способами. Тем не менее в настоящем стандарте проводится специальное разграничение, позволяющее специфицировать желательные свойства безопасности. Все сущности, которые могут быть созданы на основе ресурсов, характеризуются одним из двух способов. Сущности могут быть активными, т.е. являться причиной действий, которые происходят в пределах ОО, и инициировать операции, выполняемые с информацией. Напротив, сущности могут быть пассивными, т.е. являться контейнером - источником информации или контейнером - местом хранения информации.
Подробнее под катом…
Оглавление
Введение и цели цикла
История и эволюция фреймворка
Центральный банк как популяризатор ОУД4
Общие положения и концепции ОУД4
Полезные ссылки и материалы
Приложение (список сокращений)
Введение и цели цикла
На данный момент планируется как минимум три статьи, посвященные отдельным аспектам фреймворка. Первая – вводная, знакомящая читателей с историей вопроса, ключевыми терминами и концепции. Здесь описывается их взаимосвязь, дается общее представление о проблеме. Вторая статья будет описывать роль разработчика ПО, его обязанности и решаемые в рамках безопасной разработки задачи. Третья – раскрывать фреймворк, но уже с позиции оценщика, который осуществляет сертификацию, анализ уязвимостей или оценку соответствия.
Сложность темы, колоссальный объем материалов и многочисленные нюансы практической реализации фреймворка ставят перед нами необходимость выбирать, что именно войдет в цикл статей, а что останется за его скобками для самостоятельного освоения читателями. Скажу банальность, но каждый продукт существует в собственном уникальном контексте, использует свои инструменты для разработки и деплоя, несет под капотом уникальный набор рисков и задач безопасности. Поэтому, чтобы не скатиться в жанр псевдопопуляризации, абстрактной и поверхностной настолько, что в итоге она оказывается напрочь оторванной от реальности, а потому бесполезной, мы просим читателей не стесняться и давать активную обратную связь. Мы будем признательны за конкретные вопросы и аргументированные пожелания, уточнения и замечания; за обмен практическим опытом по результатам вашей работы с фреймворком, чтобы опираясь на большое количество различных примеров сделать его проще для понимания.
В будущем, по мотивам написанных материалов и обратной связи, мы допускаем создание методических материалов в формате гайдов или FAQ более академичного формата, которые послужат введением в тему и руководством к действию для следующих поколений внедренцев ОУД, позволяя специалистам уделить больше времени своим непосредственным задачам вместо самостоятельной дешифровки языка стандартов, анализа требований регуляторов и комментариев к ним.
История и эволюция фреймворка
ОУД расшифровывается как оценочный уровень доверия. Из самого названия следует цель фреймворка – гарантировать соответствие продукта определенным критериям, заявленным в соответствующих стандартах, чтобы пользователи (заказчики, владельцы, физические лица и т.д.) могли доверять программному или аппаратному обеспечению, прошедшему необходимые проверки и декларирующему через них соответствие необходимым требованиям. Чтобы не уходить в длинную лекцию о разработке, уязвимостях, их эксплуатации и сопутствующих рисках, напомним, что любая ИТ-система теоретически (а на деле чаще всего и практически – были бы ресурсы!) – несовершенна. Поэтому в силу различных недостатков, связанных с:
разработкой (кодированием архитектуры в конечный продукт);
ИТ-система почти всегда оказывается в группе риска. Яркие подтверждения тому можно найти в многочисленных блогах, аналитических отчетах и твитах специалистов, занимающихся вопросами безопасности. Наверняка и вы сами наблюдали или сталкивались с инцидентами безопасности и утечками информации на личном опыте. Цели атак, источники угроз, последствия их реализации и методы управления рисками могут различаться у разных организаций. Чтобы дать специалистам общий язык и методологию необходима стандартизация проблемного поля. Для этих целей и был создан наш фреймворк.
Рисунок 1. Иллюстрация вектора атаки
Центральный банк как популяризатор ОУД4
Примерно в то время, когда Стандартинформ публикует первые документы семейства ГОСТ 15408, Банк России, в соответствии с международными трендами, начинает ужесточать требования к информационной безопасности платежей и кредитных организаций. Его целью является обеспечение устойчивости и надежности платежной и банковской системы, в том числе борьба с мошенничеством и несанкционированными переводами. Летом 2012 года принимается знаменитое положение 382-П, которое на следующие 8 лет становится основным нормативом по информационной безопасности для организаций, занимающихся денежными переводами на территории РФ (не считая более нишевых и специфичных требований, вроде стандарта PCI DSS, которые существовали и до этого).
С положения 382-П начинается внедрение ОУД 4 в жизнь финансовых организаций. В мае 2018 года Банк России, сталкиваясь с фактами печальной статистики уязвимостей ДБО и иных публично доступных интерфейсов взаимодействия с клиентами, вносит изменения в упомянутое Положение. Среди них содержится п. 2.5.5.1, цитата:
В последующие годы это требование, в уточненном и видоизмененном виде, появлялось в других нормативах ЦБ, и по состоянию на 2021 год прямо или косвенно вытекает из:
672-П (через ссылку на ГОСТ Р 57580.1-2017, где в требованиях ЖЦ.8 и ЖЦ.20 косвенно формулируется ежегодный ОУД4);
ПО распространяется клиентам организации (физическим или юридическим лицам);
ПО доступно через интернет неограниченному кругу лиц (а не закрыто VPN или иными ограничителями).
Рисунок 3. Границы применимости ОУД для приложений финансовых организаций
Таким образом, спор о границах применимости ОУД был разрешен, а широкая формулировка границ применимости, проистекающая из 382-П уйдет в небытие вместе с указанным положением (оно утрачивает силу 01 января 2022 года на основании положения Банка России 719-П). Остается единственный вопрос – как быть, если несколько приложений подпадают под требования? Наш ответ неоригинален – риск-ориентированный подход и приоритизация проектов по ОУД внутри организации, особенно в условиях жестко лимитированного бюджета. Такую приоритизацию можно выстраивать на основании масштаба финансовых переводов, с учетом количества обрабатываемых персональных данных или исходить из других, менее очевидных соображений, например возможностей команды разработки оказывать поддержку проекту. В любом случае у вас наверняка есть более критичные каналы взаимодействия с клиентами и есть менее критичные. Если бюджет проекта ограничен, а количество различных приложений подпадающих под ОУД велико, самый простой критерий принятия решения - финансовый.
Теперь, когда мы изучили контекст вопроса, определились с границами применимости требований, решили в какой последовательности мы будем прогонять наши продукты через горнило ОУД, давайте поговорим о ключевых особенностях фреймворка и сделаем его обзор.
Общие положения и концепции ОУД4
В общих чертах фреймворк ОУД можно рассматривать как разновидность SDLC, в рамках которого у нас возникает стандартный набор этапов жизненного цикла продукта, типичный для подобных фреймворков. Их сопровождают популярные концепции, такие как: среда функционирования, функция безопасности, управление конфигурациями и другие.
Ключевыми документами, для понимания фреймворка, являются упомянутые в ссылках ГОСТы, которые не только вводят терминологию, но и содержат многочисленные разъяснения и примеры его различных аспектов. Ниже перечень, на наш взгляд, наиболее интересных и полезных:
ГОСТ Р 58143-2018.
Общий процесс разработки и тестирования, согласно фреймворку, описывается в первой части ГОСТ 15408. В общем случае жизненный цикл продукта может быть представлен так, как показано на рисунке ниже.
Этапы работ, формирующих ОУД, описываются в третьей части стандарта ГОСТ 15408, как показано на следующем рисунке.
Рис 5. Компоненты, формирующие ОУД
Чтобы лучше понять, как устроен процесс безопасной разработки, согласно фреймворку, попробуем разобрать его в следующих разрезах:
Ключевых концепций и ролей;
Базовых процессов (взаимодействий) и их результатов.
На базовом уровне можно выделить три ключевые роли:
А. Заказчик (может совпадать с пользователем или владельцем), который использует некий продукт и требует соответствие этого продукта неким установленным требованиям к ИБ;
Б. Разработчик, который создает этот продукт и выстраивает его жизненный цикл, в соответствии с требованиями Заказчика;
В. Оценщик, который проверяет соответствие разработанного продукта установленным требованиям.
Таким образом, для гипотетической страховой или пенсионного фонда, с собственной разработкой личного кабинета пользователей силами штатных специалистов возможен сценарий консолидации всех ролей и компетенций внутри самой организации, а вот для банка или иной разновидности кредитной организации такой сценарий де-юре запрещен. Если возможности и законы позволяют, то наращивание внутренних компетенций может оказаться рентабельнее ежегодного приглашения внешних подрядчиков, стоимость услуг которых может превышать стоимость ПО, в отношении которого проводятся работы.
Какие же процессы и взаимодействия возникают в ходе работ в соответствии с фреймворком ОУД? Практически каждый процесс ИБ начинается с описания границ проекта и требований, безопасная разработка не исключение.
В общих чертах фреймворк декларирует следующую последовательность действий:
Разработать документацию и политики на продукт, которые регламентируют требования к ИБ приложения и разработки;
Обеспечить практическое применение документов в разработке конкретного продукта;
В ходе тестов, оценки соответствия и/или анализа уязвимостей подтвердить, что установленные на уровне документации и политик требования выполняются де-факто и позволяют достичь необходимого уровня безопасности (по сути защитить продукт от нарушителя ИБ с определенным потенциалом).
Ключевым элементом фреймворка является объект оценки (или ОО, например, ДБО, или какой-то компонент внутри ДБО), к которому предъявляются функциональные требования к безопасности (или ФТБ, например, необходимая реализация системы управления доступом или стойкая криптография), формулируемые в задании по безопасности или профиле защиты (разница между двумя в том, что задание по безопасности обычно создается Заказчиком самостоятельно, под себя; а профиль тиражируется различными институциями как минимально-адекватный стандарт для какого-то класса решений, например для межсетевых экранов или антивирусов). Так как объект оценки существует не в вакууме, а актуальные уязвимости связаны не только с разработкой и проектированием, но и с настройкой и эксплуатацией объекта, важными понятиями являются среда функционирования и конфигурация среды/объекта оценки. Наконец, сам оценочный уровень доверия представляет собой гамбургер из большего или меньшего набора компонент, в зависимости от выбранного уровня (смотри рисунок 5 выше).
В итоге Заказчик организует деятельность Разработчика таким образом, чтобы тот в результате создавал продукт, соответствующий заданным в документации требованиям. При поставке этот продукт должен безопасно и корректно разворачиваться в среде функционирования, с соблюдением всех установленных в документации требований к конфигурации и обслуживания. Оценщик же в свою очередь анализует адекватность созданного продукта установленным требованиям и декларирует свои выводы по результатам проведенного анализа.
Такое подтверждение может осуществляться с помощью двух базовых сценариев:
С помощью сертификации (делается специализированными лабораториями, включенными в систему ФСТЭК);
С помощью оценки соответствия или анализа уязвимостей (делается самостоятельно для себя, либо сторонней организацией с лицензией ФСТЭК на ТЗКИ).
Это разделение нашло свое отражение в упомянутых по тексту положениях Банка России. В порядке убывания сложности и цены указанные сценарии можно разместить следующим образом:
Разница между оценкой соответствия и анализом уязвимостей наглядно иллюстрируется рисунком 5. В первом случае необходима именно оценка соответствия, по множеству компонентов, формирующих указанный ОУД - по сути оценка всего SDLC. Во втором – проработка лишь одного компонента, который зависит от построения SDLC, но является лишь малой частью того, что составляет целый ОУД.
При всех нюансах и вариациях имплементации необходимый минимум документации на приложение включает в себя:
Описание архитектуры безопасности;
Руководство пользователя по эксплуатации;
Проект объекта оценки;
Задание по безопасности.
Для начала такого состава документов нам хватит. Что же касается качества реализации фреймворка и надежности заключений Оценщика, то независимо от выбранного сценария работ, это во многом зависит от соблюдения Заказчиком и Разработчиком установленных семейством 15408 пререквизитов. От выстроенного в организации SDLC и наличия проработанной документации на конкретный продукт. Здесь действует правило аналогичное любому типу анализа защищенности – чем более прозрачным для проверяющих будет ПО, чем полнее окажутся его описания, чем более компетентным и проактивным будет Заказчик, тем больше недостатков и уязвимостей смогут найти проверяющие и тем качественнее окажутся их заключения. Увы, в реальной жизни, в силу дороговизны работ и сложности процесса, указанные выше пререквизиты часто либо отсутствуют, либо находятся в зачаточном состоянии.
Заключение
Полезные ссылки и материалы по теме:
d. ГОСТ 18045-2013;
f. ГОСТ Р 58143-2018.
Лучшие практики безопасной разработки:
Приложение (список сокращений)
По тексту документа использованы следующие сокращения/условные обозначения:
АБС – автоматизированная банковская система;
ГОСТ Р – национальный государственный стандарт Российской Федерации;
ИБ – информационная безопасность;
ИТ – информационные технологии;
ОО – объект оценки;
ОУД – оценочный уровень доверия (см. ГОСТ/МЭК 15408);
ПО – программное обеспечение, приложение;
Фреймворк – здесь тоже самое, что стандарт, задающий структуру вокруг которой выстраивается какой-либо процесс или решение задачи;
SDLC - Software Development Lifecycle.
Соавтор: (Рустам Гусейнов, специалист по информационной безопасности).
Статус документа: действует , введён в действие 01.12.2013 Название на английском языке: Information technology. Security techniques. Evaluation criteria for IT security. Part 1. Introduction and general model Дата актуализации информации по стандарту: 30.11.-0001, в 00:00 (более года назад) Вид стандарта: временно не известен Дата начала действия ГОСТа: 2013-12-01
Документ разработан орг-ей: Федеральное агентство по техническому регулированию и метрологии Ключевые слова документа: доверие к безопасности, задание по безопасности, информационная технология, критерии оценки безопасности, объект оценки, профиль защиты, функциональные возможности безопасности
Читайте также: