Что такое задание по безопасности

Профиль защиты и задание по безопасности

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

Класс

Семейство-1

Семейство-2

Семейство-3

Рис.7.2. Пример структуры гарантийных требований.

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

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

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

ЗБ формируется разработчиком изделия и является основой для проведения оценки и сертификации изделия.

Структура профиля защиты строго регламентирована. Он содержит следующие разделы.

1.1. Идентификация ПЗ

1.2. Аннотация ПЗ

3. СРЕДА БЕЗОПАСНОСТИ ОО

3.1. Предположения безопасности

3.3. Политика безопасности организации

4. ЦЕЛИ БЕЗОПАСНОСТИ

4.1. Цели безопасности для ОО

4.2. Цели безопасности для среды

5. ТРЕБОВАНИЯ БЕЗОПАСНОСТИ ИТ

5.1. Функциональные требования безопасности ОО

5.2. Требования доверия к безопасности ОО

5.3. Требования безопасности для среды ИТ

6. ЗАМЕЧАНИЯ ПО ПРИМЕНЕНИЮ

7.1. Логическое обоснование целей безопасности

7.2. Логическое обоснование требований безопасности

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

Литература

1. Герасименко В. А., Малюк А. А. Основы защиты информации. М. Московский

государственный инженерно- физический институт,1997г.

2. Романец Ю.В., Тимофеев П.А., Шаньгин В.Ф. Защита информации в компьютерных

системах и сетях / Под ред. В.Ф. Шаньгина. – М.: Радио и связь, 1999.

3. Мельников В. В. Защита информации в компьютерных системах. М. «Финансы и

4. «Шпионские штучки» и устройства для защиты объектов и информации. Справочное

5. Хорев А.И. Защита информации. Технические каналы утечки информации. М., 1998г.

6. Ярочкин В.И. Информационная безопасность: Учеб. для ВУЗов. Изд. 2. Минск:

Академический проект, 2005.

7. Зима В.М., Молдавян А.А., Молдовян Н.А. Безопасность глобальных сетевых технологий.

8. Голиков В.Ф., Лыньков Л.М., Прудник А.М., Борботько Т.В. Правовые и организаци-

онно-технические методы защиты информации. Учебное пособие. Минск, БГУИР, 2004г.

9. СТБ 34.101.1-2004(ИСО/МЭК 15408-1:1999). Информационные технологии и

безопасность. Критерии оценки безопасности информационных технологий. Часть 1. Введение и общая модель.

10. СТБ 34.101.2-2004(ИСО/МЭК 15408-2:1999). Информационные технологии и безопасность. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные требования безопасности.

11. СТБ 34.101.3-2004(ИСО/МЭК 15408-3:1999). Информационные технологии и безопасность. Критерии оценки безопасности информационных технологий. Часть 3. Гарантийные требования безопасности.

studopedia.org — Студопедия.Орг — 2014-2022 год. Студопедия не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования (0.015 с) .

Определение профиля защиты и задания по безопасности Текст научной статьи по специальности «Компьютерные и информационные науки»

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Грищенко Лев Аркадьевич

В статье анализируются профили защиты, построенные на основе международного стандарта ISO/IEC 15408, описывающие сервисы безопасности, их комбинации и приложения. Выделяются общие требования, которые могут войти в состав функционального пакета, применимого ко всем сервисам, упрощающего разработку и понимание профилей для конкретных сервисов.

Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Грищенко Лев Аркадьевич

Текст научной работы на тему «Определение профиля защиты и задания по безопасности»

ОПРЕДЕЛЕНИЕ ПРОФИЛЯ ЗАЩИТЫ И ЗАДАНИЯ ПО БЕЗОПАСНОСТИ Грищенко Л.А.

Грищенко Лев Аркадьевич — магистрант, кафедра информатики и вычислительной техники, Новосибирский государственный технический университет, г. Новосибирск

Аннотация: в статье анализируются профили защиты, построенные на основе международного стандарта ISO/IEC 15408, описывающие сервисы безопасности, их комбинации и приложения. Выделяются общие требования, которые могут войти в состав функционального пакета, применимого ко всем сервисам, упрощающего разработку и понимание профилей для конкретных сервисов.

Ключевые слова: профиль защиты, информационная безопасность, ГОСТ Р ИСО/МЭК 15408, требования безопасности.

Профиль защиты (protection profile) — Независимая от реализации совокупность требований безопасности для некоторой категории изделий ИТ, отвечающая специфическим запросам потребителя [1]. Профиль защиты — это специальный нормативный документ, представляющий собой совокупность задач защиты, функциональных требований безопасности (ФТБ), требований адекватности и их обоснование.

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

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

Вторая часть, «Функциональные компоненты безопасности», устанавливает структуру и содержание компонентов функциональных требований безопасности для оценки безопасности. Она также включает в себя каталог функциональных компонентов, отвечающих общим требованиям к функциональным возможностям безопасности многих продуктов ИТ [2].

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

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

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

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

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

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

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

