Статья рекомендована А.А. Стрельцовым 8.08.2013 г.

Аннотация

В статье показано, что интегрированное единое представление информационной системы и системы ее защиты в виде модели открытой среды OSE/RM обеспечивает возможность совмещения жизненных циклов обеих систем. Описан ряд задач и моделей, составляющих методологическую основу данной разработки. Приведена структурная схема и алгоритм функционирования компьютерной системы поддержки безопасности объекта защиты.

Ключевые слова:

жизненный цикл системы защиты, модель открытой системы, бизнес-процесс, безопасность, объект защиты.

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

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

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

• совмещения жизненных циклов (ЖЦ) ИС и систем их защиты;

• построения компьютерных систем поддержки управления безопасностью ИС на протяжении всего ЖЦ системы защиты.

Цель работы – описать модельно-алгоритмическую составляющую управления безопасностью ИС, основанную на этих принципах.

Модель открытой среды

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

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

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

• построить технологию выбора защитных механизмов (Мх), ориентированную на функциональные особенности компонентов ИС;

• контролировать интегрированный уровень защищенности ресурсов ИС, обеспечиваемый и штатными, и наложенными средствами.

Для этих целей предлагается использовать модель открытой среды IEEE POSIX 1003.0 OSE/RM (Open System Environment/Reference Model) [1, 2], которая синтезирует функциональность ИС и системы защиты на референтном (эталонном, справочном) уровне. Такой синтез обеспечивает основу для управления жизненным циклом системы защиты ИС.

Рис. 1. Концептуальная модель OSE/RM

<ИС> – плоскость функциональности ИС,

<А> – плоскость администрирования,

<З> – плоскость защиты

Модель включает два компонента: прикладной и платформу, обеспечивающую функционирование прикладных приложений посредством системных сервисов, вызываемых с помощью API-функций (рис.1). Она структурируется в виде матрицы компонентов («клеток»), отражающих функциональные группы ИС, и содержит три уровня по четыре группы функциональных компонентов в каждом:

• компоненты служб и сервисов промежуточного слоя (MW);

• компоненты операционных систем или операционного слоя (OW);

• аппаратный слой (HW).

Функциональные группы компонентов в данной модели составляют:

• компоненты, обеспечивающие интерфейс с пользователем (User – "U");

• компоненты, обеспечивающие все необходимые процессы (System – "S");

• компоненты, обеспечивающие организацию, представление, доступ и хранение данных (Information – "I");

• компоненты телекоммуникационной среды, обеспечивающие взаимосвязь информационных систем (Communication – "C"); данный уровень представляет собой известную модель взаимосвязи открытых систем (OSI/RM – Open System Interconnection/Reference Model).

Модель трехмерна, она имеет несколько плоскостей. Рассматривались три плоскости: передняя (базовая) <ИС> предназначена для структуризации основных функций, относящихся непосредственно к реализации прикладной части ИС. Кроме того, имеются плоскость администрирования прикладной системы <А> и плоскость ее защиты <З>, которые отражают каждая в своем контексте функциональность базовой плоскости (кстати, стандарт [2] позволяет достраивать дополнительные плоскости под любые функциональные потребности). Таким образом, понятие ИС включает и интегрирует в единую систему функциональность трех граней информационной технологии: прикладной (плоскость <ИС>), административной (плоскость <А>) и защитной (плоскость <З>).

Возможно двоякое представление плоскости защиты [1].

Представление 1. «Клетки» плоскости <З> интегрируют совокупности механизмов, обеспечивающих защиту реализаций соответствующих «клеток» базовой плоскости <ИС>. Это межкатегорийный аспект (в терминах стандарта).

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

Тогда комплексной системой защиты (КСЗ) назовем совокупность программно-технических средств защиты, реализующих механизмы межкатегорийной плоскости <З> (представление 1), построенной в соответствии с проектным представлением 2. Значит, КСЗ – это плоскость <З> модели OSE/RM, а объект защиты (ОЗ) представлен всеми тремя плоскостями модели.

Описанное единое представление ИС естественным образом требует совмещения ЖЦ и позволяет вести параллельную разработку всех трех плоскостей с учетом их функциональных особенностей и взаимосвязей.

Представление совмещенного жизненного цикла

