CC BY
30
6. Веб-портал кафедры автоматизированных систем управления ГОУ ВПО УГАТУ. -http://asu.ugatu.ac.ru
УДК 004.056, 004.838.2
КОМПЬЮТЕРНЫЕ МЕТОДЫ МОНИТОРИНГА И АНАЛИЗА ЗАЩИЩЕННОСТИ ПРИ ФУНКЦИОНИРОВАНИИ АВТОМАТИЗИРОВАННЫХ БИЗНЕС-ПРОЦЕССОВ КОМПАНИИ
О. В. Лукинова, к. т. н., с. н. с.
Тел.: (495) 334-89-70, e-mail: lobars@mail.ru Институт проблем управления им. В. А. Трапезникова РАН
http://www.ipu.ru
The author considers computer-based monitoring, preceding the design of the information security system of the automated business processes of the company. The author describes a scheme of analysis of monitoring parameters, which could solve the problem of the need to design such a system, made from POD (payment forward).
Рассмотрены компьютерные методы мониторинга, предваряющего проектирование системы информационной безопасности автоматизированных бизнес-процессов компании. Описана схема анализа параметров мониторинга, которая позволяет решить вопрос о необходимости проектирования такой системы, построенной из наложенных средств.
Ключевые слова: система информационной безопасности, мониторинг бизнес-процессов, оценочные критерии, штатные и наложенные средства защиты.
Keywords: information security system, monitoring of business processes, assessment criteria, state, POD means of protection.
1. Введение
Формализация методов формирования и принятия решений при проектировании системы безопасности современных информационных систем (ИС) является весьма непростой задачей. Это, с одной стороны, объясняется сложностью и, как следствие, опасностью самих ИС, характеризуемых многоуровневыми архитектурами, распределенностью, использованием внешних сервисов и предоставлением во внешний мир своих, ограниченными временными рамками и т. д. С другой - сам процесс принятия решений, учитывающий целый спектр противоречивых факторов, включающий вопросы законодательного, административного, процедурного, программно-технического аспектов, не менее сложен, чем сам объект защиты.
Увеличение объема информации, которую необходимо проанализировать экспертам, усложнение решаемых задач, необходимость учета большого числа взаимосвязанных факторов требуют использования вычислительной техники в процессе принятия ре-
шений. В связи с этим появился новый класс систем - систем поддержки принятия решений (СППР), основанных на формализации методов получения объективных и субъективных оценок, алгоритмизации рассуждений, анализа ситуаций, выработки вариантов решений. Одной из задач СППР при организации защиты является мониторинг параметров функционирования объекта защиты, на основании анализа данных которого решается вопрос о необходимости проектирования системы безопасности обследуемого объекта.
В статье определены области функционирования объекта защиты, параметры которых должны быть подвергнуты процедуре мониторинга; сформулированы задачи, стоящие перед подсистемой мониторинга, описа-
ны компьютерные процедуры и алгоритмы анализа, использующие аппарат субъективных оценок.
2. Описание объекта защиты
В [1] подчеркивалось, что основными защищаемыми активами компании являются бизнес-процессы, совокупность которых ассоциируются с корпоративной информационной системой (КИС).
При организации защиты активов КИС может быть две ситуации:
1. Информационная система находится в стадии разработки, и одновременно с ней происходит проектирование защиты как межкатегорийного сервиса [2] ИС. Тогда речь следует вести не о мониторинге, а скорее, о прогнозировании параметров функционирования бизнес-процессов включая и параметры безопасности.
2. Информационная система находится в стадии эксплуатации, и стоит задача спроектировать для ее бизнес-процессов систему безопасности. Именно эта ситуация и рассматривается в данной работе.
Понятие бизнес-процесса включает: а) некоторую семантику, реализуемую бизнес-логикой (виды деятельности и их взаимосвязь); б) среду функционирования, которую можно представить моделью OSE/RM (Open system environment/reference model) группы POSIX (Portable Operating System Interface for Unix), представляющую собой трехмерную логическую (справочную, эталонную, рефе-ренсную) структуризацию функциональности информационной системы и описанную в [2, 3] (на рис. 1 представлен пример некоторых реализаций «клеток» модели). Уровни описания в данной модели следующие:
- компоненты служб и сервисов промежуточного слоя (MW);
- компоненты операционных систем или операционного слоя (OW);
- аппаратный слой (HW).
Функциональные группы компонентов в
данной модели по вертикали составляют:
- компоненты, обеспечивающие интерфейс с пользователем (User - «U»);
- компоненты, реализующие все необходимые процессы в системе (System - «S»);
- компоненты, осуществляющие организацию, представление, доступ и хранение данных (Information - «I»);
- компоненты телекоммуникационной среды, обеспечивающие взаимосвязь информационных систем (Communication - «C»). Данный уровень представляет собой модель взаимосвязи от-
крытых систем (OSI/RM - Open System Interconnection/Reference Model).
Компоненты среды определяют параметры функционирования бизнес-процесса, а с точки зрения информационной безопасности она является носителем различного рода уязвимостей, которые используются нарушителем для проникновения в КИС.
Рис. 1. Модель OSE/RM
Первый этап, с которого следует начать проектирование защиты бизнес-процессов, это мониторинг и анализ состояния среды бизнес-процессов. Задачами подсистемы мониторинга СППР при проектировании системы безопасности являются: систематическое накопление данных о функционировании бизнес-процессов, обработка и анализ этих данных, представление результатов анализа в виде, удобном для ЛПР.
Анализ осуществляется с целью определения необходимости организации дополнительной защиты тому или иному бизнес-процессу. Проводить его будем по следующим направлениям:
1. Идентификация и оценка ценности информационных ресурсов бизнес-процесса КИС.
2. Загрузка вычислительных ресурсов бизнес-процесса.
3. Опасность среды бизнес-процесса с точки зрения проникновения нарушителя, ее уязвимость.
4. Защищенность, которая обеспечивается встроенными в среду средствами защиты.
3. Оценка ценности информационных ресурсов, обрабатываемых бизнес-процессом
Прежде всего следует заметить, что ценность информационных ресурсов и ущерб от
компрометации этих ресурсов - это две стороны одной медали. Например, если клиентская БД страховой компании попала в руки конкурентов, компания понесет ущерб в объеме недополученных страховых сборов. Поэтому оценка ценности ресурсов одновременно влечет и оценку ущерба от компрометации этих ресурсов.
К информационным ресурсам, в первую очередь, относится так называемый интеллектуальный капитал (ИК) организации включая нематериальные активы. В [11] определен следующий состав ИК:
1. Рыночный, т.е. активы предприятия, связанные с рыночными операциями, обеспечивающими конкурентные преимущества (данные по клиентам, поставщикам, партнерам по бизнесу, репутация компании и т. д.).
2. Структурный, который включает объекты интеллектуальной собственности (патенты, авторские права, производственные, инновационные, управленческие секреты и т. д.) и активы, формирующие рабочую среду фирмы (корпоративные, технологические, производственные стандарты, бизнес-правила, учетные политики и т. д.)
3. Человеческий капитал, воплощающий коллективные и индивидуальные знания компании, но контекст безопасности - это законодательная охрана персональных данных.
Перечисленные интеллектуальные
активы в виде различных по семантике БД, хранилищ, отдельных файлов привязаны как внешние сущности к бизнес-процессам и, стало быть, включаются в состав реализаций соответствующих «клеток» модели OSE/RM. Таким образом осуществляется
структуризация ИК, в результате чего все информационные ресурсы КИС ставятся в соответствие «клеткам» платформенной компоненты, а именно столбцу Information того или иного бизнес-процесса.
Кроме того, при оценке ущерба следует принять во внимание и тот факт, что он может произойти и в случае, если какая-либо функция бизнес-процесса перестанет работать. Поэтому при оценке ценности/ущерба к информационным ресурсам отнесем не только активы ИК, но и исполняемые коды ПО.
Ценность/ущерб может выражаться как в денежном, так и в неденежном исчислении (например, санкции, которые понесет руководитель за нарушение закона о защите персональных данных). Поэтому есть смысл перейти к обобщенному показателю «приоритет ресурса» Pr, который будет измеряться лингвистической или балльной
шкалой: «высокий - 4», «средний - 3», «низкий - 2», «очень низкий - 1», «отсутствует - 0» (через тире здесь и далее в лингвистических шкалах приведены балльные оценки).
Оценочные критерии при определении значений приоритета Pr активов могут быть следующие:
^. Нормативные акты, которые регламентируют актив: «закон РФ - 4», «ГОСТ -3», «РД - 2», «внутренние документы - 1», «отсутствует - 0» (этот критерий имеет свою лингвистическую шкалу, но она вполне согласуется с общей).
Конкурентные преимущества.
Объем недополученного дохода.
^ Степень личной ответственности ЛПР.
Степень юридической ответственности.
^ Стоимость восстановления кодов.
K1. Стоимость восстановления аппаратных средств.
Потери от компрометации бренда.
K9. Стоимость восстановления данных и т. д.
Состав списков критериев определяется семантикой функций бизнес-процессов и может быть предварительно сгенерирован в подсистеме моделирования бизнес-процессов.
Далее по каждому активу «клетки» подсистема мониторинга предлагает предварительные списки каждому эксперту, которые они могут утвердить или модифицировать. После этого СППР проводит процедуру согласования списков экспертов. Алгоритмы согласования хорошо известны, а в систему их может быть заложено несколько, с тем чтобы ЛПР мог выбрать процедуру согласования. На рис. 2 приведена блок-схема процедуры
согласования, проводимой СППР, которая включает блоки автоматического и ручного согласования [4].
Комментарии к блокам, требующим пояснения:
Блок 2 проводит сравнение экспертных списков и создает два списка параметров: список А, в который вошли критерии, выбранные всеми экспертами, и список В, содержащий все остальные критерии. Список В подлежит дальнейшему согласованию.
Блок 4 проверяет номер итерации. Если итерация первая - переход к блоку 5, если нет - к блоку 7. Вообще итераций может быть сколь угодно много, но опыт показывает, что на последующих итерациях скорость сходимости падает или сближение оценок вообще прекращается. Поэтому после первой
(или первых) итераций лучше перейти к какому-либо методу их автоматического согласования.
Блок 7. Автоматическое согласование, проводимое СППР с использованием процедур голосования, тогда в списке остаются те критерии, которые прошли ту или иную процедуру голосования. В настоящее время в литературе описано достаточно много процедур голосования, с которыми можно ознакомиться, например, в [5].
Рис. 2. Блок-схема процедуры согласования
Важно отметить, что от выбора процедуры может зависеть ее результат, поэтому выбор процедуры либо тоже согласовывается, либо определяется руководителем.
Пусть после первой итерации ЛПР решил провести голосование по правилу абсолютного большинства, т. е. считать согласованными те критерии, за которые проголосовали больше половины экспертов. СППР сравнивает перечень параметров в списке В и определяет число экспертов, давших одинаковые оценки. Оказалось, что у большинства экспертов оценки совпадают. Система запи-
сывает эти оценки в список А, ликвидируя список В.
Процедура согласования списка критериев по «клеткам» закончена.
В табл. 1 приведен пример согласованных оценок приоритета ресурсов «клеток» 5,-го бизнес-процесса по списку критериев К1, К-2, Кз.
Здесь РгК1(Б1), РгК2(Б1), РгКз(Б1) -приоритеты бизнес-процесса по критериям К1, К2 и К3 соответственно, которые считаются как средние по столбцу.
Таблица 1
Идентификатор «клетки» бизнес-процесса Критерий Рг(Кр)
Нормативные акты Конкурентные преимущества Объем недополученного дохода
Р РД - 2 Очень низкий - 1 Средний - 3 1.92
Кр ГОСТ - 3 Средний - 3 Высокий - 4 3.09
Средние значения РгК1(Б,) РгК2(8,) РгКз(Б,)
Последний столбец таблицы содержит приоритеты «клеток», которые представляют собой линейные функции
Рг(Кр) = х «Л , (1)
где ар5 - вес критерия, хр5 - значения критерия, а также совокупную оценку приоритета всего
1 р
бизнес-процесса Рг$,) = —XРг(К ), которая
Р р=1
потребуется в дальнейшем при ранжировании целей безопасности.
Далее следует определить значимость критериев, их вес ар5. Для этого можно использовать известные методы [4] или каждому эксперту заполнить таблицу рангов (значимости). Ранг критерия определяет, какова, по мнению экспертов, его важность (табл. 2).
Таблица 2
Идентификатор «клетки» бизнес-процесса Si Важность критерия
Нормативные акты Конкурентные преимущества Объем недополученного дохода
Ki Высокая - 3 Низкая - 1 Средняя - 2
Кр Низкая - 1 Средняя - 2 Очень высокая - 4
В табл. 1 и 2 все значения критериев иллюстративного примера представлены в лингвистической форме (через тире даны их балльные соответствия). Для дальнейшего анализа потребуется балльная форма оценок, обычно такой перевод подсистема мониторинга делает автоматически.
Таблицы типа 1 и 2, определяющие балльные или лингвистические оценки критериев и их веса, составляются экспертами заранее и согласовываются в подсистеме предпроектного проектирования СППР.
После того, как каждый эксперт проставил ранги в таблицах 2 для каждой «клетки» СППР определяет сумму рангов, набранным
каждым критерием:
з
грв = X ГЛ , где - ранг 5-го критерия,
} =1
определенный ]-м экспертом для р-й «клетки», п5 - число экспертов, давших данную оценку критерию, а также вес критерия, т. е нормированную
г
Vs
сумму рангов a =
£r
Fs
В итоге получим табл. 3, последний столбец которой содержит значения весов ар5 из (1).
Таблица 3
Идентификатор «клетки» бизнес-процесса Si Оценка важности критерия Сумма рангов критериев rpj Нормированный вес apj
Нормативные акты Конкурентные преимущества Объем недополученного дохода
n=4 n=3 n=2 n=1 n=5 n=2 n=2 n=1 n=4 n=3 n=2 n=1 K, K2 K3 K1 K2 K3
Ki 3 2 4 1 4 2 3 1 2 4 1 3 27 31 25 0.33 0.37 0.3
Кр 2 4 3 2 3 4 1 2 1 1 2 3 28 27 14 0.41 0.39 0.2
4. Оценка загрузки вычислительных ресурсов бизнес-процесса
Мониторинг загрузки вычислительных ресурсов среды бизнес-процесса необходимо осуществлять с двумя целями. Первая - фиксация эталонных значений, т. е. определение штатного режима функционирования параметров среды, осуществляется стандартными программными средствами. В дальнейшем это позволит СППР оценивать отклонения текущих значений от эталонных и определять наличие инцидентов безопасности.
Параметры, по которым отслеживается загрузка вычислительных ресурсов, структу-
рируются в соответствии с базовой плоскостью платформенной части модели OSE/RM. Оценку этих параметров целесообразно производить по следующим критериям:
1. Степень загрузки того или иного оборудования (производится по аппаратному слою ре-ференсной модели - рис. 1).
2. Степень разбалансировки загрузки сетевого оборудования (столбец Communication) и оборудования столбцов User, System, Information.
3. Отклонение от штатных значений и т. д.
Измеряются критерии по лингвистической однородной шкале «отсутствует - 0»,
s
s
«низкая - 1», «средняя - 2», «высокая - 3», «критическая - 4».
Вторая цель - утилитарная. Системный администратор, имея списки подключенных модемов, сканирующих программ, открытых портов, сетевых сервисов и т. д., может провести анализ на защищенность/незащищенность, легитимность /нелегитимность, нужность/ненужность соответствующих объектов.
5. Оценка параметров уязвимости среды бизнес-процесса
Среда, которая представляется «клетками» платформенной компоненты OSE/RM, подвержена влиянию ряда объективных факторов, декларируемых стандартами [6] :
• угрозы информационной безопасности со стороны среды бизнес-процесса Y(S), где i = 1 ^ I, а I - число автоматизированных бизнес-процессов предприятия, характеризующиеся вероятностью возникновения и вероятностью реализации;
• уязвимости „среды Хизнехпроцесса или системы контрмер X = (,х2,...,хп), влияющие на вероятность реализации угрозы;
• нарушитель, определяющий вероятность возникновения угрозы;
• риск - фактор, отражающий возможный ущерб в результате реализации угрозы.
Пусть Р(А( xi )) - вероятность реализации той или иной угрозы. Здесь А( X ) - событие, интерпретируемое как использование нарушителем уязвимости X, U(Si) - величина возможного ущерба при нарушении штатного функционирования бизнес-процесса Si. Тогда количественный уровень риска определяется как функция R(Si) = f (Р(А( хг )), U(S,))).
При этом вероятностные оценки будем делать в рамках субъективного подхода, который рассматривает вероятность как субъективную меру убежденности наблюдателя, соответствующую его знаниям и опыту, в истинности или ложности предложенного ему утверждения [7]. Тогда оценку меры риска Risk(Si), присущего бизнес-процессу, можно определить как произведение оценки угрозы Y(Si) на оценку ценности/ущерба Pr(Si):
Далее для х, СППР получает общую оценку (рейтинг уязвимости) по алгоритму, который использует аддитивную функцию, т. е. выбранные значения по обоим действиям
Risk(Si) = Y(Si) х Pr(Si).
Итак, среда бизнес-процесса несет угрозы его безопасности, т. к. является носителем уязвимостей Х, т. е. тех огрехов в ПО или защите, которые могут быть использованы нарушителем. Рассматриваются два типа уяз-вимостей: технологические - это «дыры» в программном коде платформенной или прикладной компонент, появляющиеся на стадии разработки ПО, или самих средств защиты, и эксплуатационные.
Уязвимости являются основной предпосылкой нападения нарушителя и существуют объективно на момент планирования защиты. Стало быть, анализирующий блок подсистемы мониторинга должен оценить ту долю риска, который присущ среде вследствие имеющихся уязвимостей. Алгоритм оценки может быть следующий.
1. С помощью определенного ПО (сканеры уязвимостей) для конкретной реалииза-ции среды бизнес-процесса на стадии пред-проектного проектирования СППР выявляются перечни уязвимостей X = (X, х2 ,...,хп ) и ставятся в соответствие «клеткам» OSE/RM.
2. Любой уязвимости X можно сопоставить два действия [8]: сначала идентифицировать уязвимость, а затем ее использовать. С точки зрения этих действий X характеризуется следующими параметрами:
a) временем, которое необходимо для совершения этих действий;
b) необходимой квалификацией;
c) уровнем знаний о среде;
d) характером и продолжительностью доступа к среде;
e) необходимыми аппаратно-программными ресурсами.
Для каждого критерия в СППР имеются согласованные экспертами оценочные балльные шкалы, разработанные на основе [8] (в табл. 4 приведен пример шкалы по критерию а, оценочные шкалы остальных критериев можно посмотреть там же).
Таблица 4
по всем таблицам суммируются. Если уязвимость можно идентифицировать/использовать несколькими способами, для каждого из них вычисляется рейтинг и из полученных
Время Идентификация уязвимости Использование уязвимости
< 0.5 часа 0 0
< суток 2 3
< месяца 3 5
> месяца 5 8
значений выбирается минимальное, т. е. уязвимости ставится в соответствие самый простой метод успешного нападения. По этому же правилу по всем xi «клетки» вычисляется общий рейтинг Яклетки,
3. По тому же принципу вычисляется потенциал нарушителя ИР. В [8] этот потенциал с учетом правила максимума ИР = тах(ЫР1 ,ИР2,...,№") (из нескольких
6. Оценка защищенности встроенными средствами
Защита среды бизнес-процессов от несанкционированного вмешательства в процессы их функционирования обеспечивается специальными механизмами. В литературе [6, 10] описываются следующие защитные механизмы (Мх):
1. Идентификация и аутентификация пользователя.
2. Разграничение доступа пользователей к ресурсам.
3. Мониторинг и аудит событий, происходящих в системе.
4. Криптографическая поддержка (шифрование) хранимых и передаваемых данных.
5. Контроль целостности и аутентичности (подлинности и авторства) хранимых и передаваемых данных.
6. Экранирование компьютерной сети или отдельного компьютера, т. е. защита периметра.
7. Анализ защищенности, т. е. выявление и анализ уязвимостей среды бизнес-процесса.
8. Обеспечение отказоустойчивости (живучести) среды бизнес-процессов, т. е. способности сохранять требуемую работоспособность, несмотря на отказ отдельных элементов.
9. Способность к восстановлению.
10. Туннелирование, т. е. «упаковка» передаваемого пакета данных в новый «конверт».
11. Уничтожение остаточных данных.
12. Выявление и нейтрализация вирусов.
13. Обнаружение компьютерных атак.
т. е. Яклетки = тт(Ях ,ЯХ2 ,...,Ях* ), где
Ях - рейтинг уязвимостей, принадлежащих данной «клетке».
Оценочная шкала рейтинга уязвимостей приведена в табл. 5.
Таблица 5
сценариев нападения выбирается худший вариант, с наибольшим потенциалом) определяется оценками табл. 6.
Таблица 6
14. Управление, обеспечивающее согласованное функционирование средств защиты.
Каждый механизм реализуется методами, алгоритмы которых и обеспечивают тот или иной уровень защиты. Традиционно уровень защиты принято определять стойкостью механизмов. Под стойкостью понимается характеристика, отражающая минимальные усилия нарушителя, необходимые для нарушения безопасности, обеспечивающейся данным механизмом [6, 9]. Параметр оценивается шкалой «Стойкость»: «базовая - 1», «средняя - 2», «высокая - 3».
В свою очередь, совокупности механизмов реализуются в виде тех или иных средств защиты, которые делятся на два класса:
1. Механизмы, встроенные (штатные) в покупаемое программное обеспечение. Многие программные и аппаратные средства, которые реализуют «клетки» референсной модели, имеют встроенные защитные механизмы, реализованные программно и установленные разработчиками этих средств: операционные системы, СУБД, различные приложения реализуют механизмы идентификации и аутентификации, обладают свойствами межсетевых экранов, средствами шифрования и т. д. Таким образом, на момент проектирования системы безопасности среда бизнес-процесса в той или иной мере защищена. Стало быть, одной из задач мониторинга яв-
Диапазон Яклетки Рейтинг уязвимости
< 10 Низкий - 1
10-17 Умеренный - 2
18-24 Высокий - 3
> 24 Нереально высокий - 4
Диапазон потенциала Потенциал нарушителя
< 10 Низкий - 1
10-17 Умеренный - 2
18-24 Высокий - 3
> 24 Нереально высокий - 4
ляется определение уровня защиты, которую могут обеспечить штатные средства.
2. Наложенные, т. е. реализованные как самостоятельные программные или программно-аппаратные комплексы и устанавливаемые дополнительно.
На стадии предпроектного проектирования подсистема мониторинга в интерактивном режиме опрашивает экспертов и сопоставляет каждой «клетке» реализованные в ней штатные механизмы. СППР заполняет таблицу стойкости типа табл. 7.
Таблица 7
Идентификатор «клетки» бизнес-процесса St Стойкость механизмов S(Mxk) S(Mxp)
Мх1 Мхк
1 2 к к +1
Ki Высокая - 3 Базовая - 1 Умеренная
Кр Средняя - 2 Механизм отсутствует Средняя
Средняя стойкость S(Mxk) Средняя - 2 Базовая - 1 S(Mx)
Здесь Б(Мхк) - стойкость к-го защитного механизма;
Б(Мхк ) - средняя стойкость к-го механизма по бизнес-процессу, вычисляется по недостатку
по шкале «Стойкость» 8(Мхк ) =
р Ихр
оценки механизмов по столбцам 2 ^ k;
S(Mxp) - совокупная стойкость механизмов, соответствующих р-й «клетке» - представляет собой суждения экспертов о величине синергетического защитного эффекта от влияния механизмов друг на друга. Например, туннелирование по протоколу IPv6 над стандартным TCP/IP дает достаточно низкую безопасность по конфиденциальности при передаче данных, но вкупе с механизмом шифрования уровень конфиденциальности резко повышается, а если на концах канала передачи установить межсетевой экран, то получим одно из самых надежных средств защиты - виртуальную частную сеть VPN.
Оценка S(Mxp) производится экспертами следующим образом:
1. Каждый эксперт на основании столбцов 2 k выставляет совокупную оценку. Для этого вводится шкала «Совокупная стойкость»: «низкая - 1», «умеренная - 2», «высокая - 3», «очень высокая - 4», т. к. шкала «Стойкость», предлагаемая стандартами [6, 9], не обеспечивают однородности оценочных шкал.
2. Согласование совокупных оценок по вышеприведенному алгоритму. В табл. 7 приведен пример согласованных оценок.
S(Mx) - средняя совокупная стойкость механизмов бизнес-процесса, вычисляется по недостатку как среднее по столбцу 5
1
S(Mx) =
Р1х?
xp - совокупные оценки
механизмов по столбцу к + 1.
7. Анализ параметров мониторинга
Анализ взаимосвязей параметров мониторинга позволяет решить вопрос о достаточности/недостаточности штатных механизмов.
Итак, в результате мониторинга получим распределение параметров по референсной модели, представленное на рис. 3, где каждая «клетка» оценивается рейтингом уязвимостей ^клатш, потенциалом нарушителя ЫР, который
может воспользоваться уязвимостями Х клет" ки, стойкостью Б(МхР) защитных средств и приоритетом ресурсов Рг(Кр), сопоставленных данной «клетке».
MW
SW
HW
Л"™"' Д™"™ Л™"
S(.MxJ SfMxJ S(Mxj
NP NP NP
PrfKj PrfKj PrfKj
д™—™ Д™—"
SftfV wv WV
MP MP NP NP
PrfKj PrfKj PrfKj PrfKj
JS"™"' л™"™
SfMxJ iV.l/j-^ ■V!»J S(M.v
NP NP NP NP
PrfKj PrfKj PrfKj PrfKj
User
Infoimation Communication
System
Я' "'""" - рейтинг уяэеимостей «клетки», S(Mxlt) " стойкость штатных механизмов защиты, ,YP - потенцчрп нарушителя, PrfKj - приоритет ресурсов чистки»
Рис. 3. Матрица параметров мониторинга в соответствии с моделью OSE/RM
Соотношение параметров определяется по следующим правилам [8]:
1. СППР рассматривает пару рейтинг «клетки» R"iemKU - потенциал нарушителя NP. Первое решающее правило гласит: нарушитель может совершить успешное нападение на ресурсы «клетки», если его потенциал не меньше рейтинга уязвимости, т. е. если рейтинг уязвимости имеет, например, оценку
«умеренный», то для успешного нападения потенциал нарушителя должен быть «высокий» (см. рис. 4).
5(Мхр)
Рис. 4. Схема сравнения параметров по правилам 1 и 2
Таким образом, условие успешного нападения заключается в том, что существует
ЫР= тах (ЫР}) такое, что Яклетки < ИР, где у -
]
тип нарушителя.
2. С другой стороны, нападение нейтрализует защитный механизм, обладающий определенной стойкостью, т. е. необходимо сравнить пару: потенциал нарушителя ИР -стойкость механизмов Б(МхР). Сравнение будем проводить следующим образом: если Б(МхР) >ЫР, то нападение нарушителя будет отражено защитным механизмом и уязвимости «клетки» не «сыграют».
Рис. 4 демонстрирует схему сравнения параметров Яклетки , ИР и Б(МхР) в нечетких шкалах по правилам 1 и 2.
Рис. 5. Возможные ситуации при реализации угроз
1. В результате проверки правил 1 и 2 для параметров ЫР, 8(МхР), Яшетки подсистема мониторинга делает вывод о степени реализации угрозы Ур для той или иной «клетки». При этом возможны следующие девять ситуаций:
А). Ситуация, когда угроза осуществима: потенциал нарушителя превосходит рейтинг уязвимости, а стойкость защитных механизмов недостаточна.
Б). Ситуация, когда угроза почти осуществима: рейтинг уязвимости равен потенциалу, а стойкость механизмов ниже потенциала нарушителя.
В). Ситуация, когда угроза, скорее всего, осуществима, т. к. в силу приближенности оценок правило 2 может не сработать.
Г). Очень возможно, что угроза реализуется, т. к. потенциал выше рейтинга уязвимостей, хотя стойкость выше потенциала.
Д). Пограничная ситуация, когда потенциал нарушителя, рейтинг уязвимостей и стойкости механизмов соответствуют друг другу, но в силу приближенности и субъективности суждений ситуация требует пристального внимания со стороны ЛПР.
Е). Правило 1 не включает ситуацию равенства рейтинга и потенциала, но субъективность оценок требует, на наш взгляд, учета таких ситуа-
ций. За счет стойкости, превосходящей потенциал, угроза может остаться нереализованной.
Ж). Ситуация, когда угрозы, скорее всего, нет, т. к. рейтинг выше потенциала, но недостаточная стойкость влечет некоторую неуверенность в благоприятном исходе.
З). Угрозы почти нет, т. к. рейтинг выше потенциала, а стойкость ему соответствует.
И). Ситуация, когда угроза точно не может быть реализована, т. к. оба правила дают положи-
тельные исходы.
Рис. 5 демонстрирует графическое представление различных соотношений анализируемых параметров в соответствии с исходами правил 1 и 2.
Эти ситуации, отражающие степень реализации угрозы при наличии только штатных средств защиты, можно интерпретировать шкалой, представленной в табл. 7.
Таблица 7
Степень реализации угрозы Yp
Ситуация Обозначение Интерпретация и балльные оценки
А) ---- Угроза точно существует - 7
Б) ---+ Угроза почти существует - 6
В) - - + + Угроза, скорее всего, существует - 5
Г) - + + + Угроза, очень возможно, существует - 4
Д) Пограничная ситуация
Е) +--- Угрозы, возможно, нет - 3
Ж) + + - - Угрозы, скорее всего, нет - 2
З) + + + - Угрозы почти нет - 1
И) + + + + Угроза отсутствует - 0
2. Вообще говоря, на основании выводов, представленных подсистемой мониторинга в соответствии с проведенным анализом, СППР может принять решение о необходимости привлечения наложенных средств защиты. Но, в дополнение к полученным оценкам, она может осуществить и оценку тех рисков, которые ожидают компанию, если угроза реализуется с уверенностью Ур. Риск - это категория, зависящая не только от степени реализации угрозы, но и от объема ущерба (см. выше).
Тогда на основании оценок ущерба и угроз подсистема мониторинга реализует алгоритм расчета оценки риска среды для р-х «клеток»:
т$кр=РНкр)*Ур, , (2)
где Рг(Кр) - оценка ущерба, Ур - оценка угрозы, р = 1, ..., Р.
Вычисленное значение Riskp отображается на шкалу «Риск клетки», которая формируется из следующих соображений. Произведение оценок Рг на У может дать 20 возможных значений: 0, 1, 2, 3, 4, 6, 8, 9, 10, 12, 14, 15, 16, 18, 20, 21, 24, 28, которые СППР автоматически разносит по, например, 5-балльной шкале, отнеся 0, 1, 2, 3 к уровню риска «очень низкий»; 4, 5, 6, 7 - к уровню «низкий»; 8, 9, 10, 12 - к «средний»; 14, 15, 16, 18 - к «выше среднего»; 20, 21, 24, 28 - к «высокий». Если такое разнесение экспертов не устроит, в СППР предусматривается процедура ручного формирования шкалы риска и
разнесения по ней возможных значений Riskp.
Совокупный по бизнес-процессу риск Risk подсистема мониторинга может определять двумя способами (хотя могут быть заложены и другие алгоритмы):
1. Как среднее значение по «клеткам»:
Risk = — V Risk р .
Р Р
Г Р
2. Как мультипликативная функция с учетом важности риска для «клетки»:
Risk = ПаРRiskр . При этом СППР произво-
р
дит процедуру назначения и согласования весов «клеток» ар с точки зрения риска по алгоритмам, описанным ранее.
Стратегии, связанные с управлением рисками, из которых ЛПР производит выбор, могут быть различными, но существует четыре стандартных:
Стратегия 1. Пусть Risk* - некоторый порог риска по i-му бизнес-процессу, приемлемого для компании с точки зрения ЛПР. Тогда если Risk < Risk*, то по данному бизнес-процессу компания готова нести потери в случае атаки злоумышленника, но систему безопасности из дополнительных средств проектировать не нужно.
Стратегия 2. Ликвидация риска, т. е. сведение его к нулевому уровню.
Стратегия 3. Уменьшение риска до приемлемого уровня.
Стратегия 4. Переадресация риска - означает, что компания решает застраховать
риски, связанные с информационными атаками и дополнительные средства защиты.
Стратегии 2 и 3 работают при условии Risk > RiskЭто означает, что при неприемлемом риске в дополнение к защитным штатным средствам необходимы наложенные, т. е. нужно проектировать комплексную систему защиты (КСЗ) из наложенных и штатных средств, а стало быть, необходимо реализо-вывать процедуру определения целевых векторов безопасности
KS црель (K (Т *), C (Т *), D(T *)),
где К(Т*), С(Т*), D(T*) - уровни конфиденциальности, целостности, доступности соответственно, которые должна обеспечивать КСЗ для ресурсов, обрабатываемых бизнес-процессом.
Литература
Состав вектора безопасности продиктован тем, что информационная безопасность обеспечивается именно перечисленными основными свойствами данных в информационных системах.
8. Заключение
Таким образом, в статье описаны методы и алгоритмы, на основании которых компьютерная система может принять решение о необходимости привлечения дополнительных защитных механизмов, т. е. определяется целесообразность построения комплексной системы защиты как из встроенных, так и из наложенных средств.
1. Лукинова О. В. Формализация задачи планирования защиты распределенной компьютерной сети на основе бизнес-процессного подхода // Надежность, 2009. № 1. C. 72-80.
2. SO/IEC TR 14252-1996 Guide to the POSIX Open System Environment.
3. Бойченко А. В., Лукинова О. В. Применение модели POSIX OSE/RM при построении подсистем информационной безопасности // Интеллектуальные системы (AIS'10); Интеллектуальные САПР (CAD-2010): Труды международных научно-практических конференций. Т. 2. - М.: Физматлит, 2010. C. 473-476.
4. Трахтенгерц Э. А. Компьютерная поддержка формирования целей и стратегий. - М.: Синтег, 2005. 224 с.
5. Трахтенгерц Э. А. Компьютерные методы реализации экономических и информационных управленческих решений. Т. 1. - М.: Синтег, 2009. 172 с.
6. ГОСТ Р ИСО/МЭК 15408-2009. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. - М., 2009.
7. Трахтенгерц Э. А. Субъективность в компьютерной поддержке управленческих решений. - М.: Синтег, 2001. 256 с.
8. Common Methodology for Information Technology Security Evaluation. Part 2: Evaluation Methodology. Version 1.0 - CEM 99/045, August 1999.
9. Руководящий документ. Безопасность информационных технологий. Руководство по формированию семейств профилей защиты. - М.: Гостехкомиссия России, 2003.
10. Галатенко В. А. Основы информационной безопасности. - М.: Интуит, 2008. 205 с.
11. Мильнер Б. З. Управление знаниями. - М.: ИНФРА-М, 2003. 215 с.
УДК 004.94
ОСОБЕННОСТИ РЕАЛИЗАЦИИ ПРОЦЕССНОГО ПОДХОДА И ОБУЧЕНИЯ УПРАВЛЕНИЮ БИЗНЕС-ПРОЦЕССАМИ ПРИ ПОМОЩИ СВОБОДНОГО ПО С ОТКРЫТЫМ КОДОМ
Г. Г. Куликов, д. т. н. проф., зав. кафедрой АСУ Тел.: (347) 273-78-23, e-mail: gennadyg_98@yahoo.com Уфимский государственный авиационный технический университет
http://www.ugatu.ac.ru А. Г. Михеев, к. ф.-м. н., докторант кафедры прикладной информатики в экономике Тел.: (916) 535-69-51, e-mail: andrmikheev@gmail.com
