CC BY
92
3
ТЕОРИЯ И ТЕХНОЛОГИЯ ПРОГРАММИРОВАНИЯ И ЗАЩИТЫ _ИНФОРМАЦИИ
МОДЕЛИ УГРОЗЫ В МЕТОДОЛОГИИ ОБЩИХ КРИТЕРИЕВ
А.В. Любимов
Исследуется возможность структурного моделирования методологии оценки безопасности информационных технологий, основанной на международном стандарте ИСО/МЭК 15408 "Критерии оценки безопасности информационных технологий" (Общие Критерии). В работе построены три UML модели: модель общего контекста безопасности, модель угрозы и модель контекста угрозы и приведены примеры их применения.
1. Введение
1.1. Предмет и цели исследования
Предметом исследования в данной работе является методология оценки безопасности информационных технологий, основанная на международном стандарте ИСО/МЭК 15408 «Критерии оценки безопасности информационных технологий» (исторически сложившееся международное название - «Общие Критерии») [1]. Основным содержанием «Общих критериев» (ОК) является изложение единого подхода к оценке безопасности продуктов и систем информационных технологий (ИТ), лежащего в основе унификации и взаимного признания национальных стандартов в области безопасности. Кроме того, ОК представляют собой также средство регламентации всей деятельности по оцениванию безопасности ИТ, которая содержится в «Общей методологии оценки» (ОМО) [2] - нормативном документе, сопровождающим ОК.
Под методологией ОК далее понимается совокупность понятий, методов, средств и функций обеспечения безопасности продуктов и систем ИТ, объединенных рамками упомянутого единого подхода и изложенных в ОК, ОМО и в других нормативно-методических документах, посвященных оцениванию изделий ИТ по ОК [3] и т. д. В зарубежных источниках эту совокупности иногда называют «парадигмой ОК» [4].
Основной перспективной целью исследования является построение системы согласованных формальных моделей методологии ОК, позволяющих эффективно осваивать, сопровождать и поддерживать стандарт на практике. При этом в качестве первоочередной выделяется задача построения структурной модели угрозы информационной безопасности как ключевого компонента методологии ОК. Решение этой задачи представлено в работе в виде трех моделей на языке UML.
1.2. Актуальность исследования
Методология ОК основывается на неформальной базовой модели угроз безопасности ИТ, которая применима к любым задачам обеспечения безопасности ИТ. В ОК эта модель не имеет явного описания, ее элементы рассредоточены по тексту стандарта, который, вместе с сопутствующей нормативно-методической документацией, составляет около двух тысяч страниц. При этом значительная часть русскоязычной методической документации находится в стадии разработки [5]. В то же время в [6] справедливо отмечается, что существующие на русском языке пояснения к стандарту весьма скупы. Таким образом, представление базовой модели в интегральной структурированной форме (т.е. в виде формальной модели) является совершенно необходимым условием как для продвижения стандарта, так и для его эффективного применения.
Поскольку понятие угрозы безопасности ИТ неразрывно связано с другими базовыми понятиями методологии ОК, такими как нарушитель, уязвимость, актив, контрмера и т.д., построение базовой модели угрозы невозможно без построения хотя бы элементарных моделей перечисленных понятий и их связей. Эта объемлющая модель далее будет называться моделью контекста угрозы.
Другой, не менее важной, мотивацией построения формальной модели методологии ОК является необходимость разработки средств и методов оперативной актуализации вносимых в стандарт изменений и дополнений, которые при переходе к новым версиям могут быть существенными.
Необходимость разработки структурных моделей методологии ОК в целом либо некоторых ее составляющих неоднократно отмечалась ведущими специалистами в области безопасности ИТ [7], однако до настоящего момента результаты этих работ в отечественной открытой печати не опубликованы.
В зарубежных публикациях этот предмет также практически не затрагивается. Из близких по тематике можно отметить лишь цикл работ Jurjens и др. по языку UMLSec и его применениям [8-10]. Этот язык является стандартным расширением UML, предназначенным для проектирования и разработки безопасных ИС, и включает в себя средства представления проектных и функциональных спецификаций по безопасности, средства тестирования этих спецификаций по безопасности и т. д. Поскольку уровень абстракции UMLSec ниже, чем в рассматриваемой задаче, использовать эти результаты напрямую не представляется возможным, и речь может идти только о согласованности.
2. Структурная модель угрозы и ее контекста
Для построения полной, непротиворечивой и адекватной структурной модели угрозы необходимо описать ее контекст, причем удобно иметь описание контекста в той же форме, что и описание компонентов, т.е. в форме структурной модели. В части 1 ОК представлено описание общего контекста безопасности (ОКБ), которое целесообразно принять за основу при построениии структурной модели контекста угрозы.
При моделировании методологии ОК в целом была выбрана следующая последовательность действий. По приведенному в части 1 ОК описанию ОКБ строится начальная структурная модель ОКБ. С ее учетом путем анализа всего корпуса нормативно-методической документации и существующих практик оценивания по ОК строится структурная модель угрозы. Далее строится структурная модель контекста угрозы, которая затем согласуется со структурной моделью ОКБ и присоединяется к ней. По уточненной структурной модели ОКБ могут быть построены, по аналогии с угрозой, структурные модели других компонентов ОКБ - уязвимости, контрмеры, агента угрозы, актива и владельца. Присоединение каждой из упомянутых моделей сопровождается очередным уточнением структурной модели ОКБ. Полученная в итоге интегральная модель представляет собой структурную модель методологии ОК.
2.1. ОКБ и его структурная модель
Описание ОКБ представлено в разделе 4.1.1 части 1 стандарта в виде вербальной модели с графическими и текстовыми комментариями. Каждый ее компонент является прототипом класса структурной модели, а каждая связь - прототипом отношения между классами. По этим компонентам, в соответствии с парадигмой объектного моделирования, были построены 7 протоклассов и 14 связывающих их отношений. В ходе анализа уточнялись имена и определения протоклассов, формировались их возможные роли, обязанности (протоотношения) и атрибуты. Затем обязанности были преобразованы в отношения с уточнением для каждого отношения его имени, стандартного типа,
направления, множественности, набора ролей и с фиксацией возможных преобразований типа.
В результате была построена начальная структурная модель ОКБ, семантика которой (определения, атрибуты и роли классов и отношений) затем уточнялась путем подробного анализа основных документов ОК. Диаграмма классов уточненной структурной модели ОКБ представлена на рис. 1. В результате анализа классы на уточненной диаграмме также становятся атрибутированными (на рисунке атрибуты скрыты для уменьшения размера).
cd General Security Context
Рис. 1. Диаграмма классов уточненной структурной модели ОКБ
В процессе построения и анализа модели ОКБ становится очевидным, что в методологии ОК существуют структурные и функциональные связи как непосредственно между компонентами угрозы, так и между этими компонентами и другими классами. Таким образом, угроза имеет самостоятельный контекст, который должен моделироваться независимо.
В построенной модели ОКБ структурные связи между классами представлены ассоциациями, которые являются слишком обобщенными и потому малоинформативными отношениями. Для построения реально применимой модели следует провести детализацию классов модели путем выделения их составляющих и характеристик, что позволит также конкретизировать и отношения. Для этого необходимо, в первую очередь, уточнить (представить в виде агрегации составляющих) класс Угроза, который является ключевым в методологии ОК. В итоговой модели этот класс (посредством своих составляющих) должен являться связующим между базовыми (Владелец, Актив, Агент угрозы) и производными
(Уязвимость, Контрмера, Риск) классами. Например, риски определяются в результате анализа угроз и сопоставления их активам, а применяемые контрмеры выбираются по результатам анализа рисков и уязвимостей. Для представления уточненных классов используются отдельные дополнительные диаграммы. Благодаря детализации классов отношения уточняются до уровня агрегаций (композиций) или, по крайней мере, зависимостей.
2.2. Структурная модель угрозы
Для построения структурной модели угрозы необходимо, в первую очередь, дать определение этого класса, а затем выделить его составляющие (подклассы) и определить связывающие их отношения.
Из анализа нормативно методической документации и практики применения ОК следует, что содержательно в методологии ОК описание угрозы представляет собой описание совокупности: актив - агент угрозы - вид нарушения безопасности - метод нападения - уязвимость - квалификация угрозы. Таким образом, структура угрозы, фактически реализованная в методологии ОК, включают четыре компонента, которые являются непосредственными подклассами класса угрозы. Некоторые из них связанны с классом угрозы простым отношением агрегирования (раг^о^, другие - отношением композиции (сильного агрегирования - сотровке^!}.
Структурная модель комплексной угрозы представлена на рис. 2.
Метка_угрозы
Спецификация_актива 1 1
Угроза
Имя_агента
1 1
Спецификация_агента
$ С (> Г
Компетентность
Возможности
Ресурсы
Мотивация_П ричина
Спецификация_НБ
Квалификация_угрозы
Оценка_активизации
Оценка_успеха
Специфижация_нападения
Характеристика_НБ Спецификация_метода Спецификация_уязвимости
Оценка_ущерба
1
Рис. 2. Структурная модель угрозы
В представленной модели класс Угроза (Threat) определяется как «квалифицированная совокупная спецификация угрожаемых активов, предполагаемых нападений на эти активы и агентов этих нападений». Семантика подклассов Угрозы, в общих чертах ясна из их имен (в модели, естественно, присутствуют их строгие определения). Определения классов, с которыми они имеют связи, приводятся в следующем разделе.
2.3. Структурная модель контекста угрозы 2.3.1. Группы классов контекста угрозы
Классы контекста модели угрозы можно разделить на три группы.
1) Непосредственные подклассы класса Угроза, отсутствующие в модели ОКБ. В контекстной модели угрозы можно опустить (как чисто внутренние) некоторые классы и подклассы этой группы, а именно: класс Метка_угрозы, все подклассы класса Специ-фикация_агента (Компетентность, Возможности, Ресурсы, Мотивация_Причина), подкласс Характеристика_НБ класса Спецификация_нападения, а также класс Квалифика-ция_угрозы - как опциональный.
2) Базовые классы модели ОКБ, которые связаны с подклассами класса Угроза либо непосредственно (например, класс Уязвимость), либо через свои подклассы (классы Актив, Агент угрозы). Подклассы этих классов являются расширениями модели ОКБ и вводятся для придания более строгой семантики связям между ее базовыми классами и классом Угроза.
3) Классы, которые отсутствуют в начальной модели ОКБ, но которые были выделены как независимые сущности при анализе понятий, связанных с классом Угроза. К таким классам относятся, в частности, классы Нарушение_безопасности и Ме-тод_нападения.
2.3.2. Базовые классы модели ОКБ, связанные с классом Угроза
Актив - информация или ресурс, который должен быть защищен средствами ИС.
Угрожаемый_актив - конкретная форма представления актива или множества активов, в отношении которой может произойти конкретное нарушение безопасности Например, «данные пользователя, передаваемые по сети» есть часть актива «данные пользователя», передаваемая по сети в конкретный момент времени. Угрожаемый актив связан с активом отношением обобщения-конкретизации.
Частная структурная модель актива, связывающая этот класс с единственным пока подклассом Угрожаемый_актив, является компонентом интегральной структурной модели контекста угрозы.
Агент_угрозы - лицо, группа, организация или фактор, стремящийся, имеющий возможность или способный нарушить безопасность (скомпрометировать активы, нанести ущерб активам или злоупотребить активами).
Класс Агент_угрозы связан с подклассом Имя_агента класса Угроза через подклассы Нарушитель и Фактор_угрозы, которые отсутствуют в ОКБ и были выделены при анализе.
Нарушитель - персонифицированный агент угрозы (лицо или организация), наделенный ролью в среде ИС (уполномоченный пользователь, сотрудник организации, постороннее лицо и пр.).
Фактор угрозы - неперсонифицированный агент угрозы, атрибутированный характеристикой (ошибка персонала, отказ программного обеспечения, отказ аппаратных средств, отказ источников питания и пр.).
Частная структурная модель агента угрозы с подклассами Нарушитель и Фак-тор_угрозы является компонентом интегральной структурной модели контекста угрозы.
Уязвимость - ошибка, недоработка или слабость в проекте, реализации, управлении или функционировании ИС, которая потенциально может быть использована для нарушения безопасности в некоторой среде.
2.3.3. Классы расширения модели ОКБ
Нарушение_безопасности (НБ) - действие или событие, которое не соответствует политике безопасности ИС или в каком-либо смысле нарушает ее (т. е. любое воздействие на какой-либо актив ИС или использование актива, нарушающее сам актив,
его целостность или доступность, либо противоречащее интересам его владельца, либо понижающее его ценность для владельца).
Подклассы класса Нарушение_безопасности, связанные со своими родителями отношением обобщения-конкретизации, представляют собой базовые типы НБ. Они, как и сам класс НБ, также определяются путем анализа практики и нормативно-методических документов, в результате которого выделены следующие подклассы: Компрометация актива:
• нарушение конфиденциальности - несанкционированное раскрытие актива;
• нарушение целостности - несанкционированная модификация актива;
• нарушение доступности - несанкционированное лишение доступа к активу.
Злоупотребление активом - любое использование актива, противоречащее интересам его владельца.
Нанесение ущерба активу - любое воздействие на актив, понижающее его ценность для владельца. Нанесение ущерба есть злоупотребление, но не наоборот.
Частная структурная модель нарушения безопасности является составляющей интегральной структурной модели контекста угрозы.
Метод_нападения - процедура, выполняемая или потенциально выполнимая по отношению к ИС, которая в случае успеха приносит выгоду агенту угрозы либо наносит ущерб ИС, организации-пользователю, ее целям или персоналу.
2.3.4. Интегральная структурная модель контекста угрозы
cd Threat context
Г7"
Name: Threat context
Package: Logical Model
Version: 1.0
Author: Alexander Lyubimov
Актив
Угрожаемый_актив
„„ссылается на Спецификация актива
..* 1
Угроза
1l
Агент_угрозы Нарушитель
Спецификация_агента
ссылается на
И
{XOR}
ссылается на
Имя агента
Агент_угрозы Фактор_угрозы
Характеристика: char
Спецификация_напад ения
Нанесение ущерба
Нарушерие_безопасрости Злоупотребление
Компрометация Нарушение_конфид енциальности
Спецификация_НБ
Компрометация Нарушение_целостности
{XOR}
Спецификация_метода
ссылается на
Компрометация Нарушение_д оступности
Метод _нападения
Квалификация_угрозы
"О Ç О"
Оценка_активизации
Оценка_успеха
Оценка_ущерба
Спецификация_уязвимости
ссылается на
Уязвимость
1 1
Рис. 3. Интегральная структурная модель контекста угрозы
Интегральная структурная модель контекста угрозы представляется диаграммой классов (рис. 3), в которую включаются все классы трех групп, описанные в предыдущих подразделах. Тот факт, что один класс модели ссылается на другой, на диаграмме отображается отношением зависимости (использования).
Полная интегральная модель контекста угрозы содержит 32 класса и 45 связей, которые сведены в 5 диаграмм.
3. Примеры применения модели
1. Выявленная и отраженная в моделях структура угрозы позволяет легко проводить проверку полноты и непротиворечивости представления угроз в профилях защиты и заданиях по безопасности как в уже спроектированных (например, в [11-14]), так и в перспективных, а также согласованность с представлением других компонентов свидетельств оценки.
2. В практике оценки и сертификации продуктов и систем ИТ используются две разновидности угроз - элементарная и комплексная. В элементарной угрозе каждая компонента представлена в единственном экземпляре. Комплексная угроза является кластеризацией совокупности элементарных угроз, которые имеют один или несколько совпадающих компонентов, но различаются одним или несколькими другими.
Представленные модели являются инструментом разработчика и оценщика, позволяющим корректно формировать комплексные угрозы из элементарных. Примеры:
Угроза 1. Нарушитель может получить неуполномоченный доступ к конфиденциальной информации либо ресурсам ограниченного использования, выдав себя за уполномоченного пользователя ОО.
Угроза 2. Уполномоченный пользователь ОО может получить доступ к конфиденциальной информации или ресурсам ограниченного использования, выдав себя за другого уполномоченного пользователя ОО.
TE.CR.ASH. Ошибка человека, отказ программного обеспечения, аппаратных средств или источников питания могут вызвать внезапное прерывание в работе ОО, приводящее к потере или искажению критичных по безопасности данных.
T.INTEGRITY. Целостность информации может быть поставлена под угрозу из-за ошибки пользователя, аппаратных ошибок или ошибок при передаче.
T.SERVICE_DEFECT. Нарушитель из враждебной (внешней) сети может использовать недостатки реализации сервисов для того, чтобы получить доступ к хостам (узлам частной сети) или другим сервисам.
4. Заключение
Полученные структурные модели методологии оценки безопасности информационных технологий по ОК дают сжатое, наглядное и формализованное представление содержания и связи основных понятий безопасности ИТ и могут быть использованы: для обучения специалистов; для унификации и проверки соответствия представления компонентов ОКБ в нормативно-методических документах; при конкретизации стандартов в методиках (например, с целью учета национальной специфики); для согласования международных, национальных и корпоративных стандартов безопасности ИТ, а также при разработке ПО поддержки процесса оценки безопасности ИТ по ОК.
Литература
1. ГОСТ Р ИСО/МЭК 15408-2002. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Госстандарт России, Москва, 2002.
2. РД Безопасность информационных технологий. Общая методология оценки безопасности информационных технологий (проект). ФСТЭК России, 2005.
3. РД Руководство по разработке профилей защиты и заданий по безопасности. Гостехкомиссия России, 2003.
4. Towns M. L. Common Criteria Paradigm (CC) / nnual Computer Security Applications Conference, Sheraton New Orleans, Louisiana, USA, December 11 - 15, 2000.
5. Калайда И. А., Трубачев А.П. Современное состояние и направления совершенствования нормативной базы в области IT-безопасности. // ormation Security/Информационная безопасность. 2004. №3.
6. Просяников Р.Е., Савельев М.С. Станут ли общими "Общие критерии". // BYTE. 2004. № 8.
7. Бетелин В.В., Галатенко В.А., Кобзарь М.Т., Сидак А.А., Трифаленков И.А. Профили защиты на основе «Общих критериев». // Аналитический обзор. Jet Info, Информационный бюллетень. 2003. №3(118).
8. J. Jurjens. Towards development of secure systems using UMLsec. In H. Hubmann, editor, Fundamental Approaches to Software Engineering (FASE/ETAPS, International Conference), volume 2029 of LNCS, pp. 187-200. Springer-Verlag, 2001.
9. J. Jurjens, UMLsec: Extending UML for Secure Systems Development, UML 2002, Dresden, Sept. 30 . Oct. 4, 2002, LNCS, © Springer-Verlag.
10. J. Jurjens, E. B. Fernandez, R. B. France, and B. Rumpe editors. Critical systems development with UML (CSDUML 2004). TU Munchen Technical Report, 2004. UML 2004 satellite workshop proceedings.
11. РД Безопасность информационных технологий. Межсетевые экраны корпоративного уровня. Профиль защиты (первая редакция). Центр безопасности информации, 2002.
12. РД Безопасность информационных технологий. Межсетевые экраны провайдерского уровня. Профиль защиты (первая редакция). Центр безопасности информации, 2002.
13. РД Безопасность информационных технологий. Операционные системы. Базовый профиль защиты (проект). Центр безопасности информации, 2002.
14. РД Безопасность информационных технологий. Система управления базой данных. Профиль защиты (первая редакция). Центр безопасности информации, 2002.