Для оценщиков в ИСО/МЭК 15408 содержатся критерии, которыми оценщики руководствуются при формировании заключения о соответствии объектов оценки предъявленным к ним требованиям безопасности.

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

• содержание файла или сервера;

• подлинность голосов, поданных на выборах;

• доступность процесса электронной коммерции;

• возможность использовать дорогостоящий принтер;

• доступ к средствам ограниченного доступа.

Среда, в которой размещаются эти активы, называется средой функционирования.

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

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

Среда функционирования также может содержать ошибки проектирования и реализации, что может привести к уязвимостям. Однако в ИСО/МЭК 15408 доверие не приобретается при рассмотрении корректности среды функционирования. Предполагается, что среда функционирования на 100% отражает цели безопасности для среды функционирования и ее не нужно оценивать.

Функциональные компоненты в ИСО/МЭК 15408-2 обычно имеют зависимости от других функциональных компонентов, также как некоторые компоненты доверия в ИСО/МЭК 15408-3 могут иметь зависимости от других компонентов ИСО/МЭК

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

Согласно ИСО/МЭК 15408 необходимо, чтобы требования основывались на компонентах из ИСО/МЭК 15408-2 или ИСО/МЭК 15408-3 с двумя исключениями:

• существуют цели безопасности для ОО, которые не могут быть преобразованы в ФТБ из ИСО/МЭК 15408-2, или существуют требования «третьей стороны» (например, законы, стандарты), которые не могут быть преобразованы в ТДБ из ИСО/МЭК 15408-3 (например, относящиеся к оценке криптографии);

• цели безопасности могут быть выражены на основе компонентов из ИСО/МЭК 15408-2 и/или ИСО/МЭК 15408-3, но только с большими трудностями и/или сложностями [3].

В обоих случаях от разработчика ПЗ/ЗБ требуется определить собственные компоненты. Эти вновь определенные компоненты называются расширенными компонентами. Точно определенный расширенный компонент необходим для обеспечения контекста и значения расширенных ФТБ или ТДБ, основанных на этом компоненте.

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

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

Профиль защиты описывает общие требования для типа ОО, поэтому его формирует не разработчик ОО (который обычно формирует ЗБ), а:

• сообществом пользователей, стремящихся прийти к консенсусу относительно требований для данного типа ОО;

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

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

В соответствии с ГОСТ Р ИСО/МЭК 15408, профиль защиты должен содержать следующие разделы:

• раздел «Введение ПЗ», содержащий описание типа ОО;

• раздел «Утверждения о соответствии», указывающий, утверждается ли в ПЗ о соответствии каким-либо ПЗ и/или пакетам, и если «да», то каким ПЗ и/или пакетам;

• раздел «Определение проблемы безопасности», в котором указываются угрозы, политика безопасности организации и предположения;

• раздел «Цели безопасности», показывающий, каким образом решение проблемы безопасности распределено между целями безопасности для ОО и целями безопасности для среды функционирования ОО;

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

чтобы определить расширенные функциональные требования и расширенные требования доверия;

• раздел «Требования безопасности», в котором цели безопасности для ОО преобразованы в изложение на стандартизованном языке. Этот стандартизированный язык представляет собой форму представления ФТБ.

Кроме того, в рассматриваемом разделе определяют ТДБ.

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

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

Рис. 1. Пример декомпозиции класса

ГОСТом Р ИСО/МЭК 15408 вводится уникальная краткая форма имени функционального элемента. Возьмем к примеру имя FAU_SAR.2.1. Оно читается следующим образом: F — функциональное требование, Аи — класс «Аудит безопасности», _SAR — семейство «Просмотр аудита безопасности», 2 (после точки) -второй компонент «Ограниченный просмотр аудита», 1 (после точки) — первый элемент компонента. То же самое обозначение применимо для ТДБ, только вместо F -функциональное требование, используется обозначение А — требование доверия к безопасности.

1. ГОСТ Р ИСО/МЭК 15408-1-2012. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 1. Введение и общая модель. — Взамен ГОСТ Р ИСО/МЭК 15408-1-2008; Введ. 01 — 12 — 2013. Москва: Стандартинформ, 2014.

2. ГОСТ Р ИСО/МЭК 15408-2-2013. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности. — Взамен ГОСТ Р ИСО/МЭК 15408-2-2008; Введ. 01 — 09 — 2014. -Москва: Стандартинформ, 2014.

3. ГОСТ Р ИСО/МЭК 15408-3-2013. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности. — Взамен ГОСТ Р ИСО/МЭК 15408-3-2008; Введ. 01- 09-2014. Москва: Стандартинформ, 2014.

ОГРАНИЧЕННО ГОМОМОРФНЫЕ СХЕМЫ ШИФРОВАНИЯ

Якушкина Анастасия Александровна — магистрант, направление: информационная безопасность, кафедра информационных технологий и систем, Дальневосточный государственный университет путей сообщений, г. Хабаровск

