CC BY-NC-ND
91
Технологии
А.Н. Приезжая
АВТОМАТИЗИРОВАННАЯ РАЗРАБОТКА ЗАЩИЩЕННОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ
Процесс разработки информационной системы в защищенном исполнении требует трудоемкого анализа защищаемого объекта и разработки большого количества документации. В данной статье предлагается технология, основанная на автоматизированном преобразовании UML-моделей, которая позволяет одновременно разрабатывать несколько представлений объекта, включая текстовое описание, и в автоматизированном режиме строить на их основе модели угроз и нарушителя, а также модель системы защиты. В данной статье разработка защищенной информационной системы рассматривается на примере распределенной базы данных.
Ключевые слова: UML-модель, персональные данные, преобразование моделей, модель объекта, модель угроз, документация, модель системы в защищенном исполнении.
В России существует огромное количество видов (категорий) информации, подлежащей защите (по некоторым оценкам до 30), и к каждому из них предъявляются свои требования по обеспечению безопасности1, кроме того, в связи с развитием информационных технологий постоянно растет сложность систем обработки данных. В результате специалисты в области информационной безопасности сталкиваются с необходимостью защищать все более сложные системы в соответствии с разными, порой противоречивыми, требованиями, и при этом сроки разработки СЗИ крайне ограничены2. В связи со всем вышесказанным особую актуальность приобретает создание средств поддержки разработки защищенных систем.
Предложенный автором метод автоматизированной разработки информационных систем в защищенном исполнении включает в
© Приезжая А.Н., 2010
себя разработку нескольких взаимосвязанных формальных моделей объекта, предназначенных для автоматизированного преобразования, построенного с использованием технологии MDA, в результате которого генерируются модель угроз безопасности информации, модель системы защиты и модель защищенной информационной системы. Рассматриваемый подход упрощает анализ системы, сокращает затраты времени на рутинные процедуры и снижает вероятность ошибки, иными словами, снижает финансовые и временные затраты на разработку защищенной системы.
В данной статье процесс разработки ИС в защищенном исполнении рассматривается на примере распределенной системы, обрабатывающей персональные данные. Взаимодействие распределенных компонент системы осуществляется через каналы общего пользования, то есть для защиты передаваемой информации конфиденциального характера необходимо применение СКЗИ.
В зарубежной научной литературе разработано несколько методов преобразования моделей с использованием технологии MDA. В частности, предложен ряд диалектов UML для разработки систем безопасности3. Также в ряде статей рассматривается применение в интегрированной разработке систем в защищенном исполнении технологии MDA для какого-то одного аспекта (механизма) безопасности4.
Существующие на сегодняшний день технологии предусматривают разработку СЗИ параллельно с функциональной частью системы, тогда как применение UML и MDA для разработки СЗИ на этапе эксплуатации системы в литературе не разработано. Кроме того, существующие методы автоматизированной разработки предусматривают только внедрение функций безопасности в информационную систему, в то время как метод, предложенный автором, предусматривает автоматизацию работ, выполняемых на предшествующих этапах, а именно разработку моделей угроз и потенциальных возможностей нарушителя, соответствующую требованиям российского законодательства.
Общие принципы разработки информационной системы в защищенном исполнении
Построение системы безопасности корпоративной информационной системы (ИС) невозможно без четкого представления о том, как она фактически функционирует, а также о том, в какой мере и каким образом ее ресурсы уже защищены. Для решения этой задачи проводится изучение информационной системы и ее компонент,
а также организации работы пользователей с целью выявления основных информационных ресурсов и информационных потоков, их соотнесения с различными категориями обрабатываемой информации, определяются границы системы, для которой должен быть обеспечен режим информационной безопасности. Соответственно определяется существующая структура организации, размещение средств вычислительной техники и поддерживающей инфраструктуры, технология обработки информации, ресурсы информационной системы, подлежащие защите. Для оценки ресурсов выбирается система критериев и методология получения оценок по этим критериям.
На основе полученных на этапе предпроектного обследования данных строится модель защищаемого объекта. В сложившейся практике модель объекта, как правило, представляется в форме вербального описания объекта защиты. В рамках данной статьи используется модель объекта, построенная на формальном языке моделирования (UML-модель), так как создание текстового описания объекта по его формальной модели является достаточно простой задачей, а сама формальная модель объекта делает объект более обозримым для разработчика, позволяя рассмотреть систему с разных точек зрения, с заданным уровнем детализации. Кроме того UML-модель объекта используется в ходе автоматизированной разработки модели информационной системы в защищенном исполнении.
На основе модели объекта разрабатываются модели угроз безопасности информации и вероятного нарушителя, проводится анализ рисков и разрабатывается перечень актуальных угроз. Также в ходе данного этапа разработки создаются политики безопасности и частное техническое задание на разработку СЗИ.
Техническое проектирование ИС в защищенном исполнении включает разработку технического проекта (пояснительной записки, ведомости технического проекта, плана организационно-технических мероприятий по подготовке ИС к внедрению средств и мер защиты информации и т. д.). На данном этапе определяются конкретные технические решения, реализующие выбранные политики безопасности и разработанную для данной автоматизированной системы концепцию СЗИ.
На следующем этапе разрабатываются положения по организации и проведению работ по обеспечению безопасности информации при ее обработке в ИС, требования по обеспечению безопасности информации при ее обработке в ИС, инструкции персоналу в части обеспечения безопасности информации при ее обработке в ИС и т. д. В случае необходимости проводятся аттестационные испытания ИС по требованиям безопасности информации.
Предложенный в данной работе метод разработки информационной системы в защищенном исполнении предназначен в первую очередь для автоматизации работ, проводимых на предпроектном этапе и частично на этапе технического проектирования. В ходе этого этапа не только проводится первичный анализ объекта защиты, определение его границ и основных свойств, но и разрабатываются документы, определяющие принципы построения системы защиты. При этом необходимо учитывать, что разрабатываемая интеграторами система защиты информации и сопровождающая ее документация должны соответствовать требованиям регуляторов в области обеспечения безопасности информации. В качестве регуляторов в данной области в настоящий момент выступают ФСТЭК России и ФСБ России5. Каждая из структур разрабатывает собственную обязательную для выполнения нормативно-методическую базу, кроме того, НМД привязана к виду защищаемой информации и типу ИС.
При этом процессы обработки информации организованы таким образом, что выделение персональных данных из общего массива информации конфиденциального характера нецелесообразно, а порой и невозможно. Таким образом, автоматизированные системы одновременно обрабатывают информации различных видов: коммерческая тайна и персональные данные (ПДн), служебная тайна и персональные данные и т. д. В этом случае может возникнуть необходимость совмещения требований регуляторов к режиму защиты различных видов информации, также в случае принятия решения об использовании криптографических (шифровальных) средств для обеспечения безопасности персональных данных возникает необходимость совмещения требований ФСТЭК России и ФСБ России как в части разработки документов, так и в части предъявляемых требований, что далеко не всегда является простой задачей.
Разработка модели объекта
Модель угроз и модель нарушителя, а впоследствии и система защиты информации строятся применительно к конкретному объекту с учетом особенностей его функционирования. Следовательно, для построения грамотной модели угроз безопасности и возможного нарушителя необходимо провести анализ объекта.
Анализ объекта может быть проведен с применением различных методик. Одной из возможных методик анализа является моделирование, которое позволяет получить обозримое и полное представление системы с требуемым уровнем детализации, кроме того, в рамках предложенного автором подхода модель объекта ис-
пользуется для автоматизированного получения модели угроз и в дальнейшем построения модели защиты.
Модель объекта должна быть построена максимально полной, с различными представлениями объекта и различными уровнями детализации, так как информация, которая может показаться избыточной на одном этапе, может быть использована на последующих. Например, данные об используемых протоколах не нужны для определения принципов построения системы защиты, но могут оказать влияние на выбор технических средств.
Для построения UML-модели объекта необходимы следующие исходные данные:
- перечень информации, подлежащей защите;
- расположение АС относительно границ контролируемой зоны (КЗ);
- конфигурация и топология АС в целом и ее отдельных компонент, в том числе физические, функциональные и технологические связи как внутри этой АС, так и с другими системами различного уровня и назначения;
- технические средства и системы, использующиеся в АС, условия их расположения;
- общесистемные и прикладные программные средства, имеющиеся или предлагаемые к использованию (разработке) в АС;
- режимы обработки информации в АС в целом и в ее отдельных компонентах;
- степень участия персонала в обработке информации конфиденциального характера, характер его взаимодействия между собой.
На основании полученных исходных данных строится модель объекта, включающая описание:
- защищаемых ресурсов (информация, программное обеспечение, технические средства, средства защиты и т. п.);
- информации, обрабатываемой в системе (класс, количество, формы представления и др.);
- потоков информации;
- подключения к сетям общего пользования;
- архитектуры системы (логика ее построения);
- функционального взаимодействия компонентов системы;
- размещения (с точки зрения топологии сети, программных модулей);
- технических средств (аппаратные и программные средства, используемые протоколы, порты);
- размещения ТС в границах контролируемой зоны;
- пользователей системы (должностные обязанности, режим доступа, права доступа);
- существующих мер и средств защиты (в том числе резервное копирование) в той мере, в которой они будут сохранены в информационной системе в защищенном исполнении.
Результаты информационного обследования объекта, как правило, оформляются в виде текстового отчета, однако в рамках данной работы в качестве описания объекта будет рассматриваться формальная модель на языке иМЬ. Данная модель не только упростит процесс анализа объекта для разработчика, сделав объект более обозримым, но и позволит ему создавать модель угроз безопасности и потенциального нарушителя, а затем и модель защиты в автоматизированном режиме, который позволяет контролировать соответствие разрабатываемых моделей исходным данным (собственно модели объекта) и требованиям регуляторов.
Модель объекта формируется из двух основных представлений: модели бизнес-логики системы и модели реализации. Модель бизнес-логики содержит описание технологического процесса в форме сценариев иМЬ и диаграмм классов, отражающих логику построения, функциональные подсистемы, основные информационные потоки, штатную структуру организации. Модель реализации содержит описание объектов доступа, размещения компонент системы и их спецификации, информационного обмена между распределенными частями ИС, а также диаграммы действия, описывающие реализацию сценариев техническими средствами системы, субъектов доступа системы и их прав и т. д. Все представления системы взаимосвязаны, так как они отражают один и тот же объект с разных точек зрения и с различной степенью детализации.
Для большей наглядности проиллюстрируем создание модели объекта описанием распределенной базы данных. В рассматриваемом примере ИС имеет три уровня: центральный, региональный и уровень пользователя. Информация вводится в региональные базы, затем по каналу связи передается в центральную базу данных, удаленные пользователи посылают запросы в региональную или центральную базу. База данных состоит из двух независимых систем обработки запросов (обусловленных формой представления запрашиваемой информации-изображение или текст). Взаимодействие между системами осуществляется по открытому каналу связи.
Рассмотрим порядок построения модели объекта. Одним из основных представлений объекта является диаграмма классов, описывающая логическую структуру ИС; в нашем примере данная диаграмма включает в себя объекты центрального, регионального уровней и уровня пользователей и отражает связи между этими объектами. Каждый тип объекта представляется классом, уровень объекта определяется стереотипом, а его тип отражается в имени класса (рис. 1).
«Центральный»
«региональный» БД РУ
«пользователь» Пользователь
Рис. 1. Логическая структура - первое приближение
Взаимодействия между объектами отображаются двумя способами: с помощью направленных ассоциаций (в свойствах ассоциации содержатся данные об информации, передающейся между уровнями) и на диаграммах последовательности, где взаимодействие объектов моделируется более подробно. Диаграммы последовательности строятся для основных сценариев и отображают обмен информацией между объектами разного уровня. Еще одна форма представления - диаграмма классов, описывающая функциональные подсистемы; данный вид диаграммы используется в тех случаях, когда объекты имеют выраженное разделение по функциональному признаку, отличное от его логической структуры.
В общем случае объект каждого уровня может представлять собой сложную распределенную ИС со своей логической структурой. В этом случае для каждого класса строится ассоциированный пакет, описывающий его внутреннюю логическую структуру. В нашем случае такие пакеты строятся для двух верхних уровней, при этом данный пакет имеет аналогичную структуру, то есть включает в себя классы, отображающие типы объектов и диаграммы классов, описывающие взаимодействия внутри объекта и - в случае необходимости - с объектами других уровней (при этом диаграммы последовательностей данного уровня детализируют взаимодействия между уровнями). Для сложных распределенных систем также выделяются функциональные подсистемы и описывается информационное взаимодействие между ними. Так, в рассматриваемом примере выделяются две подсистемы - индексации и поиска информации (в зависимости от формы представления информации) и коммуникационная подсистема.
Каждая функциональная подсистема представляется отдельным классом, взаимодействие между классами описывают диаграммы последовательности. В случае необходимости дальнейшей дета-
лизации для функционального класса создается ассоциированный пакет, отражающий его внутреннюю структуру.
Для определения угроз безопасности информации необходимо определить условия размещения компонент ИС, каналы связи и организационно-режимные мероприятия. Для полного описания условий функционирования объекта защиты строятся диаграмма (диаграммы) размещения логических компонент системы на серверах и узлах сети; диаграмма (диаграммы) размещения функциональных компонент системы на серверах и узлах сети.
Технические средства серверов и узлов сети моделируются классами со стереотипом ТС, каждый такой класс обладает атрибутами, отражающими перечень аппаратных компонент и установленного программного обеспечения. При этом для каждого технического средства или типа технического средства определяются условия размещения, организационно-режимные мероприятия, в частности режим доступа, контролируемая зона и т. д. Данные свойства задаются в специальном меню - Deployment, определяемом в файле deployment.pty. Также для технического средства могут быть определены характеристики безопасности6, например не-отказуемость. Аналогичным образом моделируется программное обеспечение. Диаграммы размещения технических средств определяют применение тех или иных ТС (ПО) на определенных логических и функциональных подсистемах.
При определении связи между распределенными компонентами необходимо определить свойства канала: является ли этот канал внутренним, выделенным, защищенным или открытым каналом общего пользования. Свойства канала отражаются в его стереотипе. Так, в рассматриваемом примере канал между региональным и центральным уровнями имеет стереотип «Internet», а канал, связывающий серверные компоненты регионального уровня, - «Secure LAN».
Необходимо определить информацию, обрабатываемую в системе. Для информационных ресурсов используются следующие представления:
- диаграмма классов, содержащая виды информации (персональные данные, коммерческая тайна и т. п.), обрабатываемые в системе. Каждый вид отображается отдельным классом, характеристики безопасности по умолчанию для данного вида информации задаются значениями соответствующих атрибутов этого класса (имя атрибута - характеристика безопасности, значение 0 не предъявляется, 1 предъявляется), например, к персональным данным по умолчанию предъявляются целостность и конфиденциальность, в процессе оп-
ределения характеристик безопасности конкретного информационного ресурса значения могут быть переопределены;
- диаграмма классов, отображающая информационные ресурсы автоматизированной системы, например фотоизображения, или паспортные данные, или данные банковского счета и т. п. Защищаемый информационный ресурс представляется отдельным классом, для каждого такого ресурса ассоциируется класс, представляющий вид информации, атрибуты этого класса содержат дополнительные характеристики безопасности или переопределяют характеристики по умолчанию. Кроме того, для классов, определенных как персональные данные, необходимо определить дополнительные атрибуты - категорию и количество;
- строятся диаграммы размещения информационных ресурсов на компонентах распределенной системы, а также по функциональным подсистемам. При этом для каждого компонента системы определяются формы, в которых на нем может существовать информация, и при определении информационного ресурса для него задаются возможные формы представления на данном сервере, узле - техническом средстве;
- строятся диаграммы взаимодействия, описывающие информационные потоки между компонентами и подсистемами ИС.
Строится диаграмма классов, описывающая структуру зарегистрированных пользователей системы, то есть субъектов доступа. В нашем примере это пользователь, оператор и системный администратор. Для удобства дальнейшего анализа вводится класс (группа), объединяющий пользователей (классы со стереотипом 8у81еши8вг).
Также строятся диаграммы, описывающие категории лиц, допущенных к системе, но не являющихся ее зарегистрированными пользователями. Эти классы объединяются общим стереотипом Коп8у81ешизег. В качестве таких лиц могут рассматриваться:
- представители сторонних организаций;
- лица, обеспечивающие поставку и ремонт технических средств;
- представители организаций, взаимодействующих по вопросам обеспечения жизнедеятельности АС;
- обслуживающий персонал, производящий работы в помещениях, в которых размещается оборудование ИС (например, работники хозяйственных служб);
- другие сотрудники организации, имеющие доступ в помещения, в которых размешается оборудование ИС;
- и другие категории лиц.
Для всех категорий лиц, допущенных к системе, описываются существующие режимные ограничения, в том числе порядок допуска в контролируемую зону, возможность удаленной работы, порядок аутентификации и т. д. Данные ограничения задаются значениями соответствующих атрибутов класса.
Для каждой категории пользователей в системе (в нашем случае это администратор, пользователь и оператор) определяются полномочия. В первом приближении полномочия пользователя определяет сценарий. Также могут быть построены сценарии взаимодействия с системой лиц, не являющихся зарегистрированными пользователями системы.
Для данной системы необходимо создать несколько сценариев (Use case), например:
- ввод информации в БД;
- удаление информации из БД;
- поиск информации;
- синхронизация баз данных центрального и регионального уровней;
- порядок осуществления технической поддержки (осуществляется организацией-разработчиком удаленно);
- управление пользователями.
Естественно, каждый сценарий имеет несколько вариантов развития, в частности ввод новой информации в БД и попытка повторного ввода информации в БД. Сценарии необходимы для понимания функциональных задач системы и используются в дальнейшем для построения диаграмм последовательности, описывающих взаимосвязь компонент ИС и информационный обмен между ними.
Диаграмма последовательности представляет собой описание реализации сценария через обмен сообщениями (вызовами) между классами системы (рис. 2).
На основании UML-модели объекта строится текстовый шаблон описания объекта, который после доработки может быть включен в отчетную документацию. На основании практического опыта автором был разработан шаблон описания объекта - типовые разделы и принципы построения документа, для которых на основании модели с помощью скрипта (genDescription) автоматически генерируются текстовые описания. В общем случае полученный шаблон модели объекта имеет следующую структуру: ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ ПРИНЯТЫЕ СОКРАЩЕНИЯ
1. ВВЕДЕНИЕ
2. ХАРАКТЕРИСТИКИ ОБЪЕКТА ЗАЩИТЫ 2.1. Основание для разработки
Оператор -Т-
Устройство -г
АРМ
п
информация
кодирование
рекомендател
ввод в БД
Сервер
I
|НЫИ список
еизображения
Вычислитель -1-
тестовые! данные
е д
запрос.
Сервер хранения
Рис. 2. Диаграмма поиска
2.2. Основания обработки персональных данных
2.3. Назначение, архитектура и структура
2.4. Состав, обрабатываемая информация и пользователи
2.5. Характеристика объекта защиты по уровням логической структуры
2.5.1. Общее описание
2.5.2. Архитектура
2.5.3. Функциональные возможности
2.5.4. Расположение
2.5.5. Состав и назначение технических средств
2.5.6. Информационное взаимодействие подсистем
2.5.7. Информационное взаимодействие уровней
2.6. Организационно-режимные меры
2.7. Классификация
2.8. Объекты защиты и защищаемые ресурсы
Разумеется, полученный текст не является готовым документом и требует доработки специалистом, однако наличие подобного шаблона документа и схем, его иллюстрирующих, значительно ускоря-
ет процесс документирования работ по созданию СЗИ и уменьшает вероятность появления расхождений между реальным состоянием системы и ее описанием в документации.
Разработка модели угроз и возможностей нарушителя
Модель угроз строится на основании модели объекта, отражающей особенности его функционирования, типовой модели угроз и экспертных решений. Предлагаемый инструмент разработки автоматизирует процесс анализа модели объекта и построения моделей угроз и нарушителя, в процессе разработки используются типовые модели, построенные в соответствии с руководящими документами ФСТЭК России и ФСБ России и основанные на практическом опыте автора7.
Инструмент поддержки разработки модели угроз и модели потенциального нарушителя включает в себя:
1. Базовую модель угроз и потенциального нарушителя (Базе.шЛ)8, которая содержит описание типового нарушителя, его возможностей, типовых уязвимостей программных и технических средств, а также модели каналов и способов реализации угроз. Кроме того, в данном пакете моделируются такие ключевые абстракции, как характеристики безопасности.
2. Шаблон модели объекта (некоторый набор правил, в соответствии с которыми строится модель объекта; описание построения модели объекта приведено в разд. 4).
3. Инструмент разметки базовой модели, позволяющий выбирать или исключать ее составляющие.
4. Инструмент разметки модели объекта, позволяющий задать требования для различных элементов модели.
В соответствии с методикой разработки при создании модели угроз безопасности информации и потенциального нарушителя необходимо:
- создать модель угроз верхнего уровня;
- создать модель нарушителя, то есть определить:
a) категории лиц - потенциальных нарушителей;
b) степень их осведомленности о системе;
c) перечень имеющихся в их распоряжении методов и средств проведения атак;
ё) перечень возможных каналов атак;
- определить актуальные способы реализации, то есть детализированные угрозы.
Построенная на подготовительном этапе модель объекта позволяет в автоматизированном режиме построить модель угроз верхнего уровня, то есть выделить все ресурсы и связанные с ними характеристики безопасности. Инструмент преобразования (скрипт GenModelhigh) создает отдельную диаграмму для каждого типа угроз (например, угрозы модификации, угрозы нарушения конфиденциальности и т. п.), на которых отображаются объекты, этим угрозам подверженные, также данная модель представляется в текстовом виде.
Модель нарушителя строится экспертным путем на основании базовой модели нарушителя Base.mdl и диаграмм субъектов доступа. Диаграммы субъектов доступа используются для определения категорий лиц, которые могут рассматриваться в качестве нарушителя, и лиц, исключенных в силу организационных мер, из числа нарушителей. В зависимости от организационных ограничений, связанных с каждым классом субъекта доступа, определяется, к какому типу нарушителя (внутренний или внешний) относится данная категория лиц. Предположения о возможностях потенциального нарушителя и его знаниях о системе строятся с использованием предположений базовой модели (в частности, об уровне знаний и вооруженности типовых категорий нарушителя и перечень возможных каналов атак) на основании экспертной оценки, а также таких элементов модели объекта, как права доступа субъектов доступа - потенциальных нарушителей, и режим доступа, связанный с объектами защиты - техническими средствами, и свойства каналов связи. Так, инструмент преобразования автоматически определяет перечень объектов, к которым возможен удаленный доступ, а также прямой доступ внешнего нарушителя (например, компьютеры мобильных пользователей). Полученные данные анализируются экспертом, из рассмотрения могут быть исключены неактуальные каналы атак или переопределены возможности нарушителя.
На основании полученной модели нарушителя строится детализированная модель угроз. Для каждой угрозы безопасности верхнего уровня вида <ресурс> - нарушение Характеристики безопасности> - определяется возможный канал атаки и способ реализации угроз (то есть нарушения характеристики безопасности). Кроме того, ресурс связан с понятием уязвимости, наличие которой в свою очередь определяет возможность применения конкретного способа реализации. Для каждого типового канала доступа в базовой модели определены способы реализации угроз (то есть способы нарушения характеристик безопасности; так, например, для электромагнитного канала рассматривается способ нарушения конфиденциальности - перехват ПЭМИ, ВЧН и т. д.). Для каждого
способа реализации определен требуемый тип нарушителя и необходимая техническая вооруженность. Таким образом, в построении детализированной модели угроз задействованы следующие абстракции (см. рис. 3).
Каждая из представленных на схеме абстракций в модели представлена стереотипом класса, описывающего конкретный канал или, например, тип нарушителя.
Детализированная модель угроз имеет следующую структуру: для каждого канала доступа создается отдельный пакет, в котором создаются диаграммы для каждого ресурса, содержащие классы, описывающие способ реализации угрозы безопасности. Угрозы безопасности формируются не для каждого отдельного ресурса, а для типа ресурса, обладающего одинаковыми свойствами. Так, например, в рассматриваемой системе одинаковые требования будут предъявляться ко всем серверам обработки информации центрального уровня.
На основании модели угроз и описания объекта осуществляется автоматизированная классификация автоматизированной системы АС (скрипт classification):
- определяется класс ИСПДн (в соответствии с руководящими документами ФСТЭК России);
- тип нарушителя (путем сравнения с описанием типов нарушителя в базовой модели);
- класс в соответствии c РД, результат классификации записывается в текстовый файл и включается отдельной диаграммой в модель.
Рис. 3. Связь понятий, используемых при разработке детализированной модели угроз
Проверка модели угроз
Проверка модели осуществляется на основании формальных правил. Построенная детализированная модель угроз анализируется, в частности, по следующим параметрам:
- правильность классификации нарушителя (осуществляется сравнением классов, описывающих возможности нарушителя данного объекта, с классами базовой модели, при этом проверяется наличие всех исходных данных);
- соответствие детализированных угроз угрозам верхнего уровня, то есть для каждой угрозы верхнего уровня должен существовать, как минимум, один способ реализации;
- для каждого канала реализации должен быть, как минимум, один способ реализации;
- для систем, имеющих подключения к каналам общего пользования, должны быть предусмотрены угрозы удаленного доступа (для всех объектов, имеющих такое подключение);
- для информации, передающейся по открытым каналам, должны рассматриваться угрозы перехвата, модификации (в зависимости от характеристик безопасности);
- для ИСПДн 1 и 2 класса, ИС, использующих СКЗИ, должны быть учтены угрозы утечки по техническим каналам.
Разработка информационной системы в защищенном исполнении
При построении модели защиты необходимо учитывать модель объекта; модель угроз безопасности; требования регуляторов к функциональным возможностям системы защиты.
При формировании модели системы защиты информационной системы для каждого технического средства формируется перечень актуальных угроз. Данный перечень формируется путем группировки сходных угроз безопасности ресурсов, размещенных на данном сервере, для некоторых типов угроз прослеживаются ассоциации с формами представления информации. В результате образуется перечень угроз вида «утечка информации, обрабатываемой на сервере А, по техническим каналам», «внедрение на сервер А вредоносных программ» и т. п. Для угроз, осуществляемых по сети, проводится проверка стереотипов каналов связи для определения «точек» установки средств межсетевого экранирования, обнаружения атак и других средств защиты, обеспечивающих безопасное подключение к открытым сетям.
На основании данного перечня автоматически осуществляется предварительный выбор требуемых механизмов защиты, который затем дорабатывается экспертным путем.
На основании модели СЗИ и модели объекта генерируется модель информационной системы в защищенном исполнении. В рамках данного подхода в качестве PIM рассматривается бизнес-модель распределенной системы, которая затем отображается на «технологическую платформу» - систему защиты информации9.
Результатом данного отображения будем PSM - модель системы в защищенном исполнении, по которой в дальнейшем возможна генерация кода. Для реализации данного отображения в соответствии с технологией MDA также необходимо разработать метамо-дель преобразования и инструмент, его реализующий.
Этот механизм позволяет сравнительно легко модернизировать систему защиты информации, сохраняя согласованность компонентов на уровне модели и, следовательно, на уровне кода. При использовании данной технологии достаточно внести изменение только в модель СЗИ, а затем повторить процедуру преобразования, фактически отобразить бизнес-модель на другую технологическую платформу.
Требования к системам защиты информации формулируются не только заказчиком, но и государственными регуляторами в сфере информационной безопасности, для многих систем требуется аттестация по требованиям безопасности информации и сертификация применяемых средств защиты информации, что делает нецелесообразным разработку собственных механизмов защиты для каждого бизнес-приложения, так как это влечет дополнительные затраты и сложности, иными словами, целесообразно использование готовых средств защиты информации.
Модель защищаемой системы
Модель системы в защищенном исполнении
т
Код
Рис. 4. Создание системы в защищенном исполнении
При этом необходимо обеспечить комплексность защиты и достаточность применяемых механизмов.
В рамках данного подхода для каждого ресурса на основании модели защиты автоматически определяется перечень подключаемых механизмов защиты, который заносится в свойства класса в инструмент Security. Применительно к каждому из основных механизмов защиты инструмент преобразования формирует интерфейсы защиты, определяющие требуемый класс СВТ, а также перечень настроек. Например, с точки зрения системы разграничения доступа на основе сценариев и диаграмм действия модели объекта формируется матрица доступа, в случае необходимости определяется уровень допуска субъектов и уровень конфиденциальности объектов. Полученная информация выводится в текстовом виде и может быть использована как для автоматической настройки средств защиты, так и администратором безопасности.
Полученная модель системы в защищенном исполнении проверяется на соответствие требованиям регуляторов. Для каждого требования регулятора автоматически указывается правило модели защиты, его реализующее, и предлагаемая настройка средств защиты.
Вывод
Рассматриваемая система поддержки разработки автоматизированных систем в защищенном исполнении не может в автоматическом режиме решать нестандартные задачи или предлагать нетривиальные решения, однако гибкость предложенного инструмента позволяет вносить любые изменения в построение системы защиты либо самого объекта, исключать и добавлять угрозы на всех этапах работ, при этом инструмент обеспечит актуальность всех представлений системы, включая документацию. Использованный в инструменте метод моделирования позволит разработчикам СЗИ легче ориентироваться в современных сложных распределенных ИС, находить их уязвимые места и предлагать нестандартные решения.
Примечания
1 См.: Ефремов А. Понятие и виды конфиденциальной информации [Электронный ресурс] // Сайт В.Б. Наумова. [М., 2009]. URL: http://www.russianlaw.net/ law/doc/a90.htm (дата обращения: 4.11.2009).
В том числе и благодаря ФЗ «О персональных данных», требующему привести информационные системы персональных данных в соответствие с законодательством до 1 января 2010 г.
См.: Jurjens J. Secure Systems Development with UML, Springer Academic Publishers, 2004 [Электронный ресурс] // Сайт программы Emule. [М., 2009]. URL: ed2k://|file|Secure_Systems_Development_with_UML_(Springer-2005). pdf|2459327|7B6A7A0EA87A02B AA419A69D9EC69A0E|/ (дата обращения: 4.11.2009); Lodderstedt T, Basin D., Doser J. SecureUML: A UML-Based Modeling Language for Model-Driven Security [Электронный ресурс]. [М., 2009]. URL: http://kisogawa.inf.ethz.ch/WebBIB/publications-softech/papers/2002/ 0_secuml_uml2002.pdf (дата обращения: 4.11.2009); Peterson M.J, Bowles J.B., Eastman C.M. UMLpac: An Approach for Integrating Security into UML Class Design [Электронный ресурс]. [М., 2009]. URL: http://www.cse.sc.edu/~yon-cek/REU/PetersonPaper.pdf (дата обращения: 4.11.2009). См.: Lodderstedt T., Basin D., Doser J. Model Driven Security from UML Models to Access Control Infrastructures [Электронный ресурс]. [М., 2009]. URL: http://www.inf.ethz.ch/personal/basin/pubs/mdac-tosem.pdf (дата обращения: 4.11.2009); Basin D., Doser J. Model Driven Security for Process-Oriented Systems [Электронный ресурс]. [М., 2009]. URL: http://kisogawa.inf.ethz.ch/WebBIB/ publications/papers/2003/ p344- odderstedt.pdf (дата обращения: 4.11.2009). Для систем, отнесенных к компетенции ФСБ России, и в случае применения криптографических (шифровальных) средств.
Характеристика безопасности моделируется классом. При необходимости внедрения дополнительной характеристики безопасности создается класс, который будет обработан инструментом преобразования.
См. в наст. номере: Приезжая А.Н. Анализ нормативно-методических документов в области защиты персональных данных.
Данные модели построены на основании практических разработок автора. Модели угроз и потенциального нарушителя, положенные в основу базовой модели, прошли согласование во ФСТЭК России и ФСБ России. Приезжая А.Н. Технологии встраивания функций безопасности в бизнес процессы // Вестник РГГУ. 2009. № 10. Сер. «Информатика. Защита информации. Математика». С. 71-84.
2
3
4
5
6
7
8
9
