CC BY
75
4
ТЕОРИЯ И ТЕХНОЛОГИЯ ПРОГРАММИРОВАНИЯ И ЗАЩИТЫ ИНФОРМАЦИИ
ФОРМАЛЬНОЕ МОДЕЛИРОВАНИЕ «ОБЩИХ КРИТЕРИЕВ» КАК ИНСТРУМЕНТ ВНЕДРЕНИЯ И ПРОДВИЖЕНИЯ СТАНДАРТА ГОСТ Р ИСО/МЭК 15408 О.Е.Зайцев, А.В.Любимов
В работе представлен обзор актуальной информации в области оценки защищенности информационных технологий, на основе которого обосновывается актуальность использования методов формального моделирования для внедрения и продвижения стандарта ГОСТ Р ИСО/МЭК 15408 «Общие Критерии» (ОК) в РФ. Дается постановка задачи формального моделирования ОК, проводится сравнительный анализ методов и обосновывается выбор методики и нотации функционального моделирования.
Введение
Национальный стандарт безопасности ГОСТ Р ИСО/МЭК 15408-2002 «Информационная технология. Методы обеспечения безопасности. Критерии оценки безопасности информационных технологий» (краткое название - «Общие критерии») начал действовать в России с 1 января 2004 года. В его основе лежит стандарт в области оценки безопасности информационных технологий (ИТ) «Common Criteria» (CC) 1999 г., разработанный под эгидой Международной организации по стандартизации. Исторически сложившимся названием в России этого стандарта является Руководящий документ «Безопасность информационных технологий» (РД БИТ). Семилетний опыт использования «Общих критериев» в мире и небольшой опыт, полученный при апробации в России, говорит о том, что применение методологии ОК способствует существенному повышению качества оценки и разработки продуктов и систем ИТ.
Объемы работ по оценке и сертификации ИТ, выполняемые в настоящее время за рубежом и планируемые в России, приводят к необходимости использования инструментальных программных средств поддержки деятельности по подготовке и проведению оценок. Современные методы разработки подобных средств предполагают широкое применение формальных моделей предметной области, по крайней мере, на стадиях специфицирования и высокоуровневого проектирования.
Решению перечисленных задач, как и многих других, а также внедрению и продвижению ОК в России способствует представление «Общих критериев» в виде множества разноплановых проекций. Такими проекциями являются три модели: функциональная модель деятельности по оценке защищенности ИТ, структурная модель защищенности ИТ и математическая модель компонентов защищенности ИТ. Как правило, функциональная модель является основной и наиболее применяемой на практике, поэтому здесь будет рассматриваться вопрос, касающийся построения функциональной модели защищенности ИТ, остальные формальные модели ОК будут рассмотрены в дальнейшем.
В настоящей работе обосновывается актуальность использования методов формального моделирования для внедрения и продвижения стандарта ГОСТ Р ИСО/МЭК 15408 в РФ, дается постановка задачи формального моделирования ОК, проводится сравнительный анализ методов и обосновывается выбор методики и нотации функционального моделирования.
Постановка задачи функционального моделирования ОК
Основной причиной создания международного стандарта ИСО/МЭК 15408 «Критерии оценки безопасности информационных технологий» (Common Criteria) являлась необходимость унификации и взаимного признания национальных стандартов в области безопасности информационных технологий. Кроме того, единый набор международных стандартов, разработанный для достижения этой цели, позволяет упростить принятие решений при покупке программных продуктов и предоставляет возможность корпоративным заказчикам приобрести системы с более надежной защитой [1].
ОК представляют собой базовый стандарт, содержащий методологию задания требований и оценки безопасности ИТ, а также систематизированный каталог требований безопасности. В качестве функциональных стандартов, в которых формулируются требования к безопасности определенных типов продуктов и систем ИТ, предусматривается использование профилей защиты (ПЗ), создаваемых на основе каталога требований. В ПЗ могут быть включены и другие требования, необходимые для обеспечения безопасности конкретного типа продуктов или систем ИТ. Изложенная в ОК методология формирования требований и универсальный каталог требований безопасности (функциональных и доверия) позволяют формировать наборы требований (ПЗ, задания по безопасности и пакеты) для различных типов продуктов и систем ИТ. Несмотря на то, что ОК направлены на оценку продуктов и систем ИТ и в документе содержится методология оценки, они включают не только методологию формирования требований для оценки, но и методологию формирования требований к разработчику по организации процесса разработки, по предоставлению материалов, необходимых для проведения оценки, а также другие обязанности разработчика в процессе проведения оценки [2]. Таким образом, применение ОК способствует существенному повышению качества оценки и разработки продуктов и систем ИТ.
Внедрение ОК в России спланировано поэтапно. До 2007 г. организации, в информационных системах которых циркулирует конфиденциальная информация, могли самостоятельно выбирать, по каким стандартам (старым или новым) проводить аттестацию, в отличие от организаций, которые обрабатывают в своих автоматизированных системах данные, содержащие сведения, представляющие собой государственную тайну. Для госструктур, которые имеют дело с подобной информацией, остаются в силе прежние РД Гостехкомиссии и требования ФСБ и бывшего ФАПСИ. Поскольку внедрение нового ГОСТ является частью правительственной программы по вступлению России в ВТО, а, как известно, при вступлении в эту организацию в стране-претенденте должны быть унифицированы некоторые стандарты, в том числе и в области информационной безопасности, в ближайшем будущем становится неизбежной масштабная деятельность по оцениванию и сертификации продуктов ИТ по стандарту ОК [3]. По этой причине уже сейчас существует необходимость подготовки значительного числа специалистов по ОК как для центров оценки и сертификации, так и для фирм-разработчиков, фирм-поставщиков и организаций-пользователей.
По прошествии некоторого времени использования стандарта ОК в области сертификации и оценки безопасности продуктов ИТ стало ясно, что предусмотренные стандартом средства не являются достаточно полными для полноценного их использования на практике и, безусловно, нуждаются в существенном расширении. Методология ОК в стандарте не имеет явного описания, ее элементы рассредоточены по тексту, который, вместе с сопутствующей нормативно-методической документацией, составляет около двух тысяч страниц. При этом значительная часть русскоязычной методической документации находится в стадии разработки или причислена к know-how и потому является недоступной. Такое положение дел является причиной недоступности методологии ОК для широкого круга пользователей. Вскоре необходимость в более полном описании и расширении средств регламентации деятельности по оценке была восполнена новым нормативным документом «Общая методология оценки» (ОМО) [4] - переводом английского варианта «Common Methodology for In-
formation Technology Security Evaluation» [5], сопровождающим ОК. Главным мотивирующим моментом создания ОМО стала необходимость унификации способов и приемов проведения оценки по ОК с целью выработки механизмов взаимного признания оценок.
Как известно основным предметом ОК являются элементы защиты (функции защищенности, свидетельства оценки, компоненты доверия к ним), в то время как основным предметом рассмотрения ОМО являются именно действия по оценке защищенности с использованием критериев и свидетельств оценки, определенных в ОК. В первую очередь ОМО предназначен для оценщиков, которые используют ОК, а также экспертов органов по сертификации, подтверждающих действия оценщиков. Также ОМО полезен заявителям на проведение оценки в целях получения исходной информации, разработчикам продуктов и систем ИТ, профилей защиты и заданий по безопасности, а также другим сторонам, заинтересованным в обеспечении безопасности ИТ [6].
Для реализации стандартов ОК и ОМО разработчикам пришлось рассмотреть общие подходы, методы и функции обеспечения защиты информации в организациях, а также описать, каким образом функции системы информационной безопасности обеспечивают выполнение требований конфиденциальности, целостности, достоверности и доступности информации [7]. Наличие таких обобщений позволяет применять методы научного анализа, в первую очередь - построение формальных моделей. В данной работе идет речь об одной из таких моделей - функциональной модели деятельности по оценке защищенности ИТ в рамках стандартов ОК и ОМО. Функциональная модель ОК должна отображать основные действия оценщика и разработчика, описанные, в основном, в ОМО. Актуальность задачи функционального моделирования методологии ОК обусловливают перечисленные ниже факторы.
Автоматизация многих действий по оценке и сертификации продуктов и систем ИТ возможна благодаря строгой регламентации деятельности оценщика и разработчика, описанной в основном в ОМО и частично в ОК. Для проектирования, разработки и сопровождения соответствующего программного обеспечения необходимо иметь функциональные спецификации в стандартизованной электронной форме. Также стандартизованная функциональная модель предоставляет удобные средства контроля версий стандарта и обеспечивает возможность прослеживания последствий принимаемых в новых версиях изменений вплоть до уровня конкретных операций, что существенно облегчает как работу сотрудников испытательных лабораторий при проведении оценки, так и работу разработчиков при подготовке к ней. Наименее подготовленной к предстоящему внедрению ОК группой пользователей являются заказчики ИС и покупатели готовых продуктов. Для них формализованное графическое представление ОК является кратким справочником.
Таким образом, представление базовых концепций ОК и их взаимосвязей в виде формальной структурированной функциональной модели является совершенно необходимым условием для продвижения и эффективного применения стандарта «Общие критерии».
Обзор зарубежных источников выявил лишь одну попытку функционального моделирования фрагментов ОК [8]. Однако при построении диаграмм реально не использовалась какая-либо определенная методика или метод, фактически они представляют собой иллюстрации, а не формализованную модель. Модель построена не по стандарту, что не позволяет говорить об ее дальнейшей применимости в области оценки и сертификации ИТ вследствие своей неполноты и субъективности. В отечественной литературе идея использования методики SADT в совокупности с методом DFD для построения формальной модели процессов оценки безопасности ИТ по стандарту ОК была предложена в [9]. Настоящая работа представляет собой ее обоснование.
Выбор и обоснование выбора метода функционального моделирования ОК
Проблема выбора методики функционального представления стандарта ОК при решении данной задачи не является критической, поскольку классическая методика SADT в данной области моделирования практически не имеет альтернативы. Получившая распространение в последние пять лет методика ARIS (Architecture of Integrated Information System) [10] ориентирована на процессы, протекающие в рамках сложной организационной структуры, а появившаяся практически одновременно методика CALS (Continuous Acquisition and Life cycle Support) [11] нацелена на представление сложных технологических цепочек процессов в многоагентной среде. Обе эти методики в поставленной задаче являются избыточными.
Методика моделирования SADT была разработана Дугласом Россом. Она представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Следует учитывать, что под методикой моделирования (как функционального, так и информационного) принято понимать «триаду»: 1) метод моделирования (способ анализа); 2) нотация моделирования (способ графического отображения результата анализа, т.е. собственно модели); 3) программное средство, поддерживающее первые два элемента триады. Однако обычно для краткости вместо термина «метод» используют термин «модель», подчеркивая тем самым основной результат анализа. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Методика SADT основывается на следующих принципах:
(1) графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, входящими в блок и выходящими из него. Взаимодействие блоков друг с другом отображается посредством интерфейсных дуг, которые определяют, когда и каким образом функции выполняются и управляются;
(2) строгость и точность выполнения правил SADT:
(а) ограничение количества блоков на каждом уровне декомпозиции (3-6 блоков);
(б) связность диаграмм (нумерация блоков);
(в) уникальность имен;
(г) синтаксические правила для графических примитивов (блоков и дуг);
(д) разделение входов и управлений (правило определения роли данных).
(е) отделение организации от функции, т.е. исключение влияния организационной структуры на функциональную модель [12].
Технические результаты оценки 1 Требования к СП и ТОО Сообщения о
Завершение оценки проолемах
Технический
отчет об оценке
Рис. 1. Функциональный блок завершения оценки с интерфейсными дугами
Функциональная модель состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы - главные компоненты модели отображения информационной системы (ИС), все функции ИС и интерфейсы на них представлены как функциональные блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, информация, которая подвергается обработке, входит в блок с левой стороны, а результаты выхода выходит с правой стороны блока. Таким образом, функциональный блок диаграммы «Процесс оценки безопасности продукта или системы ИТ» функциональной модели ОК будет выглядеть так, как показано на рис. 1.
Рис. 2. Диаграмма «Оценка глубины тестирования разработчика (АТЕ_РРТ)»
Рис. 3. Диаграмма «Оценка тестирования на соответствие проекту верхнего уровня (АТЕ_йРТ.1)»
Важной особенностью методики БАОТ является постепенное увеличение уровней детализации по мере создания диаграмм. Каждый компонент модели может быть декомпозирован (детализирован) на другой диаграмме. Каждая диаграмма отображает строение блока на диаграмме предыдущего, более высокого уровня. На рис. 3 приведен
пример детализации блока ATE_DPT.1, изображенного на диаграмме ATE_DPT (рис. 2). Диаграмма ATE_DPT.1 является результатом детализации диаграммы ATE_DPT, что отображено в названии блоков.
Методика SADT предоставляет 3 метода моделирования: IDEF0 (Integration Definition for Function Modeling), IDEF3 и DFD. Анализируя и сравнивая между собой данные методы для решения поставленной задачи, однозначно выбирается метод DFD.
Действительно, метод IDEF0 моделирования бизнес-процессов фокусируется на высокоуровневом представлении операций и на факторах, которые контролируют эти операции. В рассматриваемой задаче все контролирующие факторы очевидны, а операции, наоборот, должны представляться на весьма низком уровне - вплоть до элементов или даже шагов действий оценщика. Поэтому метод IDEF0 не подходит. Такой же вывод, но по другим причинам, можно сделать и в отношении метода IDEF3, который фокусируется на бизнес-логике выполнения операций и на принятии решений, относящихся к выполнению определенной операции, а также на том, каким образом осуществляется синхронизация процессов. В поставленной задаче данной работы эти вопросы не имеют существенного значения, в первую очередь благодаря тем широким возможностям распараллеливания работ на независимые действия, которые обеспечиваются в рамках методологии ОК. К тому же метод IDEF3 практически лишен средств описания данных (документов, свидетельств, результатов действий), которые являются важнейшими компонентами процесса оценивания.
Метод DFD является модификацией метода IDEF0. Главной модификацией стала трактовка функциональных блоков (activities) как модулей программной системы. В остальном основная суть метода IDEF0, последовательная иерархическая декомпозиция, не изменилась, так как прекрасно вписывалась в область нисходящего проектирования программных систем. Впоследствии идея ICOM в отношении дуг оказалась излишней (на примере ИС): управления, ограничивающие или предписывающие условия выполнения функций модуля стали очевидными - это просто его программа; механизмы, показывающие, кто и с помощью чего выполняет функцию модуля - это компьютер и операционная система. Входы и выходы модулей стали равноправны - это потоки данных, передаваемых от модуля к модулю. Таким образом, все синтаксические ограничения были отброшены. Тем не менее, при такой трактовке нотация IDEF0 оказалась явно бедна - в ней не хватало нескольких элементов, которые и были добавлены.
Внешние источники (External References), располагаемые на контекстной диаграмме, позволяют явно описать внешние источники и приемники данных модели -внешние программные системы, внешние базы данных, внешние организации, операторы и т. д. Важно также, что можно использовать несколько экземпляров одного и того же внешнего источника на разных диаграммах модели. Это упрощает ее читаемость за счет существенного уменьшения числа потоков данных.
Хранилища данных (Data Stores), которые также можно использовать в нескольких экземплярах на разных диаграммах модели, позволяют описать «данные в покое». По существу, это прообразы таблиц базы данных проектируемой программной системы. Дуги, соединяющие их с модулями программной системы, моделируют информационный обмен приложений с базой данных.
Ссылки на другие страницы позволяют описывать передачу данных от модуля к модулю, избегая их «протаскивания» через все диаграммы верхнего уровня.
Таким образом, DFD-модели гораздо более информативны и более легко читаемы. Даже на контекстном уровне большая информативность DFD-диаграмм очевидна. В настоящее время диаграммы верхнего уровня иерархии, описывающие контекст деятельности организации в целом, выполняются в нотации IDEF0, а конкретные процессы, предназначенные для автоматизации на более низких уровнях иерархии, выполняются в нотации DFD. Таким образом, наилучшим выбором в задаче функционального
моделирования ОК является метод DFD, который фокусируется именно на операциях обработки данных - данных, необходимых для проведения операций или создаваемых какими-либо операциями; данных для групп или организаций, которые либо предоставляют, либо получают данные; потоком данных между различными действиями, видами или подвидами действий или операциями, а также между операциями и вовлеченными хранилищами данных. Метод DFD, по сравнению с IDEF0, позволяет, во-первых, гораздо более полно отразить на диаграммах роли сущностей, которые инициируют, выполняют, заканчивают или используют результаты выполнения процессов, а во-вторых, дает возможность гораздо более полно представить обмен ресурсами (в частности - документами) межу сущностями процессов.
Таким образом, задача выбора методики моделирования деятельности по оценке защищенности ИТ по стандарту «Общие критерии» решена.
Научная новизна настоящей работы состоит в том, что описанная выше методика SADT и ее метод графического отображения DFD позволили построить полную функциональную модель оценки защищенности ИТ по стандарту "Общие критерии", детализировав эту модель до уровня представления элементов действий оценщика и разработчика. На основании идей и исходных материалов по функциональному моделированию ОК, предложенных в [9], а также внесенных коррективов в методику SADT, в связи с особенностями моделируемого объекта, была получена модель, в состав которой входит 91 функциональная диаграмма, 241 процесс в иерархии и 410 ресурсов.
Заключение
Национальный стандарт безопасности ГОСТ Р ИСО/МЭК 15408-2002 «Информационная технология. Методы обеспечения безопасности. Критерии оценки безопасности информационных технологий» был принят в России 1 января 2004 года. Семилетний опыт использования «Общих критериев» в мире и небольшой опыт, полученный при апробации в России, говорит о том, что применение методологии ОК способствует существенному повышению качества оценки и разработки продуктов и систем ИТ. Таким образом, оценка защищенности ИТ по ОК является перспективным направлением, а проблемы, связанные с использованием ОК, очень актуальными.
Для внедрения, продвижения и эффективного использования данного стандарта необходимо представить «Общие критерии» в виде формализованных, структурированных моделей, таких как структурная, функциональная и математическая модель. Также к представлению ОК в формальной форме приводят работы по оценке и сертификации ИТ, выполняемые в настоящее время за рубежом и планируемые в России. В данном случае необходимо использовать инструментальные программных средства поддержки деятельности по подготовке и проведению оценок, а современные методы разработки подобных средств предполагают широкое применение формальных моделей. Представление ОК в виде формальной модели позволяет решать ряд практических задач в области оценки защищенности продуктов и систем ИТ и сертификации.
В данной работе речь шла о функциональной модели, так как она является основной и наиболее используемой на практике. Для построения функциональной модели ОК изначально необходимо было выбрать метод моделирования и обосновать данный выбор, что и было проделано. Исходя из сравнительного анализа методик и методов моделирования, обоснованно была выбрана методика SADT и ее нотация DFD.
Литература
1. Рэдклифф Д. Одна мера безопасности на всех. // Computerworld. 2000. № 12. С.76-80.
2. ГОСТ Р ИСО/МЭК 15408-1-2002. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 1. Введение и общая модель. Госстандарт России, Москва, 2002.
3. Просяников Р.Е., Савельев М.С. ГОСТ 15408: Станут ли общими «Общие критерии». -Secure Networks, 2005. <http://www.secure.com.ru/modules.cfm?block=portal_b_documents&id=A7ZE70A3316 950558>
4. РД Безопасность информационных технологий. Общая методология оценки безопасности информационных технологий (проект). - ФСТЭК России, 2005.
5. [CEM] Common Methodology for Information Technology Security Evaluation. Evaluation Methodology. January 2004. Version 2.2. Revision 256. CCIMB-2004-01-004.
6. Кобзарь М., Сидак А. Методология оценки безопасности информационных технологий по общим критериям. - Jetinfo, № 6 (133), 2004. сс.2-16.
7. Афанасьев В.Н. Общие критерии безопасности информационных систем. - Международная студенческая школа-семинар "Новые информационные технологии", г. Судак, 14 - 21 мая, 2003, Тезисы докладов XI в 2-х томах - М.: МГИЭМ, 2003. 641с.
8. 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. 62 p.
9. Любимов А.В. Функциональная структура общих критериев оценки безопасности информационных технологий. - Труды 9-й научно-технической конференции "Теория и технология программирования и защиты информации. Применение вычислительной техники." Санкт-Петербург, 18 мая 2005 г. сс.20-24.
10. Шеер Август-Вильгельм. Бизнес-процессы. Основные понятия. Теория. Методы. Весть - МетаТехнология, 1999. 152 с.
11. Кобзарь М., Сидак А. Стандартизация безопасности ИТ. Мир Связи. - № 3, 2003. сс.7-16.
12. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. - CIT Forum, 1997. -http://citforum.ru/go/iframe/citforum_left.html?/database/case/index.shtml
