CC BY
29
УДК 004.056, 004.838.2
КОМПЬЮТЕРНЫЕ МЕТОДЫ МОНИТОРИНГА И АНАЛИЗА ЗАЩИЩЕННОСТИ ПРИ ФУНКЦИОНИРОВАНИИ АВТОМАТИЗИРОВАННЫХ БИЗНЕС-ПРОЦЕССОВ КОМПАНИИ
О. В. Лукинова, к. т. н., с. н. с.
Тел.: (495) 334-89-70, e-mail: [email protected] Институт проблем управления им. В. А. Трапезникова РАН
www.http://ipu.ru
Methods of computer monitoring prior to the designing of the information security of the company automated business processes are considered. The scheme of monitoring analysis of parameters is described, which allows to solve the problem of designing such system.
Рассмотрены компьютерные методы мониторинга, предваряющего проектирование системы информационной безопасности автоматизированных бизнес-процессов компании. Описана схема анализа параметров мониторинга, которая позволяет решить вопрос о необходимости проектирования такой системы, построенной из наложенных средств.
Ключевые слова: система информационной безопасности, мониторинг бизнес-процессов, оценочные критерии, штатные и наложенные средства защиты.
Keywords: information security system, monitoring of business processes, assessment criteria
1. Введение
Формализация методов формирования и принятия решений
при проектировании систем безопасности современных информационных систем (ИС) является
весьма непростой задачей. Это, с одной стороны, объясняется сложностью и, как следствие, опасностью самих ИС, характеризуемых многоуровневой архитектурой; распределенностью; использованием внешних сервисов и предоставлением во внешний мир своих; ограниченными временными рамками и т. д. С другой - сам процесс принятия решений, учитывающий целый спектр противоречивых факторов, включающий вопросы законодательного, административного, процедурного, программно-технического аспектов, не менее сложен, чем сам объект защиты.
Увеличение объема информации, которую необходимо проанализировать экспертам, усложнение решаемых задач, необходимость учета большого числа взаимосвязанных факторов требуют использования вычислительной техники в процессе принятия решений. В связи с этим появился новый класс систем - систем поддержки принятия
решений (СППР), основанных на формализации методов получения объективных и субъективных оценок, алгоритмизации рассуждений, анализа ситуаций, выработки вариантов решений. Одной из задач СППР при организации защиты является мониторинг параметров функционирования объекта защиты, на основании анализа данных которого решается вопрос о необходимости проектирования системы безопасности обследуемого объекта.
В статье определены области функционирования объекта защиты, параметры которых должны быть подвергнуты процедуре мониторинга; сформулированы задачи, стоящие перед подсистемой мониторинга; описаны компьютерные процедуры и алгоритмы анализа, использующие аппарат субъективных оценок.
2. Описание объекта защиты
В [1] подчеркивалось, что основными защищаемыми активами компании являются бизнес-процессы, совокупность которых ассоциируются с корпоративной информационной системой (КИС).
При организации защиты активов КИС может быть две ситуации:
1) информационная система находится в стадии разработки и одновременно с ней происходит проектирование защиты как межкатегорийного сервиса [2] ИС. Тогда речь следует вести не о мониторинге, а ско-
Appl
рее, о прогнозировании параметров функционирования бизнес-процессов, включая и параметры безопасности;
2) информационная система находится в стадии эксплуатации, и стоит задача спроектировать для ее бизнес-процессов систему безопасности. Именно эта ситуация и рассматривается в данной работе.
Понятие бизнес-
процесса включает: а) некоторую семантику, реализуемую бизнес-логикой
/ OV
(виды деятельности и их взаимосвязь); б) среду функционирования, которую можно представить HV
моделью OSE/RM (Open System Interconnec-
tion/Reference Model) группы POSIX (Portable Operating System Interface for Unix), представляющую собой трехмерную логическую (справочную, эталонную, референс-ную) структуризацию функциональности информационной системы и описанную в [2, 3]. На рис. 1 представлен пример некоторых реализаций «клеток» модели. Уровни описания в данной модели следующие:
- компоненты служб и сервисов промежуточного слоя (MW);
- компоненты операционных систем, или операционного слоя (OW);
- аппаратный слой (HW).
Функциональные группы компонентов в
данной модели по вертикали составляют:
- компоненты, обеспечивающие интерфейс с пользователем (User);
- компоненты, реализующие все необходимые процессы в системе (System);
- компоненты, осуществляющие организацию, представление, доступ и хранение данных (Information)';
- компоненты телекоммуникационной среды, обеспечивающие взаимосвязь информационных систем (Communication), данный уровень представляет собой модель взаимосвязи открытых систем (OSI/RM).
Компоненты среды определяют параметры функционирования бизнес-процесса, а с точки зрения информационной безопасности она является носителем различного рода уязвимостей, которые используются нарушителем для проникновения в КИС.
Первый этап, с которого следует начать проектирование защиты бизнес-процессов,
это мониторинг и анализ состояния среды бизнес-процессов. Задачами подсистемы мониторинга СППР при проектировании систе-
/
/
Экранные формы Бизнес- логика Запросы к БД, форматы Клиенты прикладных протоколов
Рис. 1. Модель 08Е/КМ
мы безопасности являются: систематическое накопление данных о функционировании бизнес-процессов, обработка и анализ этих данных, представление результатов анализа в виде, удобном для ЛПР.
Анализ осуществляется с целью определения необходимости организации дополнительной защиты тому или иному бизнес-процессу. Проводить его будем по следующим направлениям:
1. Идентификация и оценка ценности информационных ресурсов бизнес-процесса КИС.
2. Загрузка вычислительных ресурсов бизнес-процесса.
3. Опасность среды бизнес-процесса с точки зрения проникновения нарушителя, ее уязвимость.
4. Защищенность, которая обеспечивается встроенными в среду средствами защиты.
3. Оценка ценности информационных ресурсов, обрабатываемых бизнес-процессом
Прежде всего следует заметить, что ценность информационных ресурсов и ущерб от компрометации этих ресурсов - это две стороны одной медали. Например, если клиентская БД страховой компании попала в руки конкурентов, компания понесет ущерб в объеме недополученных страховых сборов.
Поэтому оценка ценности ресурсов одновременно влечет и оценку ущерба от компрометации этих ресурсов.
К информационным ресурсам в первую очередь относится так называемый интеллектуальный капитал (ИК) организации, включая нематериальные активы. В [11] определен следующий состав ИК:
1. Рыночный, т. е. активы предприятия, связанные с рыночными операциями, обеспечивающими конкурентные преимущества (данные по клиентам, поставщикам, партнерам по бизнесу, репутация компании и т. д.).
2. Структурный, который включает объекты интеллектуальной собственности (патенты, авторские права, производственные, инновационные, управленческие секреты и т. д.) и активы, формирующие рабочую среду фирмы (корпоративные, технологические, производственные стандарты, бизнес-правила, учетные политики и т. д.).
3. Человеческий капитал, воплощающий коллективные и индивидуальные знания компании, но контекст безопасности - это законодательная охрана персональных данных.
Перечисленные интеллектуальные активы в виде различных по семантике БД, хранилищ, отдельных файлов привязаны как внешние сущности к бизнес-процессам и, стало быть, включаются в состав реализаций соответствующих «клеток» модели OSE/RM. Таким образом осуществляется структуризация ИК, в результате чего все информационные ресурсы КИС ставятся в соответствие «клеткам» платформенной компоненты, а именно столбцу Information того или иного бизнес-процесса.
Кроме того, при оценке ущерба следует принять во внимание и тот факт, что он может произойти и в случае, если какая-либо функция бизнес-процесса перестает работать. Поэтому при оценке ценности/ущерба к информационным ресурсам отнесем не только активы ИК, но и исполняемые коды ПО.
Ценность/ущерб может выражаться как в денежном, так и в неденежном исчислении (например, санкции, которые понесет руководитель за нарушение закона о защите персональных данных). Поэтому есть смысл перейти к обобщенному показателю «приоритет ресурса» Pr, который будет измеряться лингвистической или балльной шкалой: «высокий - 4», «средний - 3», «низкий - 2», «очень низкий -1», «отсутствует - 0» (через тире здесь и далее в лингвистических шкалах приведены балльные оценки).
Оценочные критерии при определении значений приоритета Pr активов могут быть
следующие:
K1. Нормативные акты, которые регламентируют актив: «закон РФ - 4», «ГОСТ - 3», «РД - 2», «внутренние документы - 1», «отсутствует - 0» (этот критерий имеет свою лингвистическую шкалу, но она вполне согласуется с общей).
Конкурентные преимущества.
Объем недополученного дохода.
Степень личной ответственности ЛПР.
Степень юридической ответственности.
^ Стоимость восстановления кодов.
K1. Стоимость восстановления аппаратных средств.
^. Потери от компрометации бренда.
Стоимость восстановления данных и т. д.
Состав списка критериев определяется семантикой функций бизнес-процессов и может быть предварительно сгенерирован в подсистеме моделирования бизнес-процессов.
Далее по каждому активу «клетки» подсистема мониторинга предлагает предварительные списки каждому эксперту, которые он может утвердить или модифицировать. После этого СППР проводит процедуру согласования списков экспертов. Алгоритмы согласования хорошо известны, в систему их может быть заложено несколько, с тем чтобы ЛПР мог выбрать процедуру согласования. На рис. 2 приведена блок-схема процедуры согласования, проводимой СППР, которая включает блоки автоматического и ручного согласования [4].
Комментарии к блокам, требующим пояснения
Блок 2 проводит сравнение экспертных списков и создает два списка параметров: список A, в который вошли критерии, выбранные всеми экспертами, и список B, содержащий все остальные критерии. Список B подлежит дальнейшему согласованию.
Блок 4 проверяет номер итерации. Если итерация первая - переход к блоку 5, если нет
- к блоку 7. Вообще итераций может быть сколь угодно много, но опыт показывает, что на последующих итерациях скорость сходимости падает или сближение оценок вообще прекращается. Поэтому после первой (или первых) итераций лучше перейти к какому-либо методу их автоматического согласования
Блок 7 обеспечивает автоматическое согласование, проводимое СППР с использованием процедур голосования, тогда в списке остаются те критерии, которые прошли ту или иную процедуру голосования. В настоящее время в литературе описано достаточно много процедур голосования, с которыми можно ознакомиться, например, в [5].
1
Рис. 2. Блок-схема процедуры согласования
Важно отметить, что от выбора процедуры может зависеть ее результат, поэтому выбор процедуры либо тоже согласовывается, либо определеляется руководителем.
Пусть после первой итерации ЛПР решил провести голосование по правилу абсолютного большинства, т. е. считать согласованными те критерии, за которые проголосовало больше половины экспертов. СППР сравнивает перечень параметров в списке B и определяет число экспертов, давших одина-
ковые оценки. Оказалось, что у большинства экспертов оценки совпадают. Система записывает эти оценки в список A, ликвидируя список B.
Процедура согласования списка критериев по «клеткам» закончена.
В табл. 1 приведен пример согласованных оценок приоритета ресурсов «клеток» Si-го бизнес-процесса по списку критериев Кь Кг, К.
Таблица 1
Идентификатор «клетки» бизнес-процесса Si Критерий Рг(Кр)
Нормативные акты Конкурентные преимущества Объем недополученного дохода
К - Рч Очень низкий - 1 Средний - 3 1.92
Кр ГОСТ - 3 Средний - 3 Высокий - 4 3.09
Средние значения РгК1^1) РгК2(^.) РгК3(£.) Рг^)
Здесь РгК1^1), РгК2^1), PrK3(£.) -приоритеты бизнес-процесса по критериям К1, К2 и К3 соответственно, которые считаются как средние по столбцу.
Последний столбец таблицы содержит приоритеты «клеток», которые представляют собой линейные функции
Рг(КР)=£ ар,хр.
где йр8 - вес критерия, Хр8 - значения критерия,
(1)
а также совокупную оценку приоритета всего
1 р
бизнес-процесса Рг(^) = —2 Рг (Кр), котоР р=1
рая потребуется в дальнейшем при ранжировании целей безопасности.
Далее следует определить значимость критериев, их вес арэ. Для этого можно использовать известные методы [4] или заполнить каждому эксперту таблицу рангов (значимости). Ранг критерия определяет, какова, по мнению экспертов, его важность (табл. 2).
Таблица 2
Идентификатор «клетки» бизнес-процесса St Важность критерия
Нормативные акты Конкурентные преимущества Объем недополученного дохода
К Высокая - 3 Низкая - 1 Средняя - 2
Кр Низкая - 1 Средняя - 2 Очень высокая - 4
В табл. 1 и 2 все значения критериев иллюстративного примера представлены в лингвистической форме, а через тире даны их балльные соответствия. Для дальнейшего анализа потребуются балльная форма оценок, обычно такой перевод подсистема мониторинга делает автоматически.
Таблицы типа 1 и 2, определяющие балльные или лингвистические оценки критериев и их веса, составляются экспертами заранее и согласовываются в подсистеме предпроектного проектирования СППР.
После того как каждый эксперт проставил ранги в табл. 2, для каждой «клетки»
СППР определяет сумму рангов, набранных каждым критерием:
гр5 = 2 грП5, где гр - ранг 5-го критерия,
]=1
определенный ]-м экспертом для р-й «клетки», пэ
- число экспертов, давших данную оценку критерию, а также вес критерия, т. е. нормированную г
рэ
сумму рангов а р3 ==-—.
2 г
рэ
3
В итоге получим табл. 3, последний столбец которой содержит значения весов арэ из (1).
Таблица 3
Идентификатор «клетки» бизнес-процесса S, Оценка важности критерия Сумма рангов критериев 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 K K2 K3
К 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. Оценка загрузки вычислительных ресурсов бизнес-процесса
Мониторинг загрузки вычислительных ресурсов среды бизнес-процесса необходимо осуществлять с двумя целями. Первая - фиксация эталонных значений, т. е. определение штатного режима функционирования параметров среды, осуществляется стандартными программными средствами. В дальнейшем это позволит СППР оценивать отклонения текущих значений от эталонных и определять наличие инцидентов безопасности.
Параметры, по которым отслеживается загрузка вычислительных ресурсов, структурируются в соответствии с базовой плоскостью платформенной части модели 08Е/КМ. Оценку этих параметров целесообразно про-
изводить по следующим критериям:
1. Степень загрузки того или иного оборудования (производится по аппаратному слою референсной модели, см. рис. 1).
2. Степень разбалансировки загрузки сетевого оборудования (столбец Communication) и оборудования столбцов User, System, Information.
3. Отклонение от штатных значений и
т. д.
Измеряются критерии по лингвистической однородной шкале «отсутствует - 0», «низкая - 1», «средняя - 2», «высокая - 3», «критическая - 4».
Вторая цель - утилитарная. Системный администратор, имея списки подключенных модемов, сканирующих программ, открытых портов, сетевых сервисов и т. д., может про-
вести анализ на защищенность/незащищенность, легитимность/нелигитимность,
нужность/ненужность соответствующих объектов.
5. Оценка параметров уязвимости среды бизнес-процесса
Среда, которая представляется «клетками» платформенной компоненты 08Е/КМ, подвержена влиянию ряда объективных факторов, декларируемых стандартами [6]:
• угрозы информационной безопасности со стороны среды бизнес-процесса У^), где . =Н7,1
- число автоматизированных бизнес-процессов предприятия, характеризующиеся вероятностью возникновения и вероятностью реализации;
• уязвимости среды бизнес-процесса или системы контрмер Х (Хр Х2,..., Хп ) , влияющие
на вероятность реализации угрозы;
• нарушитель, определяющий вероятность возникновения угрозы;
• риск - фактор, отражающий возможный ущерб в результате реализации угрозы.
Пусть Р(А( )) - вероятность реализа-
ции той или иной угрозы, здесь А( х.) - событие, интерпретируемое как использование нарушителем уязвимости х.; и(^) - величина возможного ущерба при нарушении штатного функционирования бизнес-процесса ^-.
Тогда количественный уровень риска определяется как функция
ад = / (Р(А( ~)), и^г))).
При этом вероятностные оценки будем рассматривать в рамках субъективного подхода, который трактует вероятность как субъективную меру убежденности наблюдателя, соответствующую его знаниям и опыту, в истинности или ложности предложенного ему утверждения [7]. Тогда оценку меры риска Ягэк^,), присущего бизнес-процессу, можно определить как произведение оценки угрозы У(^) на оценку ценности/ущерба Рг^г): Шк&) = У^г)хРг^г).
Далее для каждой уязвимости х, СППР
получает общую оценку (рейтинг уязвимости) по алгоритму, который использует аддитивную функцию, т. е. выбранные значения по обоим действиям по всем таблицам сум-
Итак, среда бизнес-процесса несет угрозы его безопасности, т. к. является носителем
уязвимостей Х, т. е. тех огрехов в ПО или защите, которые могут быть использованы нарушителем. Рассматриваются два типа уязвимостей: технологические - это «дыры» в программном коде платформенной или прикладной компонент, появляющиеся на стадии разработки ПО, или самих средств защиты, а также эксплуатационные.
Уязвимости являются основной предпосылкой нападения нарушителя и существуют объективно на момент планирования защиты. Стало быть, анализирующий блок подсистемы мониторинга должен оценить ту долю риска, который присущ среде вследствие имеющихся уязвимостей. Алгоритм оценки может быть следующий.
1. С помощью определенного ПО (сканеры уязвимостей) для конкретной реализации среды бизнес-процесса на стадии пред-проектного проектирования СППР выявляются перечни уязвимостей Х (Хр Х2Хп ) и ставятся в соответствие «клеткам» 08Е/КМ.
2. Любой уязвимости Х, можно сопоставить два действия [8]: сначала идентифицировать уязвимость, а затем ее использовать. С точки зрения этих действий Х, характеризуется следующими параметрами:
a) временем, которое необходимо для совершения этих действий;
b) необходимой квалификацией;
c) уровнем знаний о среде;
д) характером и продолжительностью доступа к среде;
е) необходимыми аппаратнопрограммными ресурсами.
Для каждого критерия в СППР имеются согласованные экспертами оценочные балльные шкалы, разработанные на основе [8] (в табл. 4 приведен пример шкалы по критерию а), оценочные шкалы остальных критериев можно посмотреть там же).
Таблица 4
мируются. Если уязвимость можно идентифицировать/использовать несколькими способами, для каждого из них вычисляется рейтинг и из полученных значений выбирается минимальное, т. е. уязвимости ставится
Время Идентификация уязвимости Использование уязвимости
< 0,5 часа 0 0
< суток 2 3
< месяца 3 5
> месяца 5 8
в соответствие самый простой метод успешного нападения. По этому же правилу по всем Х. «клетки» вычисляется общий рей-
гъклетки пклетки / Т}~1 Т}~2 ТУХп \
тинг к , т. е. К = Ш1П(К 1,к 2,...,Кп),
3. По тому же принципу вычисляется потенциал нарушителя ЫР. В [8] этот потенциал с учетом правила максимума ЫР = шах(ЫР1,ЫР2,...,ЫРп) (из нескольких
6. Оценка защищенности встроенными средствами
Защита среды бизнес-процессов от несанкционированного вмешательства в процессы их функционирования обеспечивается специальными механизмами. В литературе [6, 10] описываются следующие защитные механизмы (Мх):
1. Идентификация и аутентификация пользователя.
2. Разграничение доступа пользователей к ресурсам.
3. Мониторинг и аудит событий, происходящих в системе.
4. Криптографическая поддержка (шифрование) хранимых и передаваемых данных.
5. Контроль целостности и аутентичности (подлинности и авторства) хранимых и передаваемых данных.
6. Экранирование компьютерной сети или отдельного компьютера, т. е. защита периметра.
7. Анализ защищенности, т. е. выявление и анализ уязвимостей среды бизнес-процесса.
8. Обеспечение отказоустойчивости (живучести) среды бизнес-процессов, т. е. способности сохранять требуемую работоспособность, несмотря на отказ отдельных элементов.
9. Способность к восстановлению.
10. Туннелирование, т. е. «упаковка» передаваемого пакета данных в новый «кон-
где кХ. - рейтинг уязвимостей, принадлежащих данной «клетке».
Оценочная шкала рейтинга уязвимостей приведена в табл. 5.
Таблица 5
сценариев нападения выбирается худший вариант, с наибольшим потенциалом) определяется оценками табл. 6.
Таблица 6
верт».
11. Уничтожение остаточных данных.
12. Выявление и нейтрализация вирусов.
13. Обнаружение компьютерных атак.
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
Идентификатор «клетки» бизнес-процесса Si Стойкость механизмов S(Mxk) S(Mxp)
Мх1 Мхк
1 2 k k +1
Кі Высокая - 3 Базовая - 1 Умеренная
Кр Средняя - 2 Механизм отсутствует Средняя
Средняя стойкость S (Mxk ) Средняя - 2 Базовая - 1 S (Mx)
Здесь S(Mxk) - стойкость к-го защитного механизма.
S (МХк) - средняя стойкость к-го механизма по бизнес-процессу, вычисляется по недостатку по шкале «Стойкость» 1
хр - оценки механизмов
S (Mxk ):
Г р
табл. 7 приведен пример согласованных оценок.
S (Мх) - средняя совокупная стойкость механизмов бизнес-процесса, вычисляется по недостатку как среднее по столбцу 5: 1
S (Mx) =
совокупные оценки
по столбцу 2 ^ к.
S(Mxp) - совокупная стойкость механизмов, соответствующих р-й «клетке» - представляет собой суждения экспертов о величине синергетического защитного эффекта от влияния механизмов друг на друга. Например, туннелирование по протоколу IPv6 над стандартным TCP/IP дает достаточно низкую безопасность по конфиденциальности при передаче данных, но вкупе с механизмом шифрования уровень конфиденциальности резко повышается, а если на концах канала передачи установить межсетевой экран, получим одно из самых надежных средств защиты -виртуальную частную сеть VPN.
Оценка S(Mxp) производится экспертами следующим образом:
Каждый эксперт на основании столбцов 2 ^ к выставляет совокупную оценку. Для этого вводится шкала «Совокупная стойкость»:
«низкая - 1», «умеренная - 2»,
«высокая - 3», «очень высокая -4», т. к. шкала «Стойкость», предлагаемая стандартами [6, 9], не обеспечивает однородности оценочных шкал.
1. Согласование совокупных
механизмов по столбцу к + 1.
7. Анализ параметров мониторинга
Анализ взаимосвязей этих параметров позволяет решить вопрос о достаточности/недостаточности штатных механизмов.
Итак, в результате мониторинга получим распределение параметров по референс-ной модели, представленное на рис. 3, где
каждая «клетка» оценивается рейтингом уяз-
MW
SW
HW
System
рклетки _ реиТИНГ уЯЗВИМОСТеЙ «КЛвТКИ»,
S(Mx ) ~ стойкость штатных механизмов защиты,
]\[Р - потенциал нарушителя,
Рг(Кр) - приоритет ресурсов «клетки».
Рис. 3. Матрица параметров мониторинга в соответствии с моделью OSE/RM
вимостей Яшетки? потенциалом нарушителя оценок по вышеприведенному алгоритму. В ш, который может воспользоваться уязви-
хр
мостями Хклетки, стойкостью S(Mxp) защитных средств и приоритетом ресурсов Рг(Кр), сопоставленных данной «клетке».
S(Mxp)
Рис. 4. Схема сравнения параметров по правилам 1 и 2
Соотношение параметров определяется по следующим правилам [8]:
1. СППР рассматривает пару рейтинг «клетки» кклетки - потенциал нарушителя ЫР. Первое решающее правило гласит: нарушитель может совершить успешное нападение на ресурсы «клетки», если его потенциал не меньше рейтинга уязвимости, т. е. если рейтинг уязвимости имеет, например, оценку «умеренный», то для успешного нападения потенциал нарушителя должен быть «высокий» (см. рис. 4).
Рис. 5. Возможные ситуации при реализации угроз
Таким образом, условие успешного нападения заключается в том, что существует NP = max (NPJ) такое, что RKmmKU < NP, где j -
j
тип нарушителя.
2. С другой стороны, нападение нейтрализует защитный механизм, обладающий определенной стойкостью, т. е. необходимо сравнить пару: потенциал нарушителя ЫР -стойкость механизмов S(Mxp). Сравнение будем проводить следующим образом: если S(Mxp) > ЫР, то нападение нарушителя будет отражено защитным механизмом и уязвимости «клетки» не «сыграют».
Рис. 4 демонстрирует схему сравнения параметров кклетки , ЫР и S(Mxp) в нечетких шкалах по правилам 1 и 2.
В результате проверки правил 1 и 2 для параметров ЫР, S(Mxp), рклетки подсистема мониторинга делает вывод о степени реализации угрозы Ур для той или иной «клетки». При этом возможны следующие девять ситуаций:
А. Ситуация, когда угроза осуществима: потенциал нарушителя превосходит рейтинг уязвимости, а стойкость защитных механизмов недостаточна.
Б. Ситуация, когда угроза почти осуществима: рейтинг уязвимости равен потенциалу, а стойкость механизмов ниже потенциала нарушителя.
В. Ситуация, когда угроза, скорее всего, осуществима, т. к. в силу приближенности оценок правило 2 может не сработать.
Г. Очень возможно, что угроза реализуется, т. к. потенциал выше рейтинга уязвимостей, хотя стойкость выше потенциала.
Д. Пограничная ситуация, когда потенциал нарушителя, рейтинг уязвимостей и стойкости механизмов соответствуют друг другу, но, опять же, в силу приближенности и субъективности суждений ситуация требует пристального внимания со стороны ЛПР.
Е. Правило 1 не включает ситуацию равенства рейтинга и потенциала, но субъективность оценок требует, на наш взгляд, учета таких ситуаций. За счет стойкости, пре-
I S Пограничная ситуация
восходящей потенциал, угроза может остаться нереализованной.
Ж. Ситуация, когда угрозы, скорее всего, нет, т. к. рейтинг выше потенциала, но недостаточная стойкость влечет некоторую неуверенность в благоприятном исходе.
З. Угрозы почти нет, т. к. рейтинг выше потенциала, а стойкость ему соответствует.
И. Ситуация, когда угроза точно не может быть реализована, т. к. оба правила дают
положительные исходы.
Рис. 5 демонстрирует графическое представление различных соотношений анализируемых параметров в соответствии с исходами правил 1 и 2.
Эти ситуации, отражающие степень реализации угрозы при наличии только штатных средств защиты, можно интерпретировать шкалой, представленной в табл. 7.
Таблица 7
Степень реализации угрозы Yv
Ситуация Обозначение Интерпретация и балльные оценки
А Угроза точно существует - 7
Б + Угроза почти существует - 6
В - - + + Угроза, скорее всего, существует - 5
Г - + + + Угроза, очень возможно, существует - 4
Д Пограничная ситуация
Е + Угрозы, возможно, нет - 3
Ж + + - - Угрозы, скорее всего, нет - 2
З + + + - Угрозы почти нет - 1
И + + + + Угроза отсутствует - 0
Вообще говоря, на основании выводов, представленных подсистемой мониторинга в соответствии с проведенным анализом, СППР может принять решение о необходимости привлечения наложенных средств защиты. Но в дополнение к полученным оценкам она может осуществить и оценку тех рисков, которые ожидают компанию, если
Riskp = Pr^xYp,
Вычисленное значение Riskp отображается на шкалу «Риск клетки», которая формируется из следующих соображений. Произведение оценок Pr на Y может дать 20 возможных значений: 0, 1, 2, 3, 4, б, S, 9, 10, 12,
14, 15, 1б, 18, 20, 21, 24, 28, которые СППР автоматически разносит по, например, 5балльной шкале, отнеся 0, І, 2, 3 к уровню риска «очень низкий»; 4, 5, б, 7 - к уровню «низкий»; S, 9, 10, 12 - к «средний»; 14, 15, 1б, 18 - к «выше среднего»; 20, 21, 24, 28 - к «высокий». Если такое разнесение экспертов не устроит, в СППР предусматривается процедура ручного формирования шкалы риска и разнесения по ней возможных значений Riskp.
Совокупный по бизнес-процессу риск Risk подсистема мониторинга может определять двумя способами (хотя могут быть заложены и другие алгоритмы):
1. Как среднее значение по «клеткам»
Risk = — У Risk .
о ^ р
г р
угроза реализуется с уверенностью Yp. Риск -это категория, зависящая не только от степени реализации угрозы, но и от объема ущерба (см. выше).
Тогда на основании оценок ущерба и угроз подсистема мониторинга реализует алгоритм расчета оценки риска среды для р-х «клеток»:
(2)
2. Как мультипликативная функция с учетом важности риска для «клетки» Risk = П арRisk . При этом СППР произво-
р
дит процедуру назначения и согласования весов «клеток» ар с точки зрения риска по алгоритмам, описанным ранее.
Стратегии, связанные с управлением рисками, из которых ЛПР производит выбор, могут быть различными, но среди них есть четыре стандартных:
Стратегия 1. Пусть Risk* - некоторый пороговый риск по i-му бизнес-процессу, приемлемый для компании с точки зрения ЛПР. Тогда если Risk < Risk*, то по данному бизнес-процессу компания готова нести потери в случае атаки злоумышленника, но систему безопасности из дополнительных средств проектировать не нужно.
Стратегия 2. Ликвидация риска, т. е. сведение его до нулевого уровня.
Стратегия 3. Уменьшение риска до приемлемого уровня.
где Pr^,,) - оценка ущерба, Yp - оценка угрозы, p = 1, ..., P.
Стратегия 4. Переадресация риска: компания решает застраховать риски, связанные с информационными атаками, и дополнительные средства защиты.
Стратегии 2 и 3 работают при условии Risk > Risk*. Это означает, что при неприемлемом риске в дополнение к защитным штатным средствам необходимы наложенные, т. е. нужно проектировать комплексную систему защиты (КСЗ) из наложенных и штатных средств, а стало быть, необходимо реализовывать процедуру определения целевых векторов безопасности
KS чрель (K (Т *), C (Т *), D(T *)), где К(Т*),
С(Т*), D(T*) - соответственно уровни конфиденциальности, целостности, доступности, которые должна обеспечивать КСЗ для реЛитература
1. Лукинова О. В. Формализация задачи планирования защиты распределенной компьютерной сети на основе бизнес-процессного подхода // Надежность, 2009. № 1. С. 72-80.
2. ISO/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 c.
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 с.
сурсов, обрабатываемых бизнес-процессом. Состав вектора безопасности продиктован тем, что информационная безопасность обеспечивается именно перечисленными основными свойствами данных в информационных системах.
8. Заключение
В статье описаны методы и алгоритмы, на основании которых компьютерная система может принять решение о необходимости привлечения дополнительных защитных механизмов, т. е. определяется целесообразность построения комплексной системы защиты как из встроенных, так и из наложенных средств.
УДК 65.011.56
ЭКОНОМИЧЕСКИЕ АСПЕКТЫ УПРАВЛЕНИЯ ИНФОРМАЦИОННЫМИ ПОТОКАМИ В СЛОЖНЫХ ТЕХНИКО-ЭКОНОМИЧЕСКИХ СИСТЕМАХ НА ПРИМЕРЕ АЭС
М. Г. Кретов, к. э. н., ассистент кафедры «Гражданское строительство и прикладная экология»
Тел.: (921) 789-18-47, e-mail: [email protected] Санкт-Петербургский государственный политехнический университет
http://www.spbstu.ru