Обобщая нормативные документы в области информационных систем и программных средств [3–5], жизненный цикл ИС можно рассматривать как состоящий из трех основных стадий, включая нулевой этап консалтинговых работ. Тогда стадии ЖЦ системы защиты представляются следующим образом:

1 – формирование требований, когда в рамках консалтинга лицо, принимающее решение (ЛПР), определяет стратегические приоритеты организации в области политики безопасности; выявляются цели безопасности для объекта защиты, производится детализация их по функциональным компонентам («клеткам» модели) ИС [1];

2 – проектирование включает разработку функциональной архитектуры КСЗ и детальное проектирование, интеграцию различных компонент системы;

3 – на стадии эксплуатации и сопровождения КСЗ осуществляется мониторинг, результаты которого являются (при необходимости) входом для стадии сопровождения (модификации, модернизации), которая включает все стадии ЖЦ КСЗ.

Под управлением ЖЦ системы защиты понимается комплексное решение задач, обозначенных в пунктах 1–3. На рисунке 2 показано соответствие стадий ЖЦ ИС и системы защиты с отражением тех задач, которые предлагается решать при проработке стадий ЖЦ КСЗ от процедур формирования требований до ее сопровождения.

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

Рис. 2. Схема совмещения жизненного цикла ИС и КСЗ

Управление безопасностью должно основываться на тезисе, что защищаемыми активами являются именно бизнес-процессы. Это дает возможность:

• обеспечить непрерывность бизнеса, так как приоритеты политики безопасности определяются относительно бизнес-процессов предприятия,

• оценить важность бизнес-процессов и данных, которые ими обрабатываются,

• оценить ущерб от нарушения работоспособности бизнес-процессов вследствие реализации информационных угроз,

• сформулировать целевую функцию для КСЗ как обеспечение безопасности S_i-ых бизнес-процессов в виде свойств конфиденциальности (K), целостности (С), доступности (D) и т.п., которые могут быть измерены, по крайней мере, в лингвистических шкалах.

Разработка требований для КСЗ также включает этап консалтинга, где определяются генеральные стратегии и целевая функция системы в целом . Для формирования требований безопасности необходимо декомпозировать вектор целевой функции для каждой «клетки» плоскостей модели ОЗ. Тем самым получим межкатегорийную плоскость требований ТР (требования) по безопасности.

Представление объекта защиты в виде модели OSE/RM позволяет на этой же стадии сформировать модель угроз на референтном уровне и конкретизировать ее при детальном проектировании.

Концептуальное проектирование системы, которое предполагает построение ее функциональной архитектуры, для аспекта безопасности заключается в проектировании КСЗ на уровне защитных механизмов (Мх), обеспечивающих целевую функцию . Под механизмом защиты понимается способ обеспечения целевой функции без указания его конкретной реализации. Таким образом, основная цель этого этапа – собрать межкатегорийную плоскость Мх. В эту плоскость войдут механизмы, соответствующие только тем «клеткам» платформы, которые используются приложением (бизнес-процессом) для реализации своих функций. Такие «клетки» определяются процессной моделью [1]. При этом оценивается достаточность уровня безопасности, обеспечиваемого штатными средствами защиты, встроенными в программные компоненты будущей ИС.

Детальное проектирование ИС заключается в построении системотехнической структуры, выборе программно-аппаратных продуктов или разработке кодов согласно плоскости <ИС>, их интеграции и настройке. Для КСЗ речь идет о построении проектной плоскости <З>, то есть о разработке проекта КСЗ на уровне СЗ, воплощающего защитные механизмы. Одновременно конкретизируется и модель угроз.

Далее происходит интеграция и внедрение в эксплуатацию единого объекта, назначение которого состоит: в решении бизнес-задач предприятия посредством прикладных приложений плоскости <ИС>; в администрировании платформенных компонентов (плоскость <А>); в защите объекта (плоскость <З>) от информационных угроз.

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

• КСЗ нейтрализовала атаку, но изменились целевые установки безопасности;

• КСЗ пропустила атаку, и необходимо скорректировать модель угроз;

• КСЗ работает нормально, но изменился способ организации бизнеса.

В любом случае время от времени КСЗ необходимо модифицировать, а если не удалось противостоять атаке, следует осуществить ряд мероприятий, направленных на восстановление бизнес-процессов. Таким образом, можно говорить об итерационности (последовательности) выполнения описанных задач.

Система управления безопасностью информационной системы

В целях повышения оперативности, полноты, достоверности и устойчивости информационного обеспечения процессов управления жизненным циклом КСЗ необходима компьютерная поддержка решения указанных задач в виде системы, которую назовем системой поддержки управления безопасностью (СПУБ) ИС. Такая система требует двух принципиально различных функциональных частей: инструментальной – в виде системы поддержки принятия решений (СППР) при формировании требований и проектировании КСЗ, и целевой. К целевым отнесем компоненты, осуществляющие управленческие и прикладные функции: мониторинг окружающей обстановки, оперативное управление при эксплуатации системы защиты; хранение данных и знаний; администрирование всеми указанными компонентами. Поэтому в состав СПУБ входят следующие программные средства (рис. 3).

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

Рис. 3. Функционально-структурная схема системы поддержки управления безопасностью

2. Система поддержки принятия решений при проектировании КСЗ определяет цели и критерии безопасности, генерирует и оценивает варианты комплексной защиты, то есть стратегии реализации целей, предлагает эти варианты лицам, принимающим решения, и экспертам для согласования и окончательного выбора.

3. Система управления осуществляет оперативные воздействия в случае инцидента, зафиксированного системой мониторинга. Эти воздействия заключаются в сдерживании развития инцидента, его ликвидации, восстановлении функционирования бизнес-процессов, инициации процесса перепроектирования КСЗ.

4. Информационное обеспечение СПУБ включает базы данных, базы знаний, хранилища информации долговременного и оперативного характера: накопленные данные об инцидентах безопасности, состоянии объекта защиты, мерах и средствах защиты, репозиторий моделей и проектов КСЗ.

5. Система администрирования обеспечивает взаимодействие, контроль и управление всеми составными компонентами СПУБ.

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

Итерационный алгоритм функционирования СПУБ

Этот раздел посвящен детальному описанию задач управления жизненным циклом КСЗ и их взаимосвязи в рамках единого алгоритма функционирования СПУБ. Алгоритм включает следующие шаги.

Формирование требований

Шаг 1. Определение приоритетов в организации защиты ИС, то есть выбор руководителем генеральной стратегии, например, одной из приведенных ниже.

• Стратегия наибольшей безопасности. Пусть – целевые векторы безопасности, которую должна обеспечить система защиты. Стратегия ориентирована на выбор вариантов КСЗ на основе обеспечения по максимуму векторов . Тогда можно ожидать, что величина ущерба U от нарушений безопасности ресурсов ИС будет достаточно низкой, но стоимость такой системы – немалой .

• Стратегия приемлемого риска и приемлемой стоимости, когда уровень безопасности определяется из уровней ущерба U^* и риска R^*, которые организация готова допустить при нарушении безопасности .

• Стратегия пороговой стоимости St^порог – выбор вариантов КСЗ в случае, когда приоритетом организации является экономия. Тогда надо быть готовым к невысокому уровню безопасности и значительному ущербу .

• Стратегия приемлемой стоимости, когда выбираются такие защитные средства, стоимость которых St не превосходила бы возможного ущерба U^*. Очевидно, что в этом случае уровень безопасности будет колебаться в пределах от минимально до максимально возможного .

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

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

Шаг 2. Определение требований безопасности к КСЗ, то есть целевых векторов критериев безопасности S_i-х бизнес-процессов (уровень ИС в целом) . Компоненты вектора представляются свойствами конфиденциальности, целостности, доступности и т.п. и определяются исходя из интересов бизнеса, нормативных документов и оценок угроз. Здесь же происходит назначение требуемого уровня безопасности, то есть определяются значения критериев по S_i-му бизнес-процессу (здесь Т^* – значения критериев по соответствующим измерительным лингвистическим шкалам). Параллельно экспертами строится модель угроз.

Шаг 3. Декомпозиция целевых векторов по компонентам модели ИС. Речь идет о том, чтобы интерпретировать компоненты вектора к «клеткам» плоскостей <ИС>, <А>, <З> модели OSE/RM, так как защитные механизмы специфичны для каждой «клетки». Например, обеспечение конфиденциальности для «клетки» «Экранные формы» предполагает ограничение доступа к экранным формам приложения посредством: а) ограничения физического доступа пользователя к экрану компьютера, на котором отображаются формы, б) ограничения доступа процессов, происходящих в системе, к коду экранных форм приложения, а для «клетки» «Процессы системно-прикладного слоя» – посредством ограничения доступа со стороны соответствующих API-функций приложения к процессам системно-прикладного слоя.

Проектирование

Шаг 4. Концептуальное проектирование. На этом этапе решаются две задачи:

задача 1 – выбор набора защитных механизмов (Мх₁, Мх₂,…, Мх_р ), которые будут обеспечивать безопасность в соответствии с генеральной стратегией – либо , либо некоторый уровень ;

задача 2 – распределение механизмов (Мх₁, Мх₂,…, Мх_р ) и средств по компонентам («клеткам») модели OSE/RM, то есть сборка межкатегорийной плоскости защиты модели [1] с учетом специфики реализаций «клеток» и процессной модели информационных операций, реализующих функции приложения.

Шаг 5. Детальное проектирование. Здесь выбираются программно-аппаратные СЗ , реализующие механизмы межкатегорийной плоскости с учетом совмещения программных интерфейсов прикладных и платформенных компонентов СЗ. В результате формируется проектная плоскость защиты модели OSE/RM (рис. 4), которая включает:

• прикладные приложения и аппаратные компоненты СЗ, входящие в КСЗ,

• БД и БЗ, обеспечивающие работу алгоритмов СЗ,

• общее хранилище данных,

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

Рис. 4. Представление системы защиты в виде проектной плоскости модели OSE/RM

Эксплуатация и сопровождение

Шаг 6. Далее наступает этап эксплуатации спроектированной КСЗ. Контроль над ситуацией осуществляет система управления безопасностью совместно с системой мониторинга. На этом этапе решаются следующие задачи:

• запуск на работу КСЗ, контроль и управление ее функционированием;

• если произошло вторжение, которое пропустила КСЗ и зафиксировала система мониторинга безопасности бизнес-процессов, необходимо: применить меры оперативного сдерживания вторжения, ликвидировать факт атаки, восстановить работоспособность бизнес-процессов.

Шаг 7. Перепроектирование КСЗ следует осуществлять в следующих случаях: если произошло вторжение либо вследствие а) того, что нарушитель оказался умнее и смог найти уязвимость, не обнаруженную при проектировании, б) неточности экспертных оценок компонентов модели угроз или целевых векторов ; либо вследствие изменения условий ведения бизнеса (изменение функций бизнес-процессов или всего процесса; тогда модификации подлежит и прикладная ИС) и/или целевого вектора . Поэтому необходимо внести соответствующие изменения в БЗ факторов безопасности и бизнес-процессов и инициировать систему поддержки принятия решений для осуществления очередной итерации жизненного цикла КСЗ.

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

Основой совмещения жизненных циклов обеих систем является модель отрытой среды OSE/RM, которая позволяет представить целевую ИС и систему защиты в виде единого интегрированного объекта. Разработка системы защиты на базе совмещения ЖЦ позволяет обеспечить комплексность реализации КСЗ в соответствии со стратегиями поддержки безопасности в отличие от бессистемного использования штатных средств защиты в составе поставляемых отдельных компонентов ИС (операционных систем, баз банных, приложений и т.п.).

Литература

1. Лукинова О.В. Методология проектирования систем защиты, построенных на основе референтной модели POSIX OSE/RМ //Системы высокой доступности. 2012. № 3.

2. IEEE Std 1003.0-1005, IEEE Guide to the POSIX Open System Enviroment (OSE).
N-Y.: The Institute of Electrical and Electronics Engineers, 1995.

3. ГОСТ Р ИСО/МЭК 12207-11 Информационная технология. Процессы жизненного цикла программных средств. Стандартинформ, 2011.

4. ГОСТ 34.601.90. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания. Госстандарт СССР, 1990.

5. ГОСТ Р ИСО/МЭК 15288-05. Информационная технология. Процессы жизненного цикла систем. Стандартинформ, 2006.

6. Бойченко А.В., Лукинова О.В. Когнитивный подход к анализу влияния факторов информационной безопасности //Труды 7-й Международной научно-практической конференции «Интегрированные модели и мягкие вычисления в искусственном интеллекте». М.: Физматлит, 2013. Т. 2. С. 583–586.

______________________________________

ЛУКИНОВА Ольга Васильевна

Кандидат технических наук, доцент, старший научный сотрудник Института проблем управления им. В.А. Трапезникова РАН