CC BY
63
БАЗОВЫЕ ПАРАМЕТРЫ ФОРМАЛЬНЫХ МОДЕЛЕЙ ОЦЕНКИ ЗАЩИЩЕННОСТИ ИТ ПО «ОБЩИМ КРИТЕРИЯМ»
О.Е.Зайцев
Научный руководитель - к.т.н., доцент А.В. Любимов
В современных методах формального моделирования решающее влияние на результирующую модель оказывает выбор ее базовых свойств (назначение, точка зрения, границы моделирования), а также ее контекста. В работе представлены результаты анализа и выбора этих параметров в задаче построения функциональной модели оценки защищенности ИТ на основе ГОСТ ИСО/МЭК 15408 (Общие Критерии).
Введение
Национальный стандарт безопасности ГОСТ Р ИСО/МЭК 15408-2002 «Информационная технология. Методы обеспечения безопасности. Критерии оценки безопасности информационных технологий» (краткое название - «Общие критерии») действует в России с 1 января 2004 года. В его основе лежит стандарт в области оценки безопасности информационных технологий (ИТ) «Common Criteria» (CC) 1999 года, разработанный под эгидой Международной организации по стандартизации. Семилетний опыт использования «Общих Критериев» в мире и небольшой опыт, полученный при апробации в России, говорит о том, что применение методологии ОК способствует существенному повышению качества оценки и разработки продуктов и систем ИТ. Объемы работ по оценке и сертификации ИТ, выполняемые в настоящее время за рубежом и планируемые в России, с неизбежностью приводят к необходимости использования инструментальных программных средств поддержки деятельности по подготовке и проведению оценок. Современные методы разработки подобных средств предполагают широкое применение формальных моделей предметной области, по крайней мере, на стадиях специфицирования и высокоуровневого проектирования.
Решению перечисленных задач, как и многих других, способствует представление «Общих Критериев» в виде формальных моделей: функциональной модели деятельности по оценке защищенности ИТ, структурной модели защищенности ИТ и математической модели компонентов защищенности ИТ. Как правило, функциональная модель является основной и наиболее применяемой на практике, поэтому в данной статье будет рассматриваться построение функциональной модели защищенности ИТ, остальные формальные модели ОК будут рассмотрены в дальнейшем.
Функциональная модель ОК может быть построена с помощью методики структурного анализа и проектирования систем SADT, но, прежде чем приступать непосредственно к процессу моделирования, необходимо определить свойства этой модели и ее контекст.
В настоящей работе представлены результаты анализа объектной области и определение базовых свойств функциональной модели, а также построения контекстной модели оценки защищенности ИТ для дальнейшего построения полной функциональной модели на основе ГОСТ ИСО/МЭК 15408.
Постановка задачи выбора базовых свойств формальных моделей ОК
Основной причиной создания международного стандарта ИСО/МЭК 15408 «Критерии оценки безопасности информационных технологий» являлась необходимость унификации и взаимного признания национальных стандартов в области безопасности информационных технологий. Кроме того, единый набор международных стандартов, разработанный для достижения этой цели, позволяет упростить принятие решений при покупке программных продуктов и предоставляет возможность корпоративным заказчикам приобрести системы с более надежной защитой [1]. Применение ОК также спо-
собствует существенному повышению качества оценки и разработки продуктов и систем ИТ.
По прошествии некоторого времени использования стандарта ОК в области сертификации и оценки безопасности продуктов ИТ стало ясно, что предусмотренные стандартом средства не являются достаточно полными для полноценного их использования на практике и, безусловно, нуждаются в существенном расширении. Методология ОК в стандарте не имеет явного описания, ее элементы рассредоточены по тексту, который, вместе с сопутствующей нормативно-методической документацией, составляет около двух тысяч страниц. При этом значительная часть русскоязычной методической документации находится в стадии разработки или причислена к know-how и потому является недоступной.
Вскоре необходимость в более полном описании и расширении средств регламентации деятельности по оценке была восполнена новым нормативным документом «Общая методология оценки» (ОМО) [2], перевод английского варианта - «Common Methodology for Information Technology Security Evaluation» [3], сопровождающим ОК. Основным предметом рассмотрения ОМО являются именно действия по оценке защищенности с использованием критериев и свидетельств оценки, определенных в ОК [4].
Для реализации стандартов ОК и ОМО разработчикам пришлось рассмотреть общие подходы, методы и функции обеспечения защиты информации в организациях, а также описать, каким образом функции системы информационной безопасности обеспечивают выполнение требований конфиденциальности, целостности, достоверности и доступности информации [5]. Наличие таких обобщений позволяет применять методы научного анализа и в первую очередь - построение формальных моделей. В данной работе идет речь об одной из таких моделей - функциональной модели деятельности по оценке защищенности ИТ в рамках стандартов ОК и ОМО. Функциональная модель ОК должна отображать основные действия оценщика и разработчика, описанные, в основном, в ОМО.
Автоматизация многих действий по оценке и сертификации продуктов и систем ИТ возможна благодаря строгой регламентации деятельности оценщика и разработчика. Для проектирования, разработки и сопровождения соответствующего программного обеспечения необходимо иметь функциональные спецификации в стандартизованной электронной форме. Также стандартизованная функциональная модель предоставляет удобные средства контроля версий стандарта и обеспечивает возможность прослеживания последствий принимаемых в новых версиях изменений вплоть до уровня конкретных операций, что существенно облегчает как работу сотрудников испытательных лабораторий при проведении оценки, так и работу разработчиков при подготовке к ней. Наименее подготовленной к предстоящему внедрению ОК группой пользователей являются заказчики ИС и покупатели готовых продуктов. Для них формализованное графическое представление ОК является кратким справочником.
Перечисленные выше факторы обусловливают необходимость функционального моделирования методологии ОК.
Исходя из сравнительного анализа методик моделирования, для построения функциональной модели ОК обоснованно была выбрана методика SADT, поскольку в данной области моделирования она практически не имеет альтернативы, методики ARIS и CALS являются избыточными в данном случае. SADT-модель дает полное, точное и адекватное описание системы, имеющее конкретное назначение. Еще одним важным моментом перед построением модели, помимо выбора метода моделирования, является определение базовых свойств и контекста будущей модели согласно выбранной методике моделирования. Определение свойств проводится на самом раннем этапе проектирования. Таким образом, целью настоящей работы является представление базовых свойств и контекста функциональной модели.
Обзор зарубежных источников выявил лишь одну попытку функционального моделирования фрагментов ОК [6]. Однако при построении диаграмм реально не использовалась какая-либо определенная методика или метод, фактически они представляют собой иллюстрации, а не формализованную модель. Модель построена не по стандарту, что не позволяет говорить об ее дальнейшей применимости в области оценки и сертификации ИТ вследствие своей неполноты и субъективности. В отечественной литературе идея использования методики SADT в совокупности с методом DFD для построения формальной модели процессов оценки безопасности ИТ по стандарту ОК была предложена в [7].
Определение базовых свойств и контекста функциональной модели ОК
Свойства модели
В соответствии с методикой функционального моделирования, изложенной в международных [9] и российских [10] стандартах, определяющим свойством модели является ее назначение (Purpose), т.е. цель моделирования. Целью служит набор вопросов, на которые должна ответить модель. В результате анализа ситуации в области оценки безопасности ИТ было установлено, что основная цель моделирования - представление для целевой аудитории базовой системы процессов оценки защищенности ИТ по стандарту ОК в максимально компактной, наглядной и формализованной форме, допускающей как дальнейшую детализацию, так и коррекцию в соответствии с последующими версиями стандарта. Модель также может использоваться в качестве базовой части функциональных спецификаций для инструментального программного обеспечения поддержки процессов оценивания и в качестве справочника оценщиками при проведении оценки конкретной системы ИТ, и специалистами системы сертификации при разработке нормативно-методической документации.
Следующим свойством является точка зрения моделирования (Viewpoint). С этим свойством связана задача выбора точки зрения при моделировании, которая существенно влияет как на границы моделирования в целом, так и на объемлющий процесс детализации, осуществляемый в ходе построения самой модели. Точку зрения лучше всего представлять себе как место (позицию) человека или объекта, в которое надо встать, чтобы увидеть систему в действии. С этой фиксированной точки зрения можно создать согласованное описание системы так, чтобы в модели не смешивались несвязанные описания. В данном случае было принято решение проводить моделирование с точки зрения оценщика, так как эта роль является ключевой в процессе оценки, и ее использование позволяет построить наиболее универсальную функциональную модель. Цель и точка зрения - это основополагающие понятия SADT [10].
После фиксации цели и точки зрения моделирования стало возможным дать определение (Definition) модели, т.е., в соответствии с методом IDEF, описать ее содержание, а также определить границы (Scope) моделирования, т.е. дать описание процессов, лежащих вне области моделирования (или на ее границе) и определить степень детализации.
Определение модели. Модель содержит представление системы процессов оценивания безопасности ИТ, описывающей совокупность основных действий, которые должны выполнять заинтересованные стороны в соответствии со стандартом ОК версии 2.2. Эта система процессов дополнена процедурами, лежащими вне рамок ОК, но предусмотренных ОМО версии 1.1а (в частности - предварительными процедурами оценивания и процедурами завершения оценивания).
Границы моделирования. Модель содержит представление процессов подготовки, проведения и завершения оценки безопасности продуктов и систем ИТ (объектов оценки), предусмотренных ОК и ОМО. Детализация проводится до уровня, позволяю-
щего представить процессы генерации и использования основных документов, предусмотренных ОК и ОМО, их разделов и подразделов. Учитывая принятую точку зрения моделирования, подсистема процессов проведения оценки детализируется более подробно. Вне области моделирования лежат: функционирование системы аккредитации органов по сертификации, процессы деятельности системы сертификации ИТ, оценивание профилей защиты и разработка задания по безопасности. Оценка задания по безопасности (класс ASE) для рассматриваемого ОО включается в область моделирования как промежуточный процесс. Процессы разработки и регистрации нормативно-методических документов оценивания находятся вне границ моделирования, а сами нормативно-методические документы, наряду с объектом оценки, являются внешними ресурсами модели.
Деятельность владельцев (информационных) активов и иных пользователей системы ИТ, а также органов по сертификации составляет контекст модели. Элементы деятельности разработчиков и потребителей систем ИТ, а также заявителей включается в модель лишь в том случае, если они имеют непосредственное отношение к оцениванию. Остальные элементы деятельности этих агентов составляют контекст модели.
Контекст модели
В настоящее время актуальными являются два основополагающих документа ОК, описывающих функциональность деятельности по оценке защищенности ИТ, это -собственно Общие Критерии и сопровождающая их Общая методология оценивания. Часть I первого документа представляет собой общее введение, Часть II представляет собой справочник ФБО, и только часть III посвящена непосредственно элементам действий оценщика. Таким образом, для построения функциональной модели деятельности по оценке может использоваться только часть III ОК и, в небольшой степени, Часть I. Однако основным недостатком части III ОК является тот факт, что она представляет собой, по существу, просто справочник функциональных элементов, никак не связанных друг с другом. По ней не удается выделить общий поток работ при оценке конкретного продукта или системы ИТ при заданных условиях, а также трудно отделить работы, выполняемые на стороне разработчика, от работ, выполняемых на стороне оценщика, и представить их в виде взаимосвязанных и при этом явным образом различимых потоков.
Очевидно, что в плане организации процесса оценки эти задачи представляют существенную важность. В плане же функционального анализа решение этих задач предполагает правильное определение контекста модели:
(1) внешних агентов, т.е. внешних сущностей, деятельность которых осуществляется вне рамок модели;
(2) внешних ресурсов, т.е. информационных, материальных, финансовых и пр. ресурсов, которыми эти внешние сущности обмениваются с процессами, происходящими внутри модели.
В рассматриваемой предметной области роль внешних агентов очень важна, так как при выполнении многих действий по оценке весьма существенно, от кого именно оценщику приходит данный конкретный документ или кому именно оценщик направляет тот или иной свой вердикт, и в качестве нотации и метода функционального моделирования был выбран метод диаграмм потоков данных (DFD). Этот метод, по сравнению с более распространенным IDEF0, позволяет, во-первых, гораздо более полно отразить на диаграммах роли сущностей, которые инициируют, выполняют, заканчивают или используют результаты выполнения процессов, во-вторых, дает возможность гораздо более полно представить обмен ресурсами (в частности - документами) межу сущностями процессов. Более детальный сравнительный анализ преимуществ и недостатков методов IDEF0 и DFD приведен в работе [11].
В ходе анализа были сформированы четыре основные сущности процесса оценки. Первые три сущности являются внешними, четвертая (Оценщик) - внутренней.
Разработчик - организация или группа, ответственная за проектирование, разработку, тестирование и модификацию объекта оценки (ОО), в частности - за включение в ОО функций безопасности, описанных в ОК, и за устранение выявленных уязвимо-стей. При этом следует обратить внимание на то, что, как отмечено в ОМО, некоторые оценки (например, оценка на ОУД1 (оценочный уровень доверия)) могут вообще не требовать непосредственного участия разработчика. В этом случае сам заявитель представляет оценщику объект оценки и свидетельства оценки. Тем не менее, эта внешняя сущность определенно должна присутствовать в модели, так как ее роль возрастает с ростом заявляемого ОУД.
Заявитель - организация или группа, инициирующая оценку, т.е. являющаяся заказчиком оценки и отвечающая за обеспечение оценщика свидетельствами оценки. Заявитель заключает договор с оценщиком и оплачивает его работу. При формировании роли «Заявитель» также наблюдались содержательные проблемы. Например, в ОМО отмечается, что заявителем может быть разработчик ОО или организация, в которую входит разработчик (совмещение ролей), однако для полноты представления функциональности в модели эти роли было решено разделить.
Орган по сертификации - организация, прошедшая аккредитацию (ФСТЭК) на право проведения работ по сертификации по требованиям безопасности ИТ.
Оценщик - организация, уполномоченная органом по сертификации на право проведения работ по оценке продуктов с систем ИТ по требованиям безопасности (испытательная лаборатория).
Рис. 1. Диаграмма контекстной модели деятельности по оценке защищенности ИТ
В завершение рассмотрения сущностей процесса оценки необходимо заметить, что в число четырех базовых внешних агентов не входит такая немаловажная роль, как Потребитель (организация, группа лиц или лицо, использующее ОО в конкретных условиях). Дело в том, что в рамках оценки ИТ по ОК функции, выполняемые потребителем (устанавливает цели безопасности, формирует специфические запросы по безопасности, решает, является ли продукт или система ИТ достаточно безопасной для ее предполагаемого применения), имеют только опосредованное отношение собственно к процессам оценки, за исключением лишь одного случая, когда потребитель может зака-
зать проведение анализа безопасности продукта или системы ИТ, т.е. оценку безопасности [12]. Однако в этом случае он просто-напросто выступает в роли Заказчика.
В ходе анализа были также выделены основные потоки данных (документов), которыми обмениваются основные внешние агенты, содержание которых, в основном, ясно из имен. В итоге была получена контекстная модель деятельности по оценке защищенности ИТ по стандартам ОК и ОМО, изображенная на рис. 1.
Научная новизна настоящей работы обусловлена тем фактором, что впервые к системе понятий и процессов, составляющих основное содержание Общих Критериев, применен в полном объеме стандартизованный и хорошо себя зарекомендовавший в других задачах метод функционального моделирования SADT. В результате описанные выше определенные базовые свойства и контекст позволили построить полную функциональную модель оценки защищенности ИТ по стандарту «Общие Критерии» в соответствии с методикой моделирования SADT и выбранной нотацией DFD, детализировав эту модель до уровня представления элементов действий оценщика и разработчика. На основании идей и эскизных начальных проработок по функциональному моделированию ОК, предложенных в [7], а также внесенных в методику SADT коррективов для учета особенностей моделируемого объекта, была получена модель, в состав которой входит 91 функциональная диаграмма, 241 процесс в иерархии и 410 ресурсов.
Заключение
Национальный стандарт безопасности ГОСТ Р ИСО/МЭК 15408-2002 «Информационная технология. Методы обеспечения безопасности. Критерии оценки безопасности информационных технологий» (краткое название - «Общие критерии») действует в России с 1 января 2004 года. Опыт использования «Общих Критериев» говорит о том, что применение методологии ОК способствует существенному повышению качества оценки и разработки продуктов и систем ИТ. Таким образом, оценка защищенности ИТ по ОК является перспективным направлением, а проблемы, связанные с использованием ОК - очень актуальными.
Решению многих задач способствует представление «Общих Критериев» в виде формальных моделей. Как правило, функциональная модель является основной и наиболее применяемой на практике. Функциональная модель ОК может быть построена с помощью методики SADT, но, прежде чем приступать непосредственно к процессу моделирования, необходимо было определить свойства этой модели и ее контекст.
В настоящей работе были определены базовые свойств функциональной модели, а также построена контекстная модель оценки защищенности ИТ для дальнейшего построения полной функциональной модели на основе ГОСТ ИСО/МЭК 15408.
Литература
1. Рэдклифф Д. Одна мера безопасности на всех // Computerworld. 2000. № 12. C. 7-8.
2. РД Безопасность информационных технологий. Общая методология оценки безопасности информационных технологий (проект). / ФСТЭК России, 2005.
3. Common Methodology for Information Technology Security Evaluation. Evaluation Methodology. January 2004. Version 2.2. Revision 256. CCIMB-2004-01-004.
4. Кобзарь М., Сидак А. Методология оценки безопасности информационных технологий по общим критериям // JetInfo. 2004. № 6 (133). 53 с.
5. Афанасьев В.Н. Общие критерии безопасности информационных систем. / Международная студенческая школа-семинар «Новые информационные технологии», г. Судак, 14-21 мая 2003, Тезисы докладов в 2-х томах М.: МГИЭМ, 2003. 641 с.
6. 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.
7. Любимов А.В. Функциональная структура общих критериев оценки безопасности информационных технологий. / Труды 9-й научно-технической конференции «Теория и технология программирования и защиты информации. Применение вычислительной техники». Санкт-Петербург, 18 мая 2005 г. С. 20-24.
8. Federal Information Processing Standards Publication 183. Announcing the Standard for «Integration Definition for Function Modeling (IDEF0)». 21 December 1993.
9. РД IDEF0-2000. Методология функционального моделирования IDEF0. Руководящий документ. Издание официальное. Госстандарт России. Москва, 2000.
10. Марка Д., Макгоуэн К. Методология структурного анализа и проектирования SADT М.: МетаТехнология, 1993. 240 c.
11. Калянов Н., Козлинский А.В., Лебедев В.Н. Сравнительный анализ структурных методологий // Системы управления базами данных. 1997. №05. С. 12-17.
12. ГОСТ Р ИСО/МЭК 15408-1-2002. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 1. Введение и общая модель. М.: Госстандарт России, 2002.
