Construction of a model of threats to information security of an information system using the object-oriented design methodology

Gribanova-Podkina Mariya PhD in Physics and Mathematics Associate Professor, Department of Physics and Information Technology, Balashov Institute (branch) of the Chernyshevsky National Research Saratov State University 412300, Russia, Saratovskaya oblast', g. Balashov, ul. Karla Marksa, 29 m.gribanova-podkina@rambler.ru Other publications by this author

Проектирование системы информационной безопасности информационной системы с учетом всей важности вопроса является сложным процессом, который должен учитывать многие факторы: программные, технические, организационные и правовые. Система обеспечения информационной безопасности разрабатывается с целью достижения приемлемого уровня защиты информационной системы от случайных или преднамеренных действий различного происхождения, и ее разработка включает в себя следующие основные этапы:

1) оценку текущего состояния информационной безопасности информационной системы;

2) описание модели угроз информационной безопасности;

3) формирование рекомендаций по совершенствованию системы обеспечения информационной безопасности.

С точки зрения проектирования системы информационной безопасности, первые два этапа являются взаимосвязанными, так как оценка текущего состояния информационной безопасности производится с учетом актуальных угроз информационной безопасности, которые определяются в результате анализа модели угроз. В оценке текущего состояния системы важную роль играет проект информационной системы, который позволяет детально проанализировать функционал системы на предмет защищенности от вероятных угроз информационной безопасности. Это, кстати, позволяет анализировать защищенность системы на любом этапе ее жизненного цикла. Для современных систем, отличающихся сложной многоуровневой архитектурой, множеством неоднородных компонентов и структур, разработка проекта является также автоматизированным процессом, который осуществляется с привлечением CASE (computer-aided software engineering) средств^[1]. Вполне разумно и при разработке проекта системы информационной безопасности использовать аналогичные инструменты. В этом контексте модель угроз может иметь два варианта реализации:

– самостоятельный проект информационной безопасности информационной системы;

– интегрированный компонент безопасности в проекте информационной системы.

Для построения модели угроз информационной безопасности информационной системы используются методики и каталоги угроз из официального стандарта ГОСТ Р 51275-2006, методических документов ФСТЭК, Стандартов Банка России. Сам процесс построения модели представляет собой последовательность следующих операций:

– выявление источников угроз информационной безопасности;

– определение критически важных активов;

– определение актуальных угроз безопасности информационной системы и способов их реализации.

Согласно «Методике определения угроз безопасности информации в информационных системах» (ФСТЭК), модель угроз безопасности информации должна содержать следующие основные разделы:

– описание информационной системы и особенностей ее функционирования.

– возможности нарушителей (модель нарушителя).

– актуальные угрозы безопасности информации.

Хорошо проработанные модели угроз безопасности информации позволяют сформулировать план защиты, который сосредоточен на актуальных угрозах и предусматривает эффективные контрмеры, повышающие уровень информационной безопасности.

Учитывая сложную объектную структуру информационной системы, а также многогранность понятий информационной безопасности, для описания данных разделов целесообразно привлекать методологию объектно-ориентированного проектирования, реализованную языком моделирования UML, который часто используется при разработке проекта информационных систем. Модели, реализуемые в виде диаграмм языка UML, позволяют визуально представить структуру сложных объектов и процессов с необходимого ракурса и степенью детализации. А так как модель угроз информационной безопасности требует рассмотрения вопроса в нескольких разрезах (например, нарушители, защищаемые активы), то использование такой методологии является наиболее успешной.

Данный вопрос поднимался в научной литературе и рассматривал описанные выше возможности моделирования: разработка самостоятельных моделей информационной безопасности ^[2,3] и встраиваемые в проект ИС функции системы безопасности ^[4,5]. При этом методология разработки объектно-ориентированных моделей угроз не представлена ни в одном источнике.

В рамках настоящего исследования создавалась объектно-ориентированная модель угроз для информационной системы, обладающей следующими характеристиками:

1. Система распределенная, функционирует на базе сервера приложений, клиентская часть системы реализована в виде веб-приложения.

2. Доступ к системе имеют только сотрудники организации.

3. Система должна бесперебойно функционировать в течение всего рабочего дня.

4. Крайне нежелательна утечка информации, обрабатываемой в информационной системе.

Модель угроз разработана с использованием языка UML в среде Enterprise Architect, которая активно используется профессионалами в области проектирования информационных систем, системными аналитиками и архитекторами. Использование этого мощного инструмента видится актуальным и для специалистов в области безопасности информационных систем.

В процессе проектирования системы информационной безопасности информационной системы были сформулированы нефункциональные и функциональные требования. Функциональные требования представлены сценариями защиты информационной системы в разрезе каждой из актуальных угроз. Нефункциональные требования описывают организационные и технические характеристики системы информационной безопасности, которые относятся к качественным ее характеристикам и не описываются сценариями:

– соответствие информационной системы заданным стандартам;

– использование защищенных протоколов обмена данными;

– использование средств антивирусной защиты;

– межсетевое экранирование;

– выполнение процедур резервного копирования и другие.

Для описания проекта рассматриваются два типа источников угроз: внутренний пользователь системы (сотрудник организации), внешний пользователь (злоумышленник, не имеющий санкционированного доступа к системе). При наличии развернутой классификации источников угроз целесообразно сформировать диаграмму классов, на которой можно будет проследить типы связей соответствующих объектов ^[6].

Критически важные активы фактически были озвучены в характеристиках системы. Это целостность системы, доступность системы и конфиденциальность данных.

Для каждого из активов были определены актуальные угрозы безопасности информационной системы, которые в совокупности с источниками угроз представлены на диаграмме вариантов использования (Use Case Diagram).

