Содержание к диссертации
Введение
Постановка задачи моделирования методологии общих критериев .
Методология Общих Критериев как объект моделирования.
Актуальность формального моделирования методологии ОК,
Задача структурного моделирования методологии ОК
Задача функционального моделирования методологии ОК.
Задача математического моделирования методологии ОК.
Заключение по главе 1. 33
Формальные модели защищенности в методологии общих критериев .
Структурное моделирование защищенности ИТ. 35
Общий контекст безопасности и его структурная модель , 35
Структурная модель угрозы, 38
Структурная модель контекста угрозы 41
1. Группы классов контекста угрозы, 41
2. Базовые классы модели ОКБ, связанные с классом Угроза. 42
3. Классы расширения модели ОКБ. 46
4. Интегральная структурная модель контекста угрозы. 49
Функциональное моделирование деятельности по оценке защищенности ИТ.
2.2 Л. Контекст модели и нотация. 50
2.2.2, Свойства модели, 54
2.2.3, Описание модели. 56
2.3, Математическое моделирование экономических 58
аспектов защищенности ИТ,
2.3.1, Функция защищенности ИТ, 59
j л 2 Косвенная полезность набора ФБО, 61
2.3.3 23.4
Функция замещения. 63
Уравнение выбора, 64
2,3,5. Перекрестный эффект замены, 67
2.4. Заключение по главе 2, 70
3, Применение формальных моделей в системе оценки и сертификации .
ЗЛ. Применение структурных моделей угрозы и ОКБ. 71
ЗЛ Л, Представление комплексных угроз вПЗ и ЗБ. 71
3.1.2, Представление компонентов ОКБ. 74
ЗЛ.З, Конкретизация стандарта в нормативно-методических документах
3.2. Методика построения функциональной модели, 76
5.1.1, Детализация процессов,
3,2ЛЛ. Общие методы детализации и правила именования процессов для классов и семейств доверия.
3.2,1 -2. Моделирование действий на стороне разработчика. Иерархичность и усиление компонентов. Именование и специфицирование процессов для компонентов и элементов доверия.
3,2.2. Детализация ресурсов. 85
3.2.2.1. Общие правила и приемы. 85
3.2,2.2* Детализация входных ресурсов. 87
3.2.2.3. Детализация выходных и внутренних ресурсов 91
3-3, Реализация и применение функциональной модели. 108
3.3.1, Программно-инструментальный комплекс поддержки модели
3.3.2. Методика использования функциональной модели и комплекса поддержки
3.3.2.1. Подготовка, согласование и контроль конфигурации свидетельств оценки
3.3.2.2, Бизнес- планирование работ по оценке и согласование ОУД
3.4. Заключение по главе 3 125
Заключение 127
Литература
- Задача структурного моделирования методологии ОК
- Общий контекст безопасности и его структурная модель
- Конкретизация стандарта в нормативно-методических документах
- Подготовка, согласование и контроль конфигурации свидетельств оценки
Введение к работе
Актуальность темы
Стандарт ГОСТ Р ИСО/МЭК 15408 "Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий" (краткое название - "Общие критерии", сокращенно - ОК) начал действовать в России с 1 января 2004 г.
В силу особенностей построения ОК представляют собой базовый стандарт, содержащий методологию задания требований и оценки безопасности ИТ, а также систематизированный каталог требований безопасности. В качестве функциональных стандартов, в которых формулируются требования к безопасности определенных типов продуктов и систем ИТ, предусматривается использование профилей защиты, создаваемых по методологии ОК и на основе каталога требований. В ПЗ могут быть включены и любые другие требования, которые являются необходимыми для обеспечения безопасности конкретного типа продуктов или систем ИТ.
Изложенная в ОК методология формирования требований и универсальный каталог требований безопасности (функциональных и доверия) позволяют формировать на основе указанного каталога наборы требований (профили защиты, задания по безопасности и пакеты) для различных типов продуктов и систем информационных технологий (ИТ). Продукты и системы ИТ вместе с документацией определены в ОК как объекты оценки (00). Несмотря на то, что ОК направлены на оценку продуктов и систем ИТ и в документе содержится метдология оценки, они включают не только методологию формирования требований для оценки, но и методологию формирования требований к разработчику по организации процесса разработки, по предоставлению материалов, необходимых для проведения оценки, а также возлагают другие обязанности разработчика в процессе проведения оценки [33],
Таким образом, применение методологии ОК способствует существенному повышению качества как оценки, так и разработки продуктов и систем ИТ, о чем свидетельствует как шестилетний опыт их использования в мире, так и небольшой опыт, полученный при апробации "Общих критериев" в России.
Внедрение OK в России спланировано поэтапно. До 2007 г. организации, в информационных системах которых циркулирует конфиденциальная информация, могут самостоятельно выбирать по каким стандартам (старым или новым) проводить аттестацию. Однако, поскольку внедрение нового ГОСТ является частью правительственной проіраммьі по вступлению России в ВТО (что предполагает, в частности, унификацию некоторых стандартов в области информационной безопасности), в недалеком будущем становится неизбежной масштабная деятельность по оцениванию и сертификации продуктов ИТ по стандарт}' ОК [12]. По этой причине уже сейчас существует необходимость подготовки значительного числа специалистов по ОК как для центров оценки и сертификации, так и для фирм-разработчиков, фирм-поставщиков и организаций-пользователей.
Собственно методология ОК в стандарте не имеет явного описания, се элементы рассредоточены по тексту, который, вместе с сопутствующей нормативно-методической документацией, составляет около двух тысяч страниц. При этом значительная часть русскоязычной методической документации находится в стадии разработки [9] или причислена к know-how и потому является недоступной.
Объемы работ по оценке и сертификации ИТ, выполняемые в настоящее время за рубежом и планируемые в России, с неизбежностью приводят к необходимости использования инструментальных программных средств поддержки деятельности по подготовке и проведению оценок. Современные методы разработки подобных средств предполагают широкое применение формальных моделей предметной области, по крайней мере, на стадиях специфицирования и высокоуровневого проектирования.
Решение перечисленных задач, как и многих других, связанных с внедрением ОК в России представляется трудновыполнимым без представления базовых концепций методологии ОК и их взаимосвязей в интегральной структурированной форме, то есть в виде формальных моделей. Разработка системы таких моделей является совершенно необходимым условием, как для продвижения стандарта, так и для его эффективного применения.
7 Цели и задачи диссертации
Целью работы является поддерхїка продвижения, внедрения и эффективного применения "Общих Критериев" в России. С этой целью в диссертационной работе решаются задачи построения системы формальных моделей методологаи OK, а также задачи разработки методов и средств их построения, реализации и применения в системе оценки и сертификации продуктов и систем ИТ.
Объект исследования
Объектом исследования в данной работе является единая методология задания требований и оценки безопасности ИТ как совокупность понятий, методов, средств, функций и процессов обеспечения и оценки безопасности продуктов и систем ИТ, изложенных в Общих Критериях и в сопровождающих их нормативно-методических документах системы оценки и сертификации.
Предметом исследования в работе являются структурные, функциональные и математические модели защищенности информационных технологий, описывающие базовые концепции методологии ОК и их взаимосвязи, а также процессы деятельности разработчиков, оценщиков и владельцев ИТ, связанные с оценкой безопасности по ОК.
Методы исследования
При решении поставленных задач использовались методы искусственного интеллекта, методы объектного, функционального и информационного моделирования, математические методы оптимизации, математические методы микроэкономики.
Основные научные положения, выносимые на защиту
1. Система струюурных моделей основных компонентов защищенности ИТ по методологии Общих Критериев, включающая;
структурную модель угрозы;
структурную модель общего контекста безопасности;
интегральную структурную модель контекста угрозы.
Полная функциональная модель деятельности по оценке защищенности ИТ в соответствии с методологией ОК, детализированная до уровня элементов действий оценщика и разработчика.
Методика построения функциональной модели деятельности оценщика и разработчика по оценке защищенности ИТ, учитывающая специфику ОК как объекта моделирования и предметной области в целом.
Основные результаты работы
1. Построена система структурных моделей основных компонентов
защищенности ИТ по методологии Общих Критериев, включающая:
структурную модель угрозы;
структурную модель общего контекста безопасности;
интегральную структурную модель контекста угрозы.
2. Построена полная функциональная модель деятельности по оценке
защищенности ИТ в соответствии с методологией ОК, детализированная до уровня
элементов действий оценщика и разработчика.
Разработана методика построения функциональной модели деятельности оценщика и разработчика по оценке защищенности ИТ, учитывающая специфику ОК как объекта моделирования и предметной области в целом.
Построена математическая модель, описывающая экономические аспекты выбора владельцем ИТ набора функций безопасности, который обеспечивает заданный уровень защищенности по ОК.
Предложены методы применения системы структурных моделей основных компонентов защищенности ИТ по методологии ОК для решения разнообразных практических задач, возникающих в системе оценки и сертификации ИТ,
Разработан программно-инструментальный комплекс поддержки функциональной модели деятельности по оценке защищенности ИТ.
Разработана методика использования функциональной модели деятельности по оценке защищенности ИТ и программно-инструментального комплекса ее поддержки для решения практических задач подготовки, согласования и контроля конфигурации свидетельств оценки, а также для бизнес-планирования работ по оценке и согласования ОУД.
9 Научная новизна
Научная новизна результатов работы обусловлена следующими факторами.
Определение содержания понятия "методология Общих Критериев" и его трактовка в качестве объекта исследования.
Использование в применении к методологии ОК методов структурного, функционального и информационного моделирования.
Коррекция стандартов разработки структурных и функциональных моделей с учетом специфики методологии ОК как объекта моделирования.
Практическая ценность результатов
Построенные в работе формальные модели защищенности ИТ являются необходимой базой разработки функциональных и проектных спецификаций для программного обеспечения поддержки процесса оценки ИТ по ОК.
С помощью разработанной в диссертации методики и программно-инструментального комплекса поддержки функциональная модель деятельности по оценке защищегшости ИТ может использоваться для решения широкого спектра практических задач, возникающих при подготовке и проведении оценки, примеры такого использования непосредственно приводятся в работе. В совокупности функциональная модель и программно-инструментальный комплекс представляют собой также учебно-справочную систему по ОК.
Материалы диссертации могут быть использованы при разработке методических материалов для учебного процесса в вузах, осуществляющих подготовку специалистов по информационной безопасности, а также в системе повышения квалификации сотрудников испытательных лабораторий, центров сертификации, фирм-разработчиков и организаций-пользователей.
Область применения результатов
Помимо приведенных выше областей практической деятельности, построенные в работе формальные модели защищенности ИТ могут использоваться при разработке семейств профилей защиты и заданий по безопасности конкретных ИТ. Важную, как в теоретическом, так и в практическом отношении, область приложений полученных результатов составляет решение
10 задач согласоваттия международных, национальных и корпоративных стандартов в области информационной безопасности, в частности - интеграция государственных стандартов РФ в систему оценки и сертификации по ОК.
Апробация работы
Основные положения и результаты диссертационной работы докладывались и
обсуждались на III межвузовской конференции молодых ученных (10-13 апреля
2006г., г. Санкт-Петербург), на XXXV научной и учебно-методической
конференции Санкт-Петербургского Государственного университета
информационных технологий, механики и оптики (СІІ6ГУ ИТМО), 31 января - 3 февраля 2006, г. С-Петербург, на IV ежегодной всероссийской конференции "Обеспечение информационной безопасности. Региональные аспекты." - ІЗ - 17 сентября 2005, г. Сочи и па 9-ой научно-технической конференции Майоровские чтения "Теория и технология программирования и зашиты информации. Применение вычислительной техники" ( 18 мая 2005г., г. Санкт-Петербург).
Внедрение результатов
Результаты работы реализованы в учебном процессе кафедры БИТ СПбГУ ИТМО по специальностям 075300, 075400, и отчетных материалах по НИР и ОКР. (ЗАО «Эврика», Санкт-Петербург).
Структура и объем диссертации
Диссертация состоит из введения, трех глав, заключения и списка литературы. Материал изложен на 133 страницах машинописного текста, содержит 25 рисунков и 10 таблиц, список литературы состоит из 51 наименования.
В первой главе представлена постановка задачи моделирования методологии Общих Критериев,
В первом разделе первой главы проанализировано содержание, назначение и взаимосвязь основных документов, используемых при оценке информационных технологий по Общим Критериям и рассмотрены варианты их использования в системе оценки и сертификации. Здесь же дано определение содержания понятия
"методология OK" и приведен его генезис. Обоснована возможность применения к методологии ОК методов научного анализа и в первую очередь - методов построения формальных моделей. В конце раздела предложен состав и определено назначение системы формальных моделей методологии ОК, развиваемой далее в работе.
Во втором разделе дан краткий обзор актуальных практических задач, решаемых заинтересованными сторонами в системе оценки и сертификации, и обоснована необходимость формального моделирования методологии ОК для их успешного решения.
В третьем разделе обоснована необходимость и актуальность построения структурных моделей методологии ОК в целом и ее компонентов и дан обзор существующих работ по этой тематике. Здесь же поставлена задача построения структурных моделей защищенности ИТ как важнейшего аспекта методологии ОК, а также сформулированы основные проблемы, порожденные спецификой предметной области, которые возникают в процессе построения этих моделей. Далее сформулирован набор требований к методике структурного моделирования, проведен сравнительный анализ методик и решена задача выбора основных компонентов методики - метода и языка. В результате в качестве методики структурного моделирования выбирается OMG UML І.4 / 2.0.
В четвертом разделе рассмотрен спектр практических задач, возникающих в деятельности заявителя, оценщика и разработчика ИТ, для реитения которых могут и должны применяться функциональные модели методологии ОК, и обоснован выбор методики SADT и метода DFD в качестве инструментов функционального моделирования. Далее очерчены основные проблемы, возникающие в процессе построения функциональных моделей и обусловленные спецификой предметной области- В конце раздела дан обзор отечественных и зарубежных источников, посвященных задачам функционального моделирования методологии ОК, и проведен их сравнительный анализ, на основе которого сформирована область моделирования и определены необходимые основные свойства результирующей функциональной модели.
В пятом разделе обоснована актуальность исследования экономических аспектов безопасности ИТ в рамках методологии ОК с использованием
12 сформированных в OK и в ОМО функциональных требований безопасности ИТ в качестве критериев (показателей) защищенности. Здесь же дана содержательная постановка задачи управления уровнем защищенности ИС с учетом предпочтений потребителя или владельца ИС в аспекте безопасности, рыночной стоимости реализации того или иного компонента защиты, а также бюджетных ограничений на стоимость защиты в целом. В конце раздела отмечена аналогия поставленной задачи с задачей потребительского выбора в микроэкономике.
Во второй главе представлены формальные модели защищенности в методологии Общих Критериев, как решение поставленной в первой главе задачи.
В первом разделе второй главы задача структурного моделирования защищенности ИТ раскрыта как задача построения системы струюурных моделей основных компонентов методологии ОКэ приведен возможный спектр моделей, входящих в систему, обоснован минимальный набор из трех моделей (структурная модель общего контекста безопасности, струюурпая модель угрозы, структурная модель контекста угрозы) и сформулирован порядок их построения, согласования, уточнения и пополнения. Далее по приведенному в ОК описанию общего контекста безопасности (ОКБ) ИТ построена его структурная модель и описаны методы ее уточнения и пополнения. Затем проанализировано содержание понятия угрозы, предполагаемое методологией ОК, и по результатам анализа построена структурная модель угрозы. В конце раздела проведен анализ контекста, в котором понятие угрозы используется в методологии ОК, и построена его интегральная струюурпая модель. Структурная модель угрозы, структурная модель общего контекста безопасности ИТ и интегральная структурная модель контекста угрозы в совокупности составляют систему структурных моделей основных компонентов защищенности ИТ по методологии ОК - первое положение, выносимое на защиту.
Во втором разделе построен контекст решения задачи функционального моделирования и сформулированы основные свойства модели: цель и точка зрения моделирования, содержание (определение) модели и границы моделирования. Далее представлена функциональная модель деятельности по оценке защищенности ИТ в соответствии с методологией ОК - второе положение, выносимое на защиту. Приведено описание функциональной модели как иерархии DFD диаграмм, описывающих потоки данных между процессами, а также краткое
ІЗ описание методики ее построения. Более детально методика изложена во втором разделе третьей главы.
В третьем разделе представлена математическая модель, описывающая поведение владельца ИС при изменении цеп на услуги обеспечения безопасности, т.е. цен на реализацию ФБО, и при изменении бюджета безопасности, находящегося в распоряжении владельца,
В третьей главе рассмотрены вопросы применения представленных во второй главе формальных моделей для решения задач, возникающих в ходе оценки и сертификации ИТ.
В первом разделе третьей главы описано применение построенной системы структурных моделей основных компонентов защищенности ИТ по методологии ОК для решения разнообразных практических задач, возникающих в системе оценки и сертификации ИТ:
продемонстрировано использование структурной модели угрозы для проверки полноты и непротиворечивости представления угроз в профилях защиты (ПЗ) и заданиях по безопасности (ЗБ) и для корректного формирования комплексных угроз из элементарных в ходе разработки и оценивания ПЗ и ЗБ;
приведены примеры применения структурной модели контекста угрозы для унификации представления компонентов ОКБ в различных документах системы сертификации по ОК, а также для проверки соответствия таких представлений в других стандартах и системах методологии ОК;
Продемонстрировано использование структурной модели ОКБ при разработке нормативного и методического обеспечения реализации ОК, в частности - для разработки структурного представления политики безопасности 00 (ПБО) как необходимого компонента свидетельств оценки.
Во втором разделе рассмотрена специфика объекта моделирования и предметной области в целом и описаны обусловленные этой спецификой коррекгивы, которые необходимо внести в методологию SADT при построении функциональной модели деятельности по оценке защищенности ИТ. Поскольку
14 коррективы являются весьма существенными, полученная в результате методика построения функциональной модели деятельности по опенке защищенности ИТ выносится на защиту как новый и оригинальный результат. В разделе представлены основные составляющие этой методики как в аспекте детализации процессов;
общие методы детализации процессов функциональной модели с учетом специфики объекта моделирования и принятые правила именования процессов для классов и семейств доверия;
метод моделирования действий на стороне разработчика;
применение таблиц разбиения семейств па компоненты и элементы для моделирования объектных иерархий наследования, отражающих усиление компонентов доверия;
* правила именования и специфицирования процессов для компонентов и элементов доверия; так и в аспекте детализации ресурсов:
обратное направление детализации ресурсов по принципу "снизу вверх" для учета объектной иерархичности ресурсов;
применение таблиц разбиения свидетельств оценки семейства по компонентам и элементам при детализации входных ресурсов для элементов компонентов доверия;
специфический и ориентированный на ОМО алгоритм детализации выходных и внутренних ресурсов.
В первой части третьего раздела дано описание программно -инструментального комплекса поддержки функциональной модели деятельности по оценке защищенности ИТ и продемонстрированы возможности его использования как для автоматизации широкого спектра действий по оцениванию, так и в качестве учебно-справочной системы. Во второй части раздела приведена методика использования функциональной модели и программно инструментального комплекса ее поддержки для решения задач, возникающих на тех этапах процесса оценивания, которые не регламентированы стандартами ОК, в частности - для подготовки, согласования и контроля конфигурации свидетельств оценки, а также - для бизнес - планирования работ по оценке и согласования ОУД.
Задача структурного моделирования методологии ОК
Методология Общих Критериев основывается на неформальной базовой концепции угроз безопасности ИТ, которая применима к широкому спектру задач обеспечения безопасности ИТ и является исходным пунктом для формирования других концепций - уязвимости, метода нападения, нарушения безопасности, контрмеры, функции безопасности и пр., а также для представления свидетельств оценки и действий разработчика и оценщика.
В Общих Критериях эти концепции не имеют явного описания, их элементы рассредоточены по тексту стандарта, который, вместе с сопутствующей нормативно-методической документацией, составляег около двух тысяч странии. При этом значительная часть русскоязычной методической документации находится в стадии разработки [9] или причислена к know-how и потому является недоступной. В то же время в [23] справедливо отмечается, что существующие пояснения к стандарту достаточно скупы, а публикации о нем можно найти лить в небольшом числе фирменных журналов (например, Jet Info), которые распространяются весьма ограниченно.
Отсюда следует, что представление базовых концепций методологии ОК и их взаимосвязей в интегральной структурированной форме (т, е. в виде формальных моделей) является совершенно необходимым условием, как для продвижения стандарта так и для его эффективного применения.
Как отмечается в [9], "для деятельности заказчиков, разработчиков, пользователей IT изделий, органов по сертификации и испытательных лабораторий4 большое значение имеет обеспечение возможности оперативного внесения в корпус нормативно - методических документов, описывающих методологию ОК, "текущих изменений, вызванных учетом опыта практического применения и совершенствования критериев оценки ГГ-безопаспости." Решение этой задачи представляется трудновыполнимым без представления хотя бы основных концепции методологии в формализованном виде. Таким образом, второй, не менее важной мотивацией построения формальных моделей методологии ОК, является необходимость разработки средств и методов оперативной актуализации вносимых в стандарт изменений и дополнений, которые при переходе к новым версиям могут быть существенными.
Постановлением Госстандарта России от 4.04.2002 г. № 133-ст новый стандарт РД БИТ (серия руководящих документов по безопасности информационных технологий) вводится в действие с 1 января 2004 г. Внедрение ОК в России спланировано поэтапно. До 2007 г. организации, в информационных системах которых циркулирует конфиденциальная информация, могут самостоятельно выбирать по каким стандартам (старым или тговым) проводить аттестацию. Однако, поскольку внедрение нового ГОСТ является частью правительственной программы по вступлению России в ВТО (что предполагает, в частности, унификацию некоторых стандартов в области информационной безопасности), в недалеком будущем становится неизбежной масштабная деятельность по оцениванию и сертификации продуктов ИТ по стандарту ОК [12]. По этой причине уже сейчас существует необходимость подготовки значительного числа специалистов по ОК как для центров оценки и сертификации, так и для фирм-разработчиков, фирм-поставщиков и организаций-пользователей.
Объемы работ по оценке и сертификации ИТ, выполняемые в настоящее время за рубежом и планируемые в России, с неизбежностью приводят к необходимости использования инструментальных программных средств поддержки деятельности по подготовке и проведению оценок. Современные методы разработки подобных средств предполагают широкое применение формальных моделей предметной области, по крайней мере, на стадиях специфицирования и высокоуровневого проектирования,
Задача структурного моделирования методологии ОК
В настоящей работе термин "структурное моделирование 1 трактуется с точки зрения объектной парадигмы. Под структурной моделью понимается, в первую очередь, модель объектная (классы, отношения, механизмы), дополняемая при необходимости моделями поведения (взаимодействия, прецеденты, процессы). В современной практике формального моделирования построение системы структурных моделей предметной области или системы является необходимым и базовым этапом исследования, предваряющим построение любых других моделей, в частности - функциональных и математических. В первую очередь, структурное моделирование позволяет зафиксировать терминологию предметной области посредством формального описания ее лексики и семантики (например, в виде классов), а также взаимосвязь основных понятий и их составляющих посредством формального описания отношений между классами. Для методологии ОК это имеет особое значение, поскольку, как отмечено выше, в стандарте праісгически отсутствует сколько-нибудь систематизированное изложение основных понятий, а описанию связей между ними отведено две страницы.
Необходимость разработки структурных моделей методологии ОК в целом или некоторых ее составляющих неоднократно отмечалась ведущими специалистами в области безопасности ИТ [3], однако до настоящего момента результаты этих работ в открытой печати не опубликованы. В этих же работах отмечается и основная проблема, возникающая при построении структурных моделей методологии ОК. Она состоит в том, что основные понятия предметной области - функциональные требования безопасности - и их связи описаны в части 2 стандарта ОК [19] в рамках дообъектпой, функциональной (или "библиотечной" -в терминах [3]) парадигмы. Например, стандарт предоставляет параметризованные функциональные требования, но не содержит необходимых с объектной точки зрения комбинаций таких требований или универсальных интерфейсов, допускающих конкретизацию в контексте различных сервисов. Иными словами, функциональные требования не сгруппированы в осмысленные наборы (объектные интерфейсы), к которым могло бы применяться наследование, В такой ситуации разработка объектных моделей требует основательного переосмысления и переструктурирования всего исходного материала, а это (как минимум) 850 страниц нетривиального текста.
Общий контекст безопасности и его структурная модель
Для построения полной, непротиворечивой и адекватной структурной модели защищенности ИТ необходимо, в первую очередь, построить структурную модель угрозы как ключевого компонента безопасности. Для угрозы также необходимо описать ее контекст, который можно определить как "связное целое, в пределах которого наиболее точно выявляется значение составляющих его компонентов". При этом удобно иметь описание контекста в той же форме, что и описание компонентов, то есть, в форме структурной модели.
В части 1 Общих Критериев представлено описание общего контекста безопасности (ОКБ) информационных технологий, которое целесообразно принять за основу при построении структурной модели контекста угрозы.
При моделировании методологии Общих Критериев в целом была выбрана следующая последовательность действий. По приведенному в части 1 ОК описанию ОКБ строится начальная структурная модель ОКБ, С ее учетом путем анализа всего корпуса нормативно-методической документации и существующих практик оценивания по ОК строится структурная модель угрозы. Далее строится структурная модель контекста угрозы, которая затем согласуется со структурной моделью ОКБ и присоединяется к ней. По уточненной структурной модели ОКБ могут быть построены, по аналогии с угрозой, структурные модели других компонентов ОКБ - уязвимости, контрмеры, агента угрозы, актива и владельца. Присоединение каждой из упомяііушх моделей сопровождается очередным уточнением структурной модели ОКБ. Полученная в итоге интегральная модель представляет собой структурную модель защищенности ИТ по методологии Общих Критериев.
Чтобы исключить влияние неточностей перевода, при построении структурной модели контекста угрозы за основу был принят оригинал описания ОКБ (рис. 2.1), представленный в разделе англоязычной версии стандарта [34].
Это описание представляет собой графическую вербальную модель, дополненную текстовыми комментариями. Каждый компонент, изображенный прямоугольником на рисунке, является прототипом класса структурной модели, а каждая стрелка — прототипом отношения между классами. По этим компонентам, в соответствии с парадигмой объектного моделирования [4], были построены 7 протоклассов и 14 связывающих их отношений. В ходе анализа уточнялись имена и определения протоклассов, формировались их возможные роли, обязанности (протоотношения) и атрибуты. Затем обязанности были преобразованы в отношения с уточнением для каждого отношения его имени, стандартного типа, направления, множественности, набора ролей и с фиксацией возможных преобразований типа» В результате была построена структурная модель ОКБ, представленная на рис. 2.2, являющаяся исходной для дальнейшего анализа.
Следующим шагом анализа являлось выделение ролей классов. Для их включения в структуру классов был выбран такой стандартный механизм расширения UML, как ограничение (constraint), который расширяет семантику класса, позволяя добавлять новые или модифицировать существующие правила.
В итоговой модели этот класс (посредством своих составляющих) должен являться связующим между базовыми (Владелец, Актив, Агент угрозы) и производными (Уязвимость, Контрмера, Риск) классами. Например, риски определяются в результате анализа угроз и сопоставления их активам, а применяемые контрмеры выбираются по результатам анализа рисков и уязвимостей. Для представления уточненных классов следует использовать отдельные дополнительные диаграммы. Благодаря детализации классов отношения уточняются до уровня агрегаций (композиций) или, по крайней мерс, зависимостей.
Для построения структурной модели угрозы необходимо, в первую очередь, дать определение этого класса, а затем выделить его составляющие (подклассы) и определить связывающие их отношения.
В основных документах, описывающих методологию ОК [18-20, 21], явное определение понятия угрозы отсутствует, В нормативном документе Гостехкомиссии [24] дается следующее определение: "Угроза - совокупность условий и факторов, определяющих потенциальную или реально существующую опасность возникновения инцидента, который может привести к нанесению ущерба изделию ИТ или его владельцу". Это определение является явно недостаточным по двум причинам. Во-первых, не указан перечень тех условий и факторов, посредством которых должна описываться угроза. Во-вторых, понятие угрозы раскрывается через понятия "инцидент" и "ущерб", которые лежат вне рамок общего контекста безопасности, принятого в методологии ОК. Таким образом, для получения удовлетворительного определения класса "Угроза" необходим дополнительный анализ.
Из анализа нормативно методической документации и практики применения ОК в России следует что содержательно в методологии ОК описание угрозы представляет собой описание совокупности: актив - агент угрозы - вид нарушения безопасности - метод нападения - уязвимость - квалификация угрозы. Элементы этой совокупности как раз и представляют собой те самые "условия и факторы", описания которых не хватает в приведенном выше определении, причем все они входят в ОКБ, за исключением, может быть, квалификации угрозы, которая лежит на его границе.
Таким образом, структура угрозы, фактически реализованная в методологии ОК, содержит четыре содержательных компонента верхнего уровня, которые являются непосредственными подклассами класса угрозы. Некоторые из них связанны с классом угрозы простым отношением агрегирования (part_of), другие -отношением композиции (сильного агрегирования - composite_of).
Примечание. Отличие композита от агрегата состоит в том, например, что его целое связано с частями дополнительным отношением владения (то есть, часть может принадлежать только одному композиту), а так же в том, что "время жизни1 частей и целого совпадают.
Конкретизация стандарта в нормативно-методических документах
Структурная модель контекста угрозы в ОК, приведенная в разделе 2.1,3, позволяет также проводить унификацию представления компонентов ОКБ в различных документах системы сертификации по ОК, а также выполнять проверку соответствия таких представлений в других источниках методологии ОК. Последнее можно проиллюстрировать на следующих примерах.
1. "Угроза - совокупность условий и факторов, определяющих потенциальную или реально существующую опасность возникновения инцидента, который может привести к нанесению ущерба изделию ИТ или его владельцу/ [24]
Такое представление угрозы полностью соответствует методологии ОК, поскольку под условиями и факторами в [24] понимаются; угрожаемый актив, агент угрозы, вид нарушения безопасности, метод нападения и используемая уязвимость, то есть именно те компоненты которые составляют структуру угрозы в методологии ОК (и, конечно, в построенной модели).
2. "Угроза - это потенциально возможное происшествие, неважно, преднамеренное или нет, которое может оказать нежелательное воздействие па саму систему, а также на информацию, хранящуюся в ней. Иначе говоря, угроза это возможное событие, в результате наступления которого возникает какой-либо ущерб, убыток." [16]
Такое представление угрозы дает более узкий взгляд на понятие угрозы, чем это предусмотрено в методологии ОК, вследствие концентрации на самом факте нарушения безопасности (атаки), в ущерб остальным условиям и факторам угрозы,
3. "Угрозой называется событие, которое может вызвать нарушение функционирования автоматизированной информационной системы (АИС), включая, искажение, уничтожение или несанкционированное использование обрабатываемой в ней информации." [22]
Это представление угрозы лишь в небольшой степени соответствует методологии ОК, а именно - в том, что относится к видам нарушения безопасности. В остальном же понятие угрозы явно ограничивается самим фактом нарушения безопасности, оставляя остальные условия и факторы угрозы за рамками рассмотрения.
4. "Угроза - любое лицо, объект или событие, которое, в случае реализации, может потенциально стать причиной нанесения вреда ЛВС. Угрозы могут быть злонамеренными, такими, как умышленная модификация критической информации, или могут быть случайными, такими, как ошибки в вычислениях или случайное удаление файла. Угроза может быть также природным явлением, таким, как наводнение, ураган, молния и т.п. Непосредственный вред, вызванный угрозой, называется воздействием угрозы." [8]
Данное здесь представление понятия угрозы абсолютно не соответствует методологии ОК, поскольку, во-первых, смешивает столь различные факторы угрозы, как агент угрозы, угрожаемый актив и собственно нападение (как событие)., а во-вторых, оставляет за рамками рассмотрения столь важные факторы угрозы, как метод нападения и уязвимость.
Предложенная в разделе 2,1,3 структурная модель ОКБ может использоваться также при разработке нормативного и методического обеспечения реализации ОК,
Например, для оценки по ОУД4 и выше ОК требуют разработки структурного представления политики безопасности 00 (ПБО) как необходимого компонента свидетельств оценки (семейство доверия ADV_SPM - Моделирование политики безопасности), В зависимости от строгости требований к безопасности такое структурное представление может являться неформальным, полуформальным или формальным. Для любого уровня формализации модель ПБО должна содержать описание правил и характеристик всех политик ПБО, которые могут быть смоделированы. Использование структурной модели ОКБ в качестве общей базы для разработки структурной модели ПБО может обеспечить необходимую унификацию и существенно сократить трудозатраты, как на стороне разработчика, так и на стороне оценщика.
В качестве другого примера можно рассмотреть раздел "Идентификация и спецификация угроз" руководства по разработке профилей защиты и заданий по безопасности [24]. В нем приводятся рекомендации по содержанию спецификации угроз и некоторые примеры, но отсутствует структуры представления этого и других компонентов ОКБ, Использование в этом и подобных нормативно-методических документах предложенной структурной модели позволило бы, как и в предыдущем примере, обеспечить согласованность с (Ж, унификацию и сократить трудозатраты на различных стадиях процесса оценивания и сертификации.
Подготовка, согласование и контроль конфигурации свидетельств оценки
Совершенно аналогично изложенному выполняется детализация выходных ресурсов для компонента AVA_VLA.2. Отличие заключается лишь в сложности декомпозиции, возрастающей благодаря наличию усиления компонентов, а также в том, что некоторые выходные ресурсы одних элементов становятся входными ресурсами других, то есть, являются внутренними для диаграммы детализации компонента.
В ОМО компонент AVA_VLA.2 включает пять элементов действий оценщика из часта 3 OK: AVA__VLA.2.1E, AVA_VLA.2.2E, AVA_VLA.23E, AVA_VLA.2,4E, AVA_VLA,Z5E.
В ОМО элемент AVA_VLA.2.1E содержит три шага оценивания. Из подробного описания этих шагов оценивания в ОМО можно заключить, что выходом этого элемента является ресурс с именем "Заключение по свидетельствам (AVA_VLA.2.1E)" и следующим определением: "Заключение, вся ли относящаяся к делу информация рассмотрена при поиске уязвимостей. Заключение, описана ли каждая идентифицированная уязвимость и дано ли обоснование того, почему она является непригодной для использования в предопределенной среде 00. Заключение, согласуются ли материалы анализа уязвимостей с ЗБ и руководствами," Элемент AVA_VLA.2,2E содержит пять шагов оценивания. Его выход - ресурс с именем "Заключение по тестированию идентифицированных уязвимостей (AVA_VLA.2.2E)" и следующим определением: "Заключение, что 00 (в своей предопределенной среде) не имеет пригодных для использования явных уязвимостей.
Информация об усилиях оценщика по тестированию проникновения, в которой кратко изложен подход к тестированию, тестируемая конфигурация, глубина и результаты тестирования, а также вердикт по данному подвиду деятельности и общее решение по результатам тестирования проникновения.Т
Элементу AVA_VLA.2,3E соответствует один шаг оценивания. Его выход - ресурс с именем "Заключение о возможных неучтенных уязвимостях (AVA__VLA.2,3E)" и следующим определением:
"Заключение о возможных уязвимостях безопасности, не учтенных ранее при анализе уязвимостей разработчиком, включая: - упорядоченный по приоритетам перечень потенциальных уязвимостей; - перечень остаточных уязвимостей." Замечание, Составная часть этого ресурса - ресурс "Перечень потенциальных уязвимостей (AVA_VLA.2.3E)" с определением:
"Следует использовать методологию гипотез о недостатках, посредством которой анализируются спецификации и документация 00, а после этого делаются предположения об уязвимостях в 00. Затем перечень предполагаемых уязвимостей упорядочивается по приоритетам на основе оцененной вероятности существования уязвимости и, предполагая, что уязвимость существует, па основе потенциала нападения, требуемого для ее использования, а также возможностей, предоставляющихся нарушителю, или предполагаемого ущерба, который обусловлен конкретной уязвимостью/ является входом процесса "Независимое тестирование проникновения (AVA_VLA.2.4E)"
Элемент AVAVLA.2.4E содержит пять шагов оценивания. Его выход - ресурс с именем "Заключение по независимому тестированию проникновения (AVA_VLA.2.4E)1 и следующим определением:
"Информация об усилиях оценщика по тестированию проникновения, в которой кратко изложен подход к тестированию, тестируемая конфигурация, глубина и результаты тестирования, а также вердикт по данному подвиду деятельности и общий вывод по результатам тестирования проникновения."
Элемент AVAVLA.2.5E содержит два шага оценивания. Его выход - ресурс с именем "Заключение о стойкости 00 для низкого потенциала нападения (AVA_VLA.2.5E)" и следующим определением:
"Заключение, является ли 00, находящийся в своей предопределенной среде, стойким к нарушителю, обладающему низким потенциалом нападения.
Информации обо всех пригодных для использования уязвимостях и остаточных уязвимостях."
Замечание. Как следует из определения, входами для процесса "Оценка стойкости для низкого потенциала нападения (AVA_VLA,2-5E)\ помимо документации разработчика, являются также выходы процессов: "Тестирование проникновения по идентифицированным уязвнмостям (AVA_VLA.2.2E)"; - "Независимый анализ уязвимостей (AVA_VLA.23E)" - "Независимое тестирование проникновения (AVA_VLA.2.4E)"
Пять выходных ресурсов компонентов AVA_VLA.Z1E - AVA_VLA.2.5E объединяются в совокупный ресурс с именем "Заключение по анализу уязвимостей и оценка стойкости для низкого потенциала нападения (AVA_VLA,2)" и определением; "Заключение по свидетельствам (AVA_VLA.2.1E)
Заключение по тестированию идентифицированных уязвимостей (AVA_VLA,2.2E) Заключение о возможных неучтенных уязвимостях (AVAVLA.2.3E) Заключение по независимому тестированию проникновения (AVA_VLA.2.4E) Заключение о стойкости 00 для низкого потенциала нападения (AVAVLA.2.5E)" Этот совокупный ресурс выводится (Arrow Tunnel = Resolve to border Arrow) на внешнюю диаграмму детализации процесса "Оценка анализа уязвимостей (AVA_VLA).
Итоговая диаграмма детализации процесса "Анализ уязвимостей и оценка стойкости для низкого потенциала нападения (AVA_VLA.2)n, которая получена с учетом результатов пп. 3.2Л, 3.2.2.1, 3.2.2.2, приведена на рис. 3.4.
На диаграмме детализации процесса "Оценка анализа уязвимостей (AVAVLA)" (см. рис, 3.5) два выходных ресурса "Заключение по анализу уязвимостей разработчиком (AVAVLA.1)" и "Заключение по анализу уязвимостей и оценка стойкости для низкого потенциала нападения (AVAVLA.2)" объединяются в один совокупный ресурс с именем "Заключение по анализу уязвимостей (AVA_VLA)" со следующим определением: "Заключение по анализу уязвимостей: - не выносится для 0УД1; - совпадает с заключением по анализу уязвимостей разработчиком (AVA VLA.l) для ОУД2,3; - совпадает с заключением по анализу уязвимостей и оценкой стойкости для низкого потенциала нападения (AVA_VLA.2) для ОУД4." Примечание для ресурса: [20], [21]
Этот ресурс, в свою очередь, выводится на диаграмму "Оценка уязвимостей (AVA)", где происходит дальнейшее объединение.
Замечание. На этом описание действий оценщика по виду деятельности (классу доверия) AVA в русскоязычной версии стандарта заканчивается, то есть компоненты AVA_VLA.3 и AVA_VLA.4 в ней не детализированы. Таким образом, проведение оценки для ОУД5 и выше по ГОСТ Р ИСО/МЭК 15408 (или по соответствующему РД БИТ) невозможно.