Аннотация: в статье представлен обзор известных ограниченно гомоморфных криптосистем. Обоснованы гомоморфные свойства рассмотренных криптосистем. Проведен сопоставительный анализ особенностей применения алгоритмов гомоморфного шифрования.

Ключевые слова: криптография, гомоморфное шифрование, облачные вычисления.

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

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

С исторической точки зрения в криптологии термин «гомоморфизм» впервые используется Ривестом, Адлеманом и Дертоузом [1] в 1978 году как возможное решение для вычисления без дешифровки. Этот базис привел к многочисленным попыткам исследователей во всем мире разработать такую гомоморфную схему с большим набором операций.

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

ОПРЕДЕЛЕНИЕ 1. Схема шифрования называется гомоморфной над операцией «?», если она поддерживает следующее уравнение:

РУКОВОДЯЩИЙ ДОКУМЕНТ. РУКОВОДСТВО ПО РАЗРАБОТКЕ ПРОФИЛЕЙ ЗАЩИТЫ И ЗАДАНИЙ ПО БЕЗОПАСНОСТИ (Утв. Гостехкомиссией РФ 2003)

6. Краткий обзор профилей защиты и заданий безопасности

В данной главе приводится краткий обзор и содержание ПЗ и ЗБ. Рассматриваются взаимосвязи между ПЗ и ЗБ и процесс их разработки (см. также Приложения Б и В части 1 ОК).

Требуемое содержание ПЗ приведено в Приложении Б части 1 ОК. Пример оглавления ПЗ представлен в таблице 1.

Таблица 1

Пример оглавления профиля защиты

1. Введение ПЗ

1.1. Идентификация ПЗ

1.2. Аннотация ПЗ

2. Описание ОО

3. Среда безопасности ОО

3.1. Предположения безопасности

3.2. Угрозы

3.3. Политика безопасности организации

4. Цели безопасности

4.1. Цели безопасности для ОО

4.2. Цели безопасности для среды

5. Требования безопасности ИТ

5.1. Функциональные требования безопасности ОО

5.2. Требования доверия к безопасности ОО

5.3. Требования безопасности для ИТ-среды

6. Замечания по применению

7. Обоснование

7.1. Логическое обоснование целей безопасности

7.2. Логическое обоснование требований безопасности

В разделе «Введение ПЗ» идентифицируется ПЗ и дается его аннотация в форме, наиболее подходящей для включения в каталоги и реестры ПЗ. Данный раздел ПЗ более подробно рассматривается в главе 7 настоящего Руководства.

В раздел «Описание ОО» включается сопроводительная информация об ОО (или типе ОО), предназначенная для пояснения его назначения и требований безопасности.

В раздел ПЗ «Среда безопасности ОО» включается описание аспектов среды безопасности ОО, которые должны учитываться для объекта оценки, в частности — детальное описание предположений безопасности, определяющих границы среды безопасности, угроз активам, требующим защиты (включая описание этих активов), и политики безопасности организации (ПБОр), которой должен удовлетворять ОО. Этот раздел ПЗ более подробно рассмотрен в главе 8 настоящего Руководства.

В раздел ПЗ «Цели безопасности» включается краткое изложение предполагаемой реакции на аспекты среды безопасности, как с точки зрения целей безопасности, которые должны быть удовлетворены ОО, так и с точки зрения целей безопасности, которые должны быть удовлетворены ИТ- и не-ИТ-мерами в пределах среды ОО. Данный раздел ПЗ более подробно рассмотрен в главе 9 настоящего руководства.

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

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

В разделе ПЗ «Обоснование» демонстрируется, что ПЗ специфицирует полную и взаимосвязанную совокупность требований безопасности ИТ и что соответствующий ОО учитывает идентифицированные аспекты среды безопасности. Раздел ПЗ «Обоснование» более подробно рассмотрен в главе 12 настоящего Руководства.

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

а) раздел «Введение ПЗ» может включать подраздел, описывающий организацию ПЗ, а также содержать ссылки на другие ПЗ и другие документы;

б) раздел «Среда безопасности ОО» может включать отдельные подразделы для различных доменов в ИТ-среде для ОО;

в) раздел «Требования безопасности ИТ» может быть расширен за счет включения, где необходимо, требований безопасности для не-ИТ-среды.

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

Требуемое содержание ЗБ дано в Приложении В части 1 ОК. Пример оглавления ЗБ представлен в таблице 2.

В разделе «Введение ЗБ» идентифицируется ЗБ и ОО (включая номер версии) и дается аннотация ЗБ в форме, наиболее подходящей для включения в список оцененных (сертифицированных) продуктов ИТ. Раздел «Введение ЗБ» более подробно рассмотрен в главе 7 настоящего Руководства.

В раздел ЗБ «Описание ОО» включается сопроводительная информация об ОО, предназначенная для пояснения его назначения и требований безопасности. Раздел ЗБ «Описание ОО» должен также включать описание конфигурации, в которой ОО подлежит оценке. Раздел ЗБ «Описание ОО» более подробно рассмотрен в главе 7 настоящего Руководства.

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

Таблица 2

Пример оглавления задания по безопасности

1. Введение ЗБ

1.1. Идентификация ЗБ

1.2. Аннотация ЗБ

2. Описание ОО

3. Среда безопасности ОО

3.1. Предположения безопасности

3.2. Угрозы

3.3. Политика безопасности организации

4. Цели безопасности

4.1. Цели безопасности для ОО

4.2. Цели безопасности для среды ОО

5. Требования безопасности ИТ

5.1. Функциональные требования безопасности ОО

5.2. Требования доверия к безопасности ОО

5.3. Требования безопасности для ИТ-среды

6. Краткая спецификация ОО

6.1. Функции безопасности ОО

6.2. Меры обеспечения доверия к безопасности

7. Утверждения о соответствии ПЗ

7.1. Ссылка на ПЗ

7.2. Уточнение ПЗ

7.3. Дополнение ПЗ

8. Обоснование

8.1. Логическое обоснование целей безопасности

8.2. Логическое обоснование требований безопасности

8.3. Логическое обоснование краткой спецификации ОО

8.4. Логическое обоснование утверждений о соответствии ПЗ

В раздел ЗБ «Цели безопасности» включается краткое изложение предполагаемой реакции на аспекты среды безопасности, как с точки зрения целей безопасности, которые должны быть удовлетворены ОО, так и с точки зрения целей безопасности, которые должны быть удовлетворены ИТ- и не-ИТ-мерами в пределах среды ОО. Данный раздел ЗБ более подробно рассмотрен в главе 9 настоящего Руководства.

В раздел ЗБ «Требования безопасности ИТ» включаются функциональные требования безопасности ОО, требования доверия к безопасности, а также требования безопасности программного, программно-аппаратного и аппаратного обеспечения ИТ-среды ОО. Требования безопасности ИТ должны быть определены путем использования, где это возможно, функциональных компонентов и компонентов доверия к безопасности частей 2 и 3 ОК. Раздел ЗБ «Требования безопасности ИТ» более подробно рассмотрен в главе 10 настоящего Руководства.

В раздел «Краткая спецификация ОО» включается описание функций безопасности ИТ, реализуемых ОО и соответствующих специфицированным функциональным требованиям безопасности, а также любых мер доверия к безопасности, соответствующих специфицированным требованиям доверия к безопасности. Раздел ЗБ «Краткая спецификация ОО» более подробно рассмотрен в главе 11 настоящего Руководства.

В разделе «Утверждения о соответствии ПЗ» идентифицируются ПЗ, о соответствии которым заявляется в ЗБ, а также любые дополнения или уточнения целей или требований из этих ПЗ. Раздел ЗБ «Утверждения о соответствии ПЗ» более подробно рассмотрен в главе 13 настоящего Руководства.

В разделе ЗБ «Обоснование» демонстрируется, что ЗБ специфицирует полную и взаимосвязанную совокупность требований безопасности ИТ, что соответствующий ОО учитывает определенные аспекты среды безопасности ИТ и что функции безопасности ИТ и меры доверия к безопасности соответствуют требованиям безопасности ОО. Раздел ЗБ «Обоснование» более подробно рассмотрен в главе 13 настоящего руководства.

Как и в случае ПЗ (см. п. 6.1), при разработке ЗБ можно отступать от вышеуказанной структуры путем включения дополнительных и исключения необязательных разделов (и/или подразделов) ЗБ.

При сопоставлении содержания таблиц 1 и 2 очевидна взаимосвязь между ПЗ и ЗБ вследствие высокой степени общности данных документов, в особенности разделов «Среда безопасности ОО», «Цели безопасности», «Требования безопасности ИТ» и, частично, — раздела «Обоснование». Если в ЗБ утверждается о соответствии ПЗ и при этом не специфицируются дополнительные функциональные требования и требования доверия к безопасности, то содержание упомянутых выше разделов ЗБ может быть идентично содержанию соответствующих разделов ПЗ. В таких случаях рекомендуется, чтобы ЗБ ссылалось на содержание ПЗ с добавлением, где необходимо, деталей, отличающих ЗБ от ПЗ.

Следующие разделы ЗБ не имеют аналогов в ПЗ и, таким образом, являются специфичными для ЗБ:

а) раздел «Краткая спецификация ОО» включает функции безопасности ИТ, механизмы и способы обеспечения безопасности, а также меры доверия к безопасности;

б) раздел «Утверждения о соответствии ПЗ» мотивирует и детализирует требования соответствия ПЗ;

в) подразделы раздела «Обоснование», которые демонстрируют адекватность функций безопасности ИТ и мер доверия к безопасности требованиям безопасности ОО.

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

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

Разделы «Введение ПЗ/ЗБ», «Описание ОО» и «Среда безопасности ОО» предназначены, прежде всего, для потребителей изделий ИТ. Раздел «Цели безопасности» также может быть написан в первую очередь для потребителей. Вместе с тем следует помнить, что и разработчики ОО должны будут принять во внимание информацию, находящуюся в разделах «Среда безопасности ОО» и «Цели безопасности».

Раздел ПЗ «Требования безопасности ИТ» предназначен, прежде всего, для разработчиков ОО, хотя информация, содержащаяся в этом разделе, вероятно, также будет интересна потребителям изделий ИТ. Раздел ЗБ «Краткая спецификация ОО» предназначен, прежде всего, для оценщиков и потребителей. Если последние два раздела не содержат достаточного количества информации, то в них необходимо поместить ссылку на другие разделы (подразделы) ПЗ (например, «Аннотация ПЗ») и документы, которые необходимы для полного и точного понимания представленных требований безопасности ИТ.

В раздел «Обоснование» включается информация, предназначенная преимущественно для оценщиков. В то же время оценщикам целесообразно ознакомиться со всеми разделами ПЗ и ЗБ.

Анализ приложений Б и В части 1 и глав 3 — 5 части 3 ОК показывает, что разработка ПЗ/ЗБ осуществляется в следующей (нисходящей) последовательности: — идентификация аспектов среды безопасности; — определение целей безопасности, учитывающих идентифицированные аспекты среды безопасности; — формирование требований безопасности ИТ, направленных на удовлетворение целей безопасности.

В общем случае, хотя и с учетом данной последовательности действий, процесс разработки ПЗ/ЗБ носит итеративный характер. Например, формирование требований безопасности может способствовать корректировке целей безопасности или даже потребностей в безопасности. В целом, может потребоваться целый ряд итераций для наиболее полного учета взаимосвязей между угрозами, ПБОр, целями и требованиями безопасности, а также функциями безопасности, в частности, при формировании «Обоснования» ПЗ/ЗБ. При этом только когда все проблемы формирования «Обоснования» ПЗ/ЗБ решены, процесс разработки ПЗ/ЗБ можно считать завершенным.

Процесс разработки ПЗ/ЗБ может также включать внесение изменений в документ с тем, чтобы отразить изменения условий применения, например:

— идентификацию новых угроз;

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

— корректировку требований безопасности ИТ, функций безопасности и/или мер доверия к безопасности, связанную с изменениями в технологии и затратах на разработку ОО.

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

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

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

— разработка совокупности ПЗ, каждый из которых относится к различным компонентам системы ИТ, например, семейство «смарт-карты» могло бы включать ПЗ для платы интегральной схемы, ПЗ для операционной системы, ПЗ для приложения, ПЗ считывателя смарт-карт и т.д.

Если семейство ПЗ относится к конкретному типу ОО, важно чтобы было четкое различие между различными членами семейства. Другими словами, должны быть четкие различия в требованиях безопасности ОО. Это связано с тем, что ПЗ должен, по крайней мере, отличаться целями безопасности, которые определяют выбор требований безопасности ИТ. В качестве примера, можно рассмотреть случай, когда два ПЗ специфицируют одну и ту же совокупность ФТБ, но разные ТДБ. Допускается мотивировать более низкое требование безопасности возрастанием безопасности среды ОО. Такие различия должны быть отражены в целях безопасности. Там же, где семейство ПЗ применяется к различным компонентам системы ИТ (в конкретной или предполагаемой среде), должны быть четко определены ПЗ, включенные в семейство (см. также главу 14 настоящего Руководства, в которой рассматриваются вопросы разработки ПЗ для компонентов системы ИТ).

Как и зачем писать задание на проектирование систем безопасности

Как часто Вы работаете по заданию, в котором предусмотрено все, что необходимо проектировщику? А можете ли Вы сразу после получения задания приступить к работе?

Как и зачем писать задание на проектирование систем безопасности

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

Что такое задание на проектирование?

Это документ, который заказчик и проектировщик разрабатывают и согласовывают для начала проектных работ.
Дорожная карта — он определяет, что необходимо запроектировать, в каком объеме, составе, на основании каких нормативных документов.
Чек-лист документов и данных, которые проектировщик запрашивает для начала работ, и которые будет разрабатывать после.

Для кого и зачем?

Заказчику, проектировщику, эксперту — всем.

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

Проектировщику — чтобы понимать, что от него требуется, в каком объеме и составе.

Эксперту — чтобы подтвердить, что проект соответствует требованиям задания.

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

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

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

Кто должен разрабатывать задание на проектирование?

Однозначно ответить на этот вопрос нельзя. Задание может написать заказчик самостоятельно, привлечь для этого проектировщика или третью сторону.

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

А без него можно?

Нет. Согласно Градостроительному кодексу РФ №190-ФЗ задание на проектирование — это документ, служащий основанием для начала проектных работ. Эти материалы заказчик обязан передать проектировщику.

Согласно Постановления Правительства РФ №145 задание на проектирование подается вместе с проектной документацией на экспертизу. Один из этапов экспертизы — оценка соответствия принятых проектных решений заданию. Этот документ заказчик обязан предоставить эксперту.

А исполнителю запроектировать что-либо, что одновременно будет соответствовать желаниям заказчика, требованиям норм и уже разработанным техническим системам без задания невозможно от слова «совсем».

В чем проблема?

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

Документы, которые устанавливают требования к заданию на проектирование это РД 25.952-90 и ГОСТ Р 57839-2017. Ни один из этих документов, на данный момент, не включен в перечень обязательных стандартов, обеспечивающих выполнение Технических регламентов, то есть не является обязательным к исполнению. Возможно, в будущем какой-то документ и включат в список обязательных и это упростит весь процесс, но пока этого не произошло.

Требования, которые устанавливают РД и ГОСТ значительно отличаются. Если разработать задание в соответствии с РД, а после — с ГОСТом, то это будет два разных документа.

На рис. 1 приведена таблица из приложения к РД 25.952-90. РД предлагает собрать данные о характеристиках защищаемых помещений по данной форме. Для каждого помещения указываем: площадь, высоту, категорию, класс взрывозащиты, относительную влажность и пр.

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

В 2017 году был введен в действие ГОСТ Р 57839-2017 «Производственные услуги. Системы безопасности технические. Задание на проектирование. Общие требования».

ГОСТ содержит более подробные требования по содержанию, чем РД. Он дает представление о том, как должен выглядеть документ от титульного листа до листа согласований. В нем приведен подробный перечень разделов и описаны требования по содержанию каждого из них (рис.2).

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

Если и разрабатывать типовой универсальный документ, то удобный и полезный — по ГОСТу.

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

Техническое задание или задание на проектирование?

Согласно официальной статистике Яндекса, за 2019-2020 гг. пользователи запрашивали “Задание на проектирование” 20 000 раз в месяц, а “Техническое задание” — 150 000 раз в месяц.

Говорящая статистика — в жизни задание на проектирование называют техническим заданием. Несмотря на то, что Градостроительный кодекс, Постановления правительства №87 и №145 единогласны в наименовании — задание на проектирование.

Задание на проектирование по ГОСТу является и техническим заданием, в том числе. Техническое задание — это описание технических характеристик разрабатываемой системы. Если задание на проектирование разрабатывают в соответствие с ГОСТ Р 57839-2017 (п.5, табл.1, рис.2), то оно содержит и необходимые описания технических требований.

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

С примером задания на проектирование для здания детского сада, разработанного по ГОСТ Р 57839-2017, можно ознакомиться ниже.

Время — самое ценное

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

Задание разработано для систем ПС, СОУЭ, АДУ, АВПВ, АПТ, ОС, СКУД, СОТ. А также оно подойдет для других систем безопасности, но с необходимыми корректировками. С полным перечнем систем безопасности можно ознакомиться в ГОСТ Р 56936-2016 “Производственные услуги. Системы безопасности технические. Этапы жизненного цикла систем. Общие требования”.

Обратная связь

А как в вашей практике обстоят дела с заданием на проектирование? Есть ли у Вас задание — стандарт организации, по которому Вы работаете? Всегда проектируете по заданию или умеете без него? Ответы, вопросы и пожелания, вы можете направить на e-mail: klimovadv@rubezh.ru или присоединиться к чату проектировщиков в Telegram. Буду рада получить от вас обратную связь.

Обзор Профиля защиты прикладного программного обеспечения. Методический документ Банка России

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

В частности, данное требование сформулировано в следующих нормативных актах (в уже действующих и в тех, которые вступят в силу в ближайшее время) Банка России:

Положение Банка России от 4 июня 2020 г. № 719-П «О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств». В пункте 1.2 данного акта для операторов по переводу денежных средств, банковских платежных агентов (субагентов), операторов услуг информационного обмена и операторов услуг платежной инфраструктуры выставляется требование по применению прикладного программного обеспечения автоматизированных систем и приложений, которые распространяются клиентам или взаимодействуют напрямую с сетью интернет (по сути, клиент-сервер), прошедшего сертификацию в системе сертификации Федеральной службы по техническому и экспортному контролю или оценку соответствия по требованиям к оценочному уровню доверия (далее — ОУД) не ниже чем ОУД 4 в соответствии с требованиями национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 15408-3-2013 «Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности». Для проведения оценки соответствия организации (кроме банковских платежных агентов, субагентов) должны привлекать внешние проверяющие организации.

Положение Банка России от 20 апреля 2021 г. № 757-П «Об установлении обязательных для некредитных финансовых организаций требований к обеспечению защиты информации при осуществлении деятельности в сфере финансовых рынков в целях противодействия осуществлению незаконных финансовых операций». В пункте 1.8 для некредитных финансовых организаций, реализующих усиленный и стандартный уровни защиты информации, указано аналогичное вышеуказанному требование по применению прикладного программного обеспечения, распространяемого клиентам или доступного к взаимодействию через сеть интернет, прошедшего сертификацию или оценку соответствия по ОУД 4. При этом, оценка соответствия прикладного ПО может проводиться как самостоятельно, так и с привлечением внешней проверяющей организации.

Таким образом, для организаций кредитно-финансовой сферы стоит задача обеспечения анализа прикладного программного обеспечения, которую в соответствии с требованиями можно решить путем сертификации по требованиям ФСТЭК или оценкой соответствия по ОУД4. При этом должна быть привлечена сторонняя организация.

Очевидно, что в текущих реалиях программное обеспечение (особенно в части взаимодействия с клиентами) очень часто изменяется. Проведение сертификации весьма проблематично, увеличит сроки выхода новых версий ПО и, по сути, приведет к потере конкурентоспособности как за счет долгих сроков вывода новых продуктов, так и за счет стоимости сертификации. С этой точки зрения (экономической эффективности) интересен опубликованный в июне 2021 года на Федеральном портале проектов нормативных правовых актов проект Указания Банка России «О внесении изменений в Положение Банка России от 17 апреля 2019 года № 683-П…», в котором одно из изменений касается возможности проведения оценки соответствия самостоятельно. Вероятно, аналогичные изменения и подходы будут «стандартизированы» по всем актам Банка России и позволят организациям выстраивать безопасную разработку целиком внутри себя.

В актах указана оценка соответствия в соответствии с ГОСТ Р ИСО/МЭК 15408-3-2013 «Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности», но общий характер ГОСТ и потребность в определении требований, учитывающих специфику финансовой сферы, сподвигло Банк России к разработке методического документа – профиля защиты (что и предусмотрено ГОСТ Р ИСО/МЭК 15408-3-2013, где в введении указано: «Компоненты доверия к безопасности, которые определены в ИСО/МЭК 15408-3, являются основой для требований доверия к безопасности, отражаемых в профиле защиты (ПЗ)»). Полное название методического документа – «ПРОФИЛЬ ЗАЩИТЫ прикладного программного обеспечения автоматизированных систем и приложений кредитных организаций и некредитных финансовых организаций» (далее – Профиль защиты) и, по всей видимости, он будет одним из основных методических документов для подразделений организаций финансово-кредитной сферы, обеспечивающих безопасную разработку.

Профиль защиты — достаточно объемный документ (155 страниц). Рассмотрим его основные разделы.

Из общих положений явно следует применение данного документа для сертификации и оценки соответствия как самими организациями кредитно-финансовой сферы, так и привлекаемыми внешними организациями. Указывается на то, что документ учитывает положения национальных стандартов Российской Федерации (хотелось бы отдельно отметить указанные в документе ГОСТ Р 57580.1-2017 и ГОСТ 34.603-92), отраслевых рекомендаций (РС БР ИББС-2.6-2014) и нормативных актов Банка России – в общем, разработчики документа постарались передать всю специфику требований мегарегулятора к своим поднадзорным.

Из введения следует, что документ разработан для оценочного уровня доверия 4 (ОУД4), усиленного рядом компонент. Хотелось бы отметить, что в 719-П и в проекте изменений 683-П для организаций поменьше (например, для не являющихся системно значимыми) предусмотрен ОУД5 – возможно, скоро данный документ получит обновление. Также в данном разделе указаны термины и определения, соглашения (операции «уточнение», «выбор», «назначение» и «итерация» над компонентами требований безопасности) и аннотация объекта оценки.

Аннотация объекта оценки (ОО) содержит подробное описание и, в принципе, её можно использовать как разъяснение объекта, к которому предъявляются требования из нормативных актов Банка России по проведению оценки соответствия или сертификации. Для ОО разъяснено что это такое, на каких технологических участках применяется и какие функциональные требования безопасности (ФТБ) предъявляются. Правильно реализованные (и в последующем периодически проверяемые) ФТБ обеспечат исключение возникновения типовых недостатков прикладного ПО:

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

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

защиту персональной идентификационной информации;

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

Следующий раздел Профиля защиты посвящен соответствую внешним документам (стандартам серии 15408, РС БР ИББС-2.6-2014) и так и называется — «Утверждение о соответствии». Особое внимание можно уделить подразделу 3.5, в котором идет речь о строгом соответствии документов организации (разработанных, в свою очередь, на базе Профиля защиты) всем требованиям Профиля защиты, но не ограничиваясь (т.е. документы организации могут и должны быть шире, повышая детализацию и учитывая специфику прикладного программного обеспечения, применяемого в организации). В случае, если строгое соответствие невозможно, должно быть обоснование, в соответствии с риск-ориентированным подходом, как обработан соответствующий риск нарушения информационной безопасности.

В следующем разделе «Определение проблемы безопасности» идет разбор угроз, которые обязательно нужно рассмотреть:

угроза НСД к информации при наличии уязвимостей на стороне организации, за счет доступа к оборудованию;

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

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

Рис. 1. Матрица соответствия целей угрозам и политикам

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

Цель безопасности ОО-1. ОО должен обеспечивать контроль целостности своей установки и пакетов обновлений, а также эффективно использовать способы предотвращения нарушений целостности, предоставляемые средой выполнения, эффективно использовать документированные и поддерживаемые возможности, предоставляемые средой выполнения. Обеспечивать контроль доступа (ролевой, дискреционный, мандатный) к объектам, находящимся под контролем ПО.

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

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

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

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

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

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

Перечислим направления (классы), которым посвящены функциональные требования безопасности:

Профили защиты, разработанные на основе «Общих критериев». Часть 1. Общие требования к сервисам безопасности

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

Общие положения

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

» Общие критерии » в применении к оценке безопасности изделий информационных технологий (ИТ) являются, по сути, метасредствами, задающими систему понятий, в терминах которых должна производиться оценка, но не предоставляющих конкретных наборов требований и критериев, подлежащих обязательной проверке. Эти требования и критерии фигурируют в профилях защиты (ПЗ) и заданиях по безопасности (ЗБ) (см., например, [ 56 ] , [ 20 ] , [GTKRRPP]).

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

В настоящее время такая база и в мире (см., например, [ 95 ] , ), и в России только создается. В нашей стране эту работу курирует ФСТЭК — Федеральная служба по техническому и экспортному контролю (ранее Государственная техническая комиссия при Президенте РФ — Гостехкомиссия России).

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

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

• идентификация и аутентификация ;
• управление доступом ;
• протоколирование и аудит ;
• шифрование;
• контроль целостности;
• экранирование;
• анализ защищенности ;
• обеспечение отказоустойчивости;
• обеспечение безопасного восстановления ;
• туннелирование;
• управление .

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

Выделение сервисов туннелирования и управления еще не вошло в общепринятую практику, поэтому пока они обойдены вниманием разработчиков ПЗ.

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

Если придерживаться объектно-ориентированного подхода (см., например, курс [ 91 ] , а также книгу [ 90 ] ), то целесообразно выделить по крайней мере два уровня в иерархии наследования требований к сервисам безопасности:

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

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

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

Задание по безопасности

Этот документ, содержащий требования безопасности для конкретного изделия ИТ.

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

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

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

ЗБ является основой для проведения оценки безопасности изделия ИТ.

Задание по безопасности содержит дополнительную информацию, ориентированную на конкретную реализацию продукта ИТ и разъясняющую, каким образом требования ПЗ реализуются в конкретном продукте ИТ. Задание по безопасности содержит следующую дополнительную по отношению к ПЗ информацию:

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

применимо); в) материалы обоснования, устанавливающие, что краткая

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

Структура задания по безопасности

Краткая спецификация ОО должна определить отображение требований безопасности И предоставить описание функций безопасности и мер доверия к ОО.

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

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

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

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

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

— конкретизацию ПЗ, идентифицирующую те требования безопасности ИТ, в которых выполняются операции, разрешенные в ПЗ, или дополнительно уточняются требования ПЗ;

— дополнение ПЗ, идентифицирующее цели и требования безопасности ОО, которые дополняют цели и требования ПЗ.

Случай, когда в ЗБ утверждается о частичном соответствии ПЗ, не приемлем для оценки в рамках ОК.

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

Должно быть продемонстрировано следующее:

— сочетание специфицированных для ОО функций безопасности ИТ при совместном использовании удовлетворяет функциональным требованиям безопасности ОО;

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

— строго обосновано утверждение, что изложенные меры доверия соответствуют требованиям доверия.

Уровень детализации логического обоснования должен соответствовать уровню детализации определения функций безопасности.

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

Разработка профилей защиты

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

Профиль защиты должен содержать:

— описание потребностей пользователей изделия ИТ в обеспечении безопасности;

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

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

— функциональные требования безопасности и требования доверия к безопасности, которые направлены на решение проблемы безопасности в соответствии с описанием среды безопасности и целями безопасности для изделия ИТ. Функциональные требования безопасности выражают то, что должно выполняться изделием ИТ и его средой для удовлетворения целей безопасности. Требования доверия к безопасности определяют степень уверенности в правильности реализации функций безопасности изделия ИТ. Функциональные требования безопасности и требования доверия к безопасности должны обеспечивать достижение целей безопасности;

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

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

Требования безопасности профилей защиты

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

Рекомендации по разработке ПЗ изложены в РД Гостехкомиссии России «Руководство по разработке профилей защиты и заданий по безопасности».

Оценка и сертификация ПЗ

Оценка ПЗ выполняется согласно критериям оценки ПЗ, содержащимся в части 3 РД Гостехкомиссии России «Критерии оценки безопасности информационных технологий».

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

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

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

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

Регистрация и публикация ПЗ

После завершения разработки проекта профиля защиты подается заявка на его регистрацию в орган регистрации профилей защиты в соответствии с РД Гостехкомиссии России «Руководство по регистрации профилей защиты». При положительном результате проверки ПЗ включается в реестр профилей защиты. Орган регистрации обеспечивает ведение реестра профилей защиты и его публикацию.

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