CC BY
73
ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ
УДК 004.056.5
МЕТОДИКА ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ ПРОЦЕССА ОЦЕНКИ ЗАЩИЩЕННОСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ ПО «ОБЩИМ КРИТЕРИЯМ» О.Е. Зайцев, А.В. Любимов
При построении функциональной модели «Общих критериев» (ОК) используется методика БЛОТ и еe нотация DFD. Методика БЛОТ изначально не может адекватно отобразить модель ОК в связи с определенной спецификой объекта моделирования, поэтому для получения методики функционального моделирования ОК в методику БЛОТ необходимо внести некоторые коррективы. Ключевые слова: модель, методика, моделирование, функциональный.
Введение
Национальный стандарт безопасности ГОСТ Р ИСО/МЭК 15408-2002 «Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий» («Общие критерии», ОК) действует в России с 1 января 2004 года. Опыт использования ОК говорит о том, что применение методологии ОК способствует существенному повышению качества оценки и разработки продуктов и информационных технологий (ИТ). Таким образом, оценка защищенности ИТ по ОК является перспективным направлением, а проблемы, связанные с использованием ОК, очень актуальны.
Решению многих задач способствует представление ОК в виде формальных моделей. Как правило, функциональная модель является основной и наиболее применяемой на практике. Функциональная модель ОК может быть построена с помощью методики структурного анализа и проектирования систем БЛОТ. Данная методика изначально не может должным образом отобразить модель ОК, что связано с определенной спецификой самого объекта моделирования. Поэтому для получения методики функционального моделирования ОК в методику БЛОТ необходимо внести некоторые коррективы. В настоящей работе представлены результаты разработки методики построения функциональной модели деятельности оценщика и разработчика по оценке защищенности ИТ на основе методики БЛОТ, скорректированной с учетом специфики ОК как объекта моделирования.
Постановка задачи
Автоматизация многих действий по оценке и сертификации продуктов и систем ИТ возможна благодаря строгой регламентации деятельности оценщика и разработчика, описанной в «Общей методологии оценки» (ОМО) и в ОК. Для проектирования, разработки и сопровождения соответствующего программного обеспечения необходимо иметь функциональные спецификации в стандартизованной электронной форме. Представление деятельности по оцениванию защищенности ИТ, регламентируемой ОК, в виде стандартизованной функциональной модели предоставляет удобные средства контроля версий стандарта и обеспечивает возможность прослеживания последствий принимаемых в новых версиях изменений вплоть до уровня конкретных операций, что существенно облегчает как работу сотрудников испытательных лабораторий при проведении оценки, так и работу разработчиков при подготовке к ней. Наименее подготовленной к предстоящему внедрению ОК группой пользователей являются заказчики ИС и покупатели готовых продуктов. Для них формализованное графическое представление ОК является кратким справочником.
Перечисленные факторы обусловливают актуальность функционального моделирования методологии ОК и определяют постановку задачи моделирования.
Исходя из сравнительного анализа методик моделирования, для построения функциональной модели ОК была выбрана методика SADT, поскольку в данной области моделирования она практически не имеет альтернативы, методики ARIS и CALS являются избыточными в данном случае. SADT-модель дает полное, точное и адекватное описание системы, имеющее конкретное назначение. Обзор зарубежных источников выявил лишь одну попытку функционального моделирования фрагментов ОК [1]. Однако при построении диаграмм реально не использовалась какая-либо определенная методика или метод, фактически они представляют собой иллюстрации, а не формализованную модель. Модель построена не по стандарту, что не позволяет говорить об ее дальнейшей применимости в области оценки и сертификации ИТ вследствие неполноты и субъективности.
В отечественной литературе идея использования методики SADT в совокупности с методом DFD для построения формальной модели процессов оценки безопасности ИТ по стандарту ОК была предложена в [2] и получила дальнейшее развитие в [3-5]. Методика построения функциональной модели деятельности по оценке защищенности ИТ, о которой говорится в настоящей работе, в целом соответствует методологии SADT, т.е. использует принцип пошаговой детализации процессов и ресурсов. Однако специфика объекта моделирования приводит к необходимости внесения в методологию SADT весьма существенных корректив, а в некоторых случаях вынуждает использовать приемы, идущие вразрез со сложившейся практикой функционального анализа. В данной работе затрагиваются такие сложности декомпозиции и приемы их преодоления.
Методика построения функциональной модели
Детализация процессов
Детализация процессов функциональной модели проводится по принципу «сверху вниз», т.е. класс доверия детализируется на семейства, семейства - на компоненты, компоненты - на элементы.
Имена процессов не совпадают с именами соответствующих классов, а, как правило, являются именем класса с добавленным отглагольным существительным. Для дополнительного отслеживания соответствия модели тексту стандарта к имени процесса в скобках добавляется идентификатор класса. Аналогичное правило именования применяется и к семействам доверия, например, «Оценка анализа уязвимостей (AVA_VLA)» и т. д.
Определение для процессов уровня классов извлекается из третьей части ОК и ОМО, причем в качестве источника определения выбирается раздел с наиболее полной информацией. При наличии расхождений предпочтение отдается ОМО. Ссылка на источник заносится во вкладку Note свойств процесса. Аналогичная процедура применяется для процессов уровня семейств.
При моделировании действий разработчика некоторые компоненты семейств, например, содержат действия, которые лежат вне принятых границ моделирования и поэтому не должны отображаться на диаграммах модели. Однако эти действия являются существенными для процесса оценивания (как правило, вследствие того, что порождают важные для оценки ресурсы - документы) и потому должны в модели каким-то образом учитываться. Противоречие может быть разрешено двумя способами.
Во-первых, подобный компонент можно включить в модель как процесс, не имеющий входов (что противоречит синтаксису стандарта DFD). Выходы такого процесса отображаются, например, пунктиром, чтобы напомнить о том, что они являются, вообще говоря, элементами свидетельств оценки, поступающими от разработчика, а не внутренними ресурсами данной диаграммы. Подобный процесс можно дополнительно выделить с по-
мощью стандартных графических примитивов. Во-вторых, подобный компонент можно вообще не размещать на диаграмме, разместив вместо нее экземпляр внешней сущности «Разработчик» с выходящими из него необходимыми ресурсами, выделив их определенным образом, но этот вариант не допускает дальнейшей детализации процесса.
Практически все компоненты семейств доверия имеют иерархическую структуру. С ростом оценочного уровня доверия (ОУД) компонент с меньшим номером заменяется компонентом с большим номером, который обеспечивает большее доверие к безопасности (усиление компонента). Это означает, что, несмотря на то, что на диаграмме отображаются все компоненты семейства, при каждой конкретной процедуре оценивания будет выполняться только один из них. Подобную ситуацию невозможно явно отразить на ОБО диаграмме, поскольку этот стандарт не содержит средств отображения логики процессов, однако ее можно описать с помощью текстового комментария.
Представление подобных иерархий методом функционального моделирования всегда вызывает большие проблемы. Причина состоит в том, что, по существу, подобные иерархии представляют собой схемы наследования, т.е. являются предметом рассмотрения в объектной области (структурное моделирование), а для представления их в рамках функциональной модели приходится вводить существенную избыточность как для процессов, так и для ресурсов. Иерархичность компонентов выражается также и в их именовании, т. е. в стандарте используются сокращенные имена, которые неточно, а иногда и превратно отражают содержание соответствующих процессов. Например, «Независимый анализ уязвимостей», помимо анализа уязвимостей оценщиком, включает в себя еще множество других действий. В итоге пришлось отказаться от полной привязки имен процессов к именам компонентов в стандарте и трактовать последние просто как названия разделов. Процессу, который соответствует компоненту, дается оригинальное имя, в наибольшей степени соответствующее его содержанию, а для привязки к стандарту используется идентификатор компонента (например, ЛУЛ_УЬЛ), именование процессов, соответствующих элементам, производится по их содержанию, описанному в ОК, с добавлением идентификатора.
Для получения точного представления о структуре семейства можно составить таблицу, представляющую разбиение семейства на компоненты и на элементы, на которой проще отследить различия и избыточность. В этой таблице столбцами являются компоненты, а строками - номер ОУД и компонента, а также элементы действий оценщика и разработчика. В таблице схематично показана подобное разбиение, где XXX - идентификатор класса, УУУ - идентификатор семейства, Б - идентификатор разработчика, Е -идентификатор оценщика.
ОУД 1 2 3 4
Компонент 1 2 3 4
Элементы дейст- XXX УУУ.1.1Б XXX УУУ.2.1Б XXX УУУ.3.1Б XXX УУУ.4.1Б
вий разработчи- описание компо- описание компо- описание компо- описание компо-
ка нента нента нента нента
Элементы дейст- XXX УУУ.1.1Е XXX УУУ.2.1Е XXX УУУ.3.1Е XXX УУУ.4.1Е
вий оценщика описание компо- описание компо- описание компо- описание компо-
нента нента нента нента
Элементы дейст- XXX УУУ.2.1Б XXX УУУ.2.1Б XXX УУУ.2.1Б XXX УУУ.2.1Б
вий разработчи- описание компо- описание компо- описание компо- описание компо-
ка нента нента нента нента
Элементы дейст- XXX УУУ.2.1Е XXX УУУ.2.1Е XXX УУУ.2.1Е XXX УУУ.2.1Е
вий оценщика описание компо- описание компо- описание компо- описание компо-
нента нента нента нента
Таблица. Детализация семейства
Детализация ресурсов
Под входными ресурсами в данной модели понимаются различные компоненты свидетельств оценки, под выходными - результаты выполнения действий оценщика, как правило, заключения и их обоснования. Все прочие ресурсы относятся к внутренним, если не оговорено противное.
Иерархичность компонентов доверия порождает избыточность не только при декомпозиции процессов, но и при декомпозиции ресурсов для компонентов. При этом следует учитывать, что содержимое одного и того же ресурса меняется в зависимости от того, для какого компонента этот ресурс предназначен, и это отличие должно быть отражено не только в определении ресурса, но и в его имени. Однако при детализации ресурсов, помимо эффекта иерархичности, приходится учитывать и другие, не менее значимые факторы. Прежде всего, это «обратное» направление детализации.
Детализация ресурсов выполняется по принципу «снизу вверх», что соответствует структуре разделов стандарта: из простых ресурсов собираются составные. Это противоречит методологии SADT (в соответствии с которой ресурсы тоже должны детализироваться сверху вниз, вместе с процессами и по мере их детализации), но в данной задаче это допустимо, поскольку детализация процессов практически регламентирована.
Вторым существенным фактором является то, что для детализации ресурсов приходится использовать англоязычный оригинал стандарта Common Criteria [6-8] для более полного и точного построения модели. Дело в том, что в ОК изменена структура свидетельств оценки (при сохранении суммарного содержания), которые являются базовыми ресурсами модели, и эти изменения, к сожалению, проведены не в лучшую сторону. Например, в этих стандартах одному и тому же компоненту может соответствовать различное число элементов содержания и представления свидетельств, при этом их больше в англоязычном оригинале стандарта. Как и для процессов, для получения точного представления о структуре ресурсов семейства полезно составить таблицу, представляющую разбиение свидетельств оценки семейства по компонентам и элементам. Действия, касающиеся необходимых усилений и добавлений, используя англоязычный вариант, выполняются аналогично как для входящих, так и для исходящих ресурсов.
При декомпозиции выходных и внутренних ресурсов приходится в значительно большей степени использовать ОМО, поскольку ОК содержат недостаточно информации по содержанию и форме представления результатов деятельности оценщика. При этом следует учитывать различие в структурировании деятельности оценщика (в основном - терминологическое), имеющее место в этих документах.
В соответствии с подразделом 2.2.5 ОМО, оценщик выносит вердикты относительно выполнения требований ОК [9]. Наименьшая структурная единица ОК, по которой выносится вердикт, - элемент действий оценщика (явный или подразумеваемый). Вердикт выносится как результат выполнения соответствующего действия. В итоге результат оценки формируется в соответствии с подразделом 5.3 части 1 ОК: вердикты по элементам действий объединяются в вердикты по компонентам, затем - в вердикты по классам, и, наконец, по ОО в целом. Все вердикты сначала являются неокончательными и сопровождаются различного рода обоснованиями, образуя «Заключение». Вся совокупность заключений по выполненным действиям оценщика представляет собой «Технические результаты оценки», которые на завершающем этапе оценки преобразуются в два документа: «Сообщения о проблемах» и «Технический отчет об оценке» (при этом неокончательные вердикты преобразуются в окончательные).
Рис. 1. Диаграмма детализации процесса «Экспертиза и анализ руководств (АУА_МБи.2)»
AVAJVLA Свидетельства оценки анализа уязвимостей
AVAJVLA. 1 Свидетельства оценки анализа уязвимостей разработчиком
Выбор компонентов: для ОУД2, ОУДЗ - AVA VLA.1; для ОУД4 - AVA VLA.2; для ОУД5 AVA VLA.3; для ОУДб, ОУД7 - AVA VLA.4
AVAJVLA, 1 Оценка анализа
уязвимостей разработчиком
AVA VLA.1 Заключение по анализу уязвимостей разработчиком
А\'А_\ЪА.2 Свидетельства оценки анализа уязвимостей и оценки стойкости для низкого потенциала нападения
А\'А_\ХА,2
Анализ уязвимостей и оценка стойкости для низкого потенциала нападения
А\;А_\ХА.2 Заключение по анализу уязвимостей и оценка стойкости для низкого потенциала нападения
А\А_\ЪА.З
Анализ уязвимостей и оценка стойкости для умеренного потенциала нападения
AVAJVLA Заключение по анализу уязвимостей
А\7А \LA.4
Анализ уязвимостей и оценка стойкости для высокого потенциала нападения
Рис. 2. Диаграмма детализации процесса "Оценка анализа уязвимостей (AVA_VLA)"
Таким образом, формируется следующий алгоритм детализации выходных ресурсов. Заключение по классу доверия ОК (виду деятельности ОМО) есть объединение (join) заключений по семействам доверия ОК (подвидам деятельности ОМО). Заключе-
ние по семейству совпадает с заключением по одному из компонентов ОК, а именно по тому компоненту, который предусматривается согласованным ОУД. Это должно быть явно отмечено в определении ресурса. Заключение по компоненту ОК (подвиду деятельности ОМО) есть объединение заключений по элементам ОК, а они, в свою очередь, формируются по описанию элементов действий оценщика в ОМО. Их именование производится по аналогии с именованием процессов. Отличие в детализации различных ресурсов заключается лишь в сложности декомпозиции, возрастающей благодаря наличию усиления компонентов, а также в том, что некоторые выходные ресурсы одних элементов становятся входными ресурсами других, т. е. являются внутренними для диаграммы детализации компонента. Результат описанных выше действий по детализации можно рассмотреть на рис. 1.
После вышеописанных действий детализация действий оценщика заканчивается, компоненты по определенным ОУД, не описанные в стандарте, не детализируются, и проведение оценки для таких ОУД по стандарту ОК невозможно. Далее объединение ресурсов проводится аналогичным образом для диаграмм более высоких уровней. Подобное объединение ресурсов продемонстрировано на рис. 2.
Заключение
Опыт использования ОК говорит о том, что применение методологии ОК способствует существенному повышению качества оценки и разработки продуктов и систем ИТ. Таким образом, оценка защищенности ИТ по ОК является перспективным направлением, а проблемы, связанные с использованием ОК, очень актуальными. При этом решению многих задач способствует представление ОК в виде формальных моделей. Как правило, функциональная модель является основной и наиболее применяемой на практике. Функциональная модель ОК может быть построена с помощью методики структурного анализа и проектирования систем SADT. Данная методика изначально не может должным образом отобразить модель ОК, поэтому для получения методики функционального моделирования ОК в методику SADT необходимо внести некоторые коррективы. В настоящей работе представлена методика построения функциональной модели деятельности оценщика и разработчика по оценке защищенности ИТ на основе методики SADT и нотации DFD, скорректированная с учетом специфики ОК.
Литература
1. Prieto-Diaz, R. The Common Criteria Evaluation Process. Process Explanation, Shortcomings, and Research Opportunities // Commonwealth Information Security Center Technical Report CISC-TR-2002-03, December 2002. - CISC, James Madison University, USA.
2. Любимов А.В. Функциональная структура общих критериев оценки безопасности информационных технологий // Труды 9-й н.-т. конф. «Теория и технология программирования и защиты информации. Применение вычислительной техники». -Санкт-Петербург, 18 мая 2005 г. - С. 20-24.
3. Зайцев О.Е. Базовые параметры формальных моделей оценки защищенности ИТ по «Общим критериям» // Научно-технический вестник СПбГУ ИТМО. - 2007. - Выпуск 39. Исследования в области информационных технологий. - С. 20 - 26.
4. Зайцев О.Е., Любимов А.В., Суханов А.В. Подходы к структурному моделированию основных компонентов безопасности ИТ «Общих критериев» // Труды 11-й н.-т. конф. «Теория и технология программирования и защиты информации. Применение вычислительной техники». - Санкт-Петербург, 18 мая 2007 г. - С. 56-60.
5. Любимов А.В. Структурное моделирование стандартов информационной безопасности // V Санкт-Петербургская межрегиональная конференция «Информационная
безопасность регионов России (ИБРР-2007)». - Санкт-Петербург, 23-25 октября 2007 г. - Материалы конференции. - СПб, 2007. - С. 57-58.
6. Common Criteria for Information Technology Security Evaluation. Version 2.2. Revision 256. Part 1: Introduction and general model. - January 2004.
7. Common Criteria for Information Technology Security Evaluation. Version 2.2. Revision 256. Part 2: Security functional requirements. - January 2004.
8. Common Criteria for Information Technology Security Evaluation. Version 2.2. Revision 256. Part 3: Security Assurance Requirements. - January 2004.
9. РД Безопасность информационных технологий. Общая методология оценки безопасности информационных технологий (проект). - ФСТЭК России, 2005.
Зайцев Олег Евгеньевич — Санкт-Петербургский государственный универси-
тет информационных технологий, механики и оптики, аспирант, zoe83@mail.ru Любимов Александр Вилиевич — Санкт-Петербургский государственный универси-
тет информационных технологий, механики и оптики, кандидат технических наук, доцент, a_v_l@inbox.ru
УДК 004.75, 004.772, 004.62
АНАЛИЗ ФАКТОРОВ, ВЛИЯЮЩИХ НА КАЧЕСТВЕННЫЕ И КОЛИЧЕСТВЕННЫЕ ПОКАЗАТЕЛИ ФУНКЦИОНИРОВАНИЯ СИСТЕМ РАСПРЕДЕЛЕННОГО ХРАНИЛИЩА ДАННЫХ
Н.М. Лукьянов, В.В. Кириллов
В работе проводится исследование распределенных хранилищ данных, анализ качественных и количественных показателей их функционирования. Результатом исследования является функциональная модель системы распределенного хранилища данных, построенная для работы в составе Интернет-сервисов. Ключевые слова: хранилища, распределенные, показатели, Интернет, сервис.
Введение
Раньше создание распределенной системы хранения данных было специфической задачей, необходимость которой была не очевидна. Сегодня, на совершенно ином техническом уровне, необходимость в распределенных системах хранения очевидна. В сети Интернет широкое распространение получили различные сервисы, предоставляющие услуги размещения, накопления и обмена различной информации, такой как фотографии, видеоматериалы, текстовые документы, электронная почта и т.д. Эти сервисы так или иначе используют в своей работе хранилища данных, которые имеют оригинальные характеристики и свойства. Каждая подобная система имеет свою архитектуру и решает свою конкретную задачу.
Данное исследование направлено на построение и анализ распределенного хранилища данных, предназначенного для работы с интерактивными веб-сервисами.
Постановка задачи
Долгое время распределенные файловые системы использовались в основном в кластерных системах, которые занимались сбором и обработкой большого количества информации, возникающей при решении таких задач, как имитация физических процессов, анализ радиосигналов, генетический анализ, расчет компьютерной графики, финансовое моделирование и т.д. [1].