Рисунок 1. Диаграмма вариантов использования. Концептуальная модель угроз.

Представленная на рисунке 1 диаграмма описывает варианты реализации угроз по всем активам информационной системы и по всем источникам угроз. В этом смысле данная модель является концептуальной моделью угроз.

Способы реализации описанных с помощью прецедентов угроз – это взгляд на отдельно взятую угрозу. Объектная методология UML позволяет проводить декомпозицию объектов, представленных на диаграммах. В нашем случае способы реализации – это тоже угрозы, расширяющие исходные. Соответственно, они должны быть связаны отношением наследования в диаграммах декомпозиции (Use Case Composite Diagram). Примеры описания способов реализации угроз «разглашение информации» и «несанкционированный доступ» приведена на рисунках 2 и 3. Отдельно следует отметить, что все диаграммы в Enterprise Architect являются интерактивными, поэтому для просмотра способов реализации угрозы можно перейти на диаграмму декомпозиции из диаграммы вариантов использования.

Рисунок 2. Способы реализации угрозы «Разглашение информации»

Рисунок 3. Способы реализации угрозы «Несанкционированный доступ»

Для просмотра угроз, направленных на каждый отдельный актив, целесообразно использовать диаграмму взаимодействия (Communication Diagram). Полученная диаграмма описывает связи между объектами системы. На рисунке 4 такими объектами являются пользователь, нарушитель и целостность информации, которые связаны прецедентами. Отметим, что в Enterprise Architect объекты, перенесенные из других диаграмм, «помнят» свои связи, что оказывается удобным механизмом при проектировании системы информационной безопасности.

Рисунок 4. Диаграмма взаимодействия. Угрозы активу «Целостность системы»

Таким образом, визуализация модели угроз использует диаграмму вариантов использования (концептуальную модель), которая детализируется:

– по граням информационной безопасности (активам системы – целостность, доступность, конфиденциальность) – с помощью диаграммы взаимодействия;

– по способам реализации угроз – с помощью дочерней диаграммы вариантов использования.

Последняя может использоваться при делении угроз по мерам воздействия на них (программные, технические и организационные). В разработанном проекте технические и организационные меры отнесены к способам реализации нефункциональных требований к информационной безопасности информационной системы, поэтому на диаграммах деление по мерам воздействия не было актуальным.

Описания сценариев реализации угроз реализованы с помощью диаграмм деятельности (ActivityDiagram), но следует отметить, что это возможно и с помощью расширения языка UML – нотации BPNM, также представленной в Enterprise Architect ^[7]. Указанную нотацию следует применять для сложных сценариев, которые требуют более детального описания бизнес-процессов и использования специальных композиционных и структурных блоков.

Для каждой угрозы возможно построение двух сценариев:

– сценарий реализации угроз;

– сценарий защиты от угрозы.

Сценарий реализации угрозы можно рассматривать как текущее состояние информационной безопасности. В терминах моделирования бизнес-процессов такая ситуация описывается термином As-Is (как есть). Пример реализации угрозы «Несанкционированное изменение данных» приведен на рисунке 5. Такой сценарий описывает ситуацию, когда пользователь системы, осуществивший вход в систему, может выполнить любые действия по изменению данных, предоставленные ему интерфейсом системы. Таким образом, со стороны системы отсутствует контроль доступности операции для пользователя, возможность ее выполнения в соответствии с должностными обязанностями, уровнем доступа и т.д.

Рисунок 5. Диаграмма деятельности.

Сценарий As-Is реализации угрозы «Несанкционированное изменение данных»

Для совершенствования системы обеспечения информационной безопасности для угрозы «Несанкционированное изменение данных» описана модель сценария To-Be (как должно быть), представленная на рисунке 6.

Эта модель фактически представляет собой сценарий защиты и использует три контура защиты:

1) проверка прав на выполнение операции, основанная на политике привилегий;

2) проверка критичности изменений, использующая классификатор операций;

3) логирование (регистрация в таблицах логов) операций.

В совокупности они образуют модуль безопасности по угрозе «Несанкционированное изменение данных», который предполагает внесение функциональных изменений в конструкцию информационной системы. С точки зрения информационной безопасности такая модель позволяет сформулировать функциональные требования к информационной системе:

– использование политики привилегированного доступа;

– наличие классификатора критичности операций;

– наличие таблиц логов по осуществляемым операциям;

– реализация программно-аппаратного комплекса подтверждения операций третьим лицом;

– реализация программно-аппаратного комплекса оповещения службы безопасности.

Рисунок 6. Диаграмма деятельности.

Сценарий To-Be реализации угрозы «Несанкционированное изменение данных»

Меры защиты, реализующие озвученные требования, могут использовать как типовые ^[8,9,10], так частные решения. Указанные меры в дальнейшем включаются в план защиты информационной системы, который представляет собой совокупность функциональных и нефункциональных требований к системе безопасности.

Приведенные примеры наглядно демонстрируют, что объектно-ориентированная методология проектирования является полезным инструментом в разработке проекта системы информационной безопасности в целом и модели угроз безопасности информационной системы, в частности. Исчерпывающее описание проекта может включать в себя такие компоненты, как диаграммы классов (это указывалось при определении источников угроз информационной безопасности), диаграммы компонентов и развертывания, диаграммы данных (описание сущностей, фигурирующих в сценариях).

Разработанные с помощью нотации UML модели угроз и сценариев являются важной частью документации по системе информационной безопасности, которая позволяет эффективнее взаимодействовать информационным аналитикам и специалистам по информационной безопасности с целью обеспечения защиты информационных систем от угроз информационной безопасности.

You can simply select and copy link from below text field.