Компьютерный мониторинг состояния среды бизнес-процессов при эксплуатации системы защиты Текст научной статьи по специальности «Компьютерные и информационные науки»

уда оо4.о56, (>04.838.2 О.В. Лукинова

Компьютерный мониторинг состояния среды бизнес-процессов при эксплуатации системы защиты

Рассмотрены вопросы компьютерного мониторинга и анализа параметров среды реализации автоматизированных бизнес-процессов в период эксплуатации системы защиты. Анализ основывается на представлении ИС в виде модели OSE/RM группы POSIX, что позволяет использовать адекватные механизмы обнаружения аномалий, определить фазу атаки и оценить ее с точки зрения нанесения деструктивных воздействий бизнес-процессу.

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

COMPUTER MONITORING OF THE ENVIRONMENT OF BUSINESS PROCESSES IN THE OPERATION OF THE SYSTEM OF PROTECTION

The problems of computer monitoring and analysis of environmental parameters implementation of automated business processes during the operation of the protection system. The analysis is based on the idea of IP as a model OSE / RM of POSIX, which allows the use of appropriate mechanisms to detect anomalies, to determine the phase of attack and evaluate it in terms of the application of the destructive effects of the business process.

Keywords: information security, the method of anomaly detection, and monitoring of business processes.

Введение

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

Следующий этап жизненного цикла КСЗ - это ее эксплуатация. Поэтому эта статья развивает идеи. изложенные в [1]. в ситуации. когда в системе происходит инцидент безопасности. а плановые средства КСЗ с ним не справляются. Здесь алгоритмы мониторинга должны быть направлены на анализ и обработку нарушений в работе бизнес-процесса. а именно: задействовать механизмы. которые позволят эффективно выявить причину нарушений; оценить степень опасности; понять. какие цели преследует нарушитель. осуществляющий атаку.

1. Задачи мониторинга среды бизнес-процессов на этапе эксплуатации КСЗ

Мониторинг этапа эксплуатации КСЗ осуществляется с целью сбора и анализа данных для принятия решений при выявлении нарушения эталонного функционирования бизнес-процесса вследствие происходящих инцидентов безо-

пасности. Общая процедура состоит из следующих шагов.

1. Отслеживание и оценка значений характеристик среды с целью выявления нарушения штатного функционирования бизнес-процессов S. Такие эффекты в ИС проявляются в виде функциональных нарушений работы приложения, обозначим их вектором {р} = {pf, pf, ..., p}. При этом функциональность ИС, как объекта защиты, представляется матрицей «клеток» платформенной и прикладной компонент модели OSERM (Open system environment reference model) группы POSIX (Portable Operating System Interface for Unix), которая подробно описана в [1, 2].

Подсистема мониторинга должна производить оценку параметров {Pf} с точки зрения степени выхода за штатные диапазоны. Для этого по каждому pF вводятся однородные шкалы оценки степени критичности (Кр№)) нарушения по шкале:

Таблица 1.

Оценочная шкала критичности нарушения параметра

Терм Критическое Среднее Слабое Норма

Диапазон 0-100 100-500 500-700 700-1000

О.В. Лукинова,

к.т.н., с.н.с. Тел.: 8 (495) 334-89-70 E-mail: lobars@mail.ru Институт проблем управления им. В.А.Трапезникова РАН www.ipu.ru

«Степень критичности»: «критическое - 3», «среднее - 2», «слабое -1», «норма - 0» (здесь и далее цифрами обозначены балльные значения шкалы). Пример такой шкалы приведен в табл. 1.

Подобные шкалы должны быть сформированы и согласованы экспертами на этапе предпроектного проектирования СППР по каждому параметру рЕ, подлежащему мониторингу и оценке.

2. Мониторинг аномалий. Нарушение характеристик {р} может быть связано: а) с программноаппаратными причинами, к которым отнесем неисправности аппаратуры, ошибки ПО, ошибки конфигурирования и т.п., и б) с аномалиями, нарушающими защиту бизнес-процессов, т.е. критерии безопасности {К5}. Назовем такие аномалии атакой (в дальнейшем рассматриваются именно такие аномалии).

Поэтому под мониторингом аномалий понимается отслеживание и оценка характеристик среды бизнес-процесс (плоскость <ИС> модели ОБЕХИМ), систем администрирования (плоскость <А>) и защиты (плоскость <З>), которые могут принимать аномальные значения при наступлении события, связанного с нарушением критериев {К5}. Для этого, прежде всего, надо описать те характеристические параметры, которые поддерживают обеспечение того или иного критерия. Тогда ясно, что именно их надо отслеживать и именно их значения выйдут за пределы штатных при нападении.

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

Описанная процедура реализуется в виде алгоритма, представленного на рис. 1.

Пусть вектор {рГ} описывает характеристические параметры критериев безопасности {К£} р-й «клетки». Перечень этих харак-

теристик структурируется составом вектора {К5}, т.е., если в качестве критериев безопасности выбраны конфиденциальность К, целостность С, доступность D данных и функций бизнес-процесса, то вектор представляется как {РК} (кЬ ..., kn, ^^, ..., ^^, d1, ..., dr),

где (кь ..., ки) характеристики К, (сі, ..., ет) - С, а (йь ..., й) - D. Эти характеристики могут быть как количественные, например, величина трафика, объем памяти, так и качественные - надежность паролей, целостность файловой систе-

Мониторинг ( функционирования бизнес-процесса

Мониторинг функциональных нарушений бизнес-процесса {р^}= {р1,рр2,.,рГ }

^^""Наруш Д 1 ения

есть? а

Мониторинг аномалий среды бизнес-процесса

\ ХОО / \s8&/ бп дент

сности ошегі?^^ а

Анализ инцидента безопасности

Нет

Нет

^Завершения мониторинга^

Рис. 1. Общий алгоритм мониторинга при эксплуатации КСЗ

Мо Мо Мо Мо

AppI —KS {Pp} —KS {Pp} —KS {Pp} —KS {Pp}

Platf

MW Мо — KS {Pp} Мо — KS {Pp} Мо — KS {Pp}

Мо Мо Мо Мо

SW — KS {Pp} —KS {Pp} —KS {Pp} {P7}

Мо Мо Мо Мо

HW —KS {Pp } —KS {Pp} —KS {Pp} —KS {Pp }

User System information Communication

Мо — механизм (модель) обнаружения аномалий

—К _ _ {Рр } — вектор характеристических свойств критериев безопасности

Рис. 2. Структуризация параметров и механизмов обнаружения по модели

OSE\RM

мы и т.д. Такие векторы характеристик должны быть сформированы по «клеткам» всех трех плоскостей модели О3Е\КМ, а их значения отслеживаться подсистемой мониторинга.

Обозначим {Р1^-"110'} - вектор характеристик критериев безопасности {КЗ} р-й «клетки» для плоскости <ИС>,

{рКя^-А-'} - вектор характеристик критериев безопасности {КЗ} р-й «клетки» для плоскости <А> ,

{^-<3:

} - вектор характеристик критериев безопасности {КЗ} р-й «клетки» для плоскости <З>.

Тогда {~РК1} = {~рКрЗ-<ИС'} и и {рБ-<л>} и {Рр3-"3'} - объединенный вектор характеристик, описывающих критерии безопасности р-х «клеток» модели.

Аномалии, которые могут возникнуть в «клетках», можно разделить на 2 группы:

1. Аномалии сетевые (СА) - характеризуются нарушением параметров, формируемых в «клетках» OSI\RM (столбец С); это сканирование, отказ в обслуживании, распространение сетевых червей, эксплуатация уязвимостей сетевых стеков, использование анализаторов трафика, сетевых модификаторов и т.п. Для обнаружения СА на сегодняшний день используются различные механизмы, включающие разные методы и модели. Проведенный сравнительный анализ показал применимость ряда математических методов, таких как статистический, спектральный, вейвлет-анализ, моделирование временных рядов, для выявления СА типа сканирование, вирусная активность, атаки на отказ в обслуживании, наносящих наибольший ущерб в силу своей распространенности и последствий.

2. Аномалии локальные (ЛА) возникают в локальной компоненте системы - реализациях столбцов и, 3, I. К ним относятся: вирусная активность, распространение программных червей, эксплуатация уязвимостей на локальном компоненте реализаций модели и т.п. Методы обнаружения ЛА реализованы различными антивирусами в виде 2-х функционально различных компонент: технической, цель которой - сбор данных для выявления вредоносного кода, и блока

анализа ситуации при принятии решения.

Все эти методы оперируют различными наборами параметров из числа координат вектора {Рр3} = = (Ь, ..., ^, сь ..., ст, dl, ..., dr), поэтому «клеткам» модели можно поставить в соответствие не только наборы параметров {Рр3}, но и, собственно, механизмы обнаружения (Мо) аномалий (рис. 2).

Подсистема мониторинга с определенной долей уверенности должна:

• уметь обнаруживать механизмами Мо, аномальные значе-

<ИС>-,

ния характеристик {Рр - },

<л> ^ гТКЗ <3'-.

{Рр - }, {Рр - }, ассоцииро-

ванных с реализациями р-х «клеток» плоскостей модели О3Е№М данной ИС;

• применять адекватные методы обнаружений аномалий;

• принимать решение о том, какая фаза развития аномалии (атаки) наблюдается в данный момент;

• определять вероятность перехода от одной фазы к другой.

2. Выбор механизмов обнаружения

Задачу выбора Мо необходимо решать исходя из следующих факторов.

1. Степень критичности (КрЗ)) функциональных нарушений бизнес-процесса Зг. Она оценивается шкалой: «критическая - 3», «средняя - 2», «слабое - 1», «норма - 0».

2. Ценность бизнес-процесса для предприятия, включая потоки обрабатываемых данных, для оценки которой в [1] были введены параметры приоритета бизнес-процесса РгЗ) и оценочная шкала: «высокий - 4», «средний - 3», «низкий - 2», «очень низкий - 1», «отсутствует - 0».

3. Тип бизнес-процесса (Т3) определяет категорию, к которой принадлежит бизнес-процесс. Это могут быть:

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

• обеспечивающие бизнес-

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

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

i. управленческие бизнес-процессы,

ii. бухгалтерские,

iii. кадровые и т.д.

TS. может принимать значения:

Г основнойпроцесс TSj = < обеспечивающийпроцесс У вспомогателъныйпроцесс.

При этом следует помнить, что каждый Si бизнес-процесс реализуется набором информационных операций IOj Si = (IOi, IO2, ... , ГОД «разложенных» по «клеткам» модели OSERM [3].

4. Возможности Мо, которые могут быть оценены критериями функциональной пригодности, функциональной приемлемости (правильности) (Prieml), эффективности использования (Eff), нагрузкой на пользователя [4, 5].

При выборе Мо необходимо понять, какими критериями руководствоваться. Здесь СППР может использовать 2-этапную процедуру.

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

Эти критерии определяют ограничения на выбор Мо, которые приемлемы по количеству пропущенных, ложных срабатываний, надежности детектирования, нагрузке на систему и временным затратам. Таким образом, решающие правила представляет собой продукции вида

if Kp = <значение> & Pr = <значение> & TSi = <значение>

then Eff {[Ngr = <значение\диапазон>] &

[Time = <значение\диапазон>}] & Prieml {[Nd = <значение\диапазон >] & (*) [O1P=< значение\диапазон >] & [O2P=< значение\диапазон > ]}.

Здесь Eff - эффективность использования:

- нагрузка на среду, это доля процессорного времени и оперативной памяти, непрерывно или

периодически задействованных в обеспечении защиты и ограничивающих быстродействие системы

(Ngr),

- временные затраты, требуемые для функционирования метода в данных условиях (Time).

Prieml - функциональная приемлемость:

- надежность детектирования (отношения правильно обнаруженных СА к общему числу имеющихся СА) (Nd),

- величина ошибки 1 рода (отношение пропущенных СА (не выявленных) к общему числу имеющихся СА) (O1P),

- величина ошибки 2 рода (отношение ложных выявлений СА к общему числу имеющихся СА) (O2P).

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

If Кр=’Критическая’ & Рг=’еысокий’ & TSi = = ’основной_процесс ’

then Eff {Ngr= min & Time=min} &

Prieml {Nd=max & O1P=min & O2P=min}.

Если же требования по Kp, Pr, и T не столь критичны, можно задействовать и Мо с более слабыми характеристиками, задаваемыми диапазоном значений.

Множество таких продукций составляет продукционную систему, которая представляется тройкой следующего вида:

ps = <F, p, I),

где F - рабочая память текущих данные;

P - база знаний, содержащая множество продукций вида (*).

Экспертная подсистема СППР, реализуя алгоритм продукционного вывода на правилах типа (*), формирует набор из k механизмов обнаружения аномалий {Mo1, Mo2,..., Mok}, функционально приемлемых механизмов для каждой «клетки» OSE\RM, включенных в информационные операции IO по Si-му бизнес-процессу.

2 этап. На втором этапе из набора {Мо1, Мо2,...,Мо]} выбираются те Мо, которые СППР совместно с экспертом сочтет приемлемыми по функциональной пригодности.

3. Идентификация фазы атаки

Пусть X - множество возможных действий (стратегий), которые может осуществить нарушитель.

Тогда атака - последовательность целенаправленных действий нарушителя х * с X, с использованием техни-1

ческих и (или) программных средств с целью нарушения заданных значений векторов К(]ь ..., ]„), С(с1, ..., ст), D(d1, ..., dr), определяющих тот или иной уровень Т* критериев безопасности бизнес-процесса К(Т*), С(Т*), D(T*).

Атака, вирусная или вторжение, развивается в несколько этапов. Подробнее описание развития атак можно прочитать, например, в [6, 7]. Каждому этапу ставятся в соответствие некоторые характеристики, мониторинг которых позволит оценивать вероятность того, насколько близка атака к нанесению ущерба бизнес-процессу.

Этапы развития атаки в виде компьютерного вторжения (КВ):

- разведка или исследование сети с целью выявления незащищенных модемов, паролей, документации по ИТ, доменных имен, 1Р-адресов сети, списков пользователей. Выполняется извне сети посредством методов социотехники, поиска на сайтах компании и других источниках интернета;

- сканирование сети проводится для выявления незащищенных модемов, паролей, топологии, состава сетевого и сервисного обеспечения, уязвимостей;

- организация доступа (взлома) к серверу;

- поддержание доступа с целью сохранения контроля над жертвой;

- сокрытие следов вторжения;

- реализация атаки, т.е. нарушение штатного функционирования бизнес-процессов, что влечет нанесение ущерба бизнесу.

Этапы атаки в виде вирусного заражения (ВЗ) сетевым червем:

- проникновение головы червя через какой-либо протокол;

- расшифровка и размещение себя внутри некоторого процесса, включая ядро, или создание нового процесса;

- сокрытие следов;

- распространение червя посредством рассылки себя по 1Р-адресам;

- реализация атаки, например, посредством массового заражения определенных файлов.

Для ВЗ под реализацией понимается и распространение червя, т.к. именно оно может быть целью в случае осуществления DOS-атаки.

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

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

Таким образом, атаку можно представить двумя фазами.

1. Фаза развития атаки, когда действия злоумышленника х1 с X, I = К, С, D, приводят к нарушениям характеристик

{рКз-<л>} =

= (], ..., ])х С, ..., <)*(<, ..., 4

(р?-<’>у - ] .... №<{.... -■

С). Особенность этой фазы в том, что прямой ущерб наносится системным, сетевым ресурсам и системе безопасности бизнес-процесса, т.е. нарушитель «работает» в «клетках» плоскостей <А> и <З>. Например, обнаружено только аномальное увеличение исходящего трафика вследствие нелигитим-ной работы сканера. Ясно, что зафиксировано вторжение в ИС, однако, если это увеличение некритично и другие характеристики в норме, то атака в стадии развития (скорее всего, идет сканирование сети). При этом происходит нарушение безопасности системных ресурсов, однако функции бизнес-

процесса, скорее всего, впрямую не страдают.

Последствия здесь могут быть следующие:

- хищение информации из системы безопасности и операционной, например, файлов паролей, учетных записей и т.п.;

- искажение/уничтожение системных и сетевых файлов, журналов регистрации событий и т.п.;

- переполнение дисковой памяти, например, из-за хранения хакерской информации;

- использование сервера как плацдарма для дальнейшего нападения (например, в качестве «зомби»);

- использование сервера для ретрансляции трафика;

- использование сервера как Smaгf-усилителя и т.п.

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

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

2. Фаза реализации характеризуется тем, что нарушение харак-

<ИС>Л ,,ИС ,ИС^

теристик {Рр- } - (]. , ..., ] )

, ИС ИСч , ИС ИС\ 1 п

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

трафика зафиксировано незаконное обращение к пользовательской БД или произошло нарушение целостности массивов пользовательской информации, то, стало быть, атака перешла в стадию реализации. Ущерб на этом этапе может быть осуществлен:

- вследствие нарушения конфиденциальности:

• хищения/разглашения информации,

- вследствие нарушения целостности:

• искажения/уничтожения информации в БД,

• искажения/уничтожения вычислительного процесса функции,

• перехвата сеанса,

- вследствие нарушения доступности:

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

Таким образом, если в результате мониторинга обнаружена атака на активы сети, то для принятия адекватных мер СППР должна структурировать пространство характеристик {Р“} - {Р7-<ИС>}х {Р3-<л>}х{Рр3-<3>} на некоторые области безопасности и оценивать эти области с точки зрения величины потенциального ущерба функциям бизнес-процесса и вероятности перехода атаки к этапу реализации.

4. Анализ и определение вероятности перехода от фазы развития атаки к фазе реализации (идентификация цели нарушителя)

Любое мероприятие всегда осуществляется с какими-то целями, которые хотелось бы достичь в результате. Нарушитель, производя атаку, также может ставить перед собой одну или несколько целей (обозначим множество таких стратегических целей {StG}), которые предполагают (в терминах модели ОЗЕ^ЯМ) нанесение вреда:

а) бизнес-процессам предприятия (цель: «Нанесение деструктивного вреда объектам плоскости <ИС>);

б) системе администрирования (цель: «Нанесение деструктивного вреда объектам плоскости <А»);

Таблица 2.

Оценочная шкала осуществляемости тактических целей

Терм Слабая - 1 Средняя - 2 Высокая - 3

Кол-во нарушенных признаков 0-30% 31-70% 71-100%

Таблица 3.

Оценки нарушений на плоскости <А> и <З>

Стратегическая цель Тактическая цель Значимость а. Оценка с.

Сл. Ср. Выс.

1 2 3 4 5 6

3Ю1 - Деструктивный вред <З> Получить доступ к файлу паролей 0,7 1

Получить учетную запись пользователя 0,6 1

3Ю2 - Деструктивный вред <А> Получить список открытых портов 0,4 2

Получить карту сети 0,7 2

Получить сведения об ОС, ПО 0,7 3

в) системе безопасности (цель: «Нанесение деструктивного вреда объектам плоскости <З>».

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

Для достижения стратегической цели StG1 необходимо реализовать набор тактических целей StG1 =

- (TkG 1, TkG2, ..., TkGТ), поэтому, чтобы понять, каковы намерения нарушителя в будущем - его стратегическая цель, необходимо понять, какую цель он осуществляет в данный момент.

Тогда, если идентифицировать тактические цели, реализуемый в настоящий момент, можно понять, какие стратегические цели преследует нарушитель в будущем. Например, на рис. 3а) представлена ситуация, когда реализуемые цели ТkG2 и ТkG3 говорят о том, что нарушитель преследует стратегическую цель StG1. А рис. 3б) демонстрирует вариант, когда целью нарушителя, скорее всего, будут и цель StG2, и цель StG3.

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

Алгоритм, который осуществляет СППР для решения данной задачи, следующий.

1. Каждая тактическая цель может быть охарактеризована набором признаков TЮi{g1, g2, ..., gG}, т.е. реакций ОС, которые могут быть зафиксированы подсистемой мониторинга. Например, если TkGi

- выявление пароля пользователя, то набор признаков (д1, g2, ..., gG) может быть следующим:

- отключение механизма аутентификации;

- обращение к файлу паролей;

- блокировка 1Р-адреса, с которого осуществлялось воздействие;

- количество попыток подбора пароля и т.п.

Идентификация TkGi происходит по характеристическим признакам (д1, g2, ..., gG) по следующему правилу (табл. 2):

- если подсистема мониторинга зафиксировала 0-30% нарушенных признаков от их общего числа, будем считать, что данная TkGi осуществляется слабо;

- если 31-70% признаков - осу-ществляемость средняя;

- диапазон нарушений в 71100% говорит о высокой степени осуществляемости.

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

Пусть подсистемой мониторинга получены оценки тактических целей, приведенные в табл. 3 (столбцы 4-6).

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

- предположение о важности реализуемой цели для нарушителя;

- уверенность экспертов в стойкости механизмов защиты, которые будут взломаны или обойдены, если цель реализуется на 100%;

- предположение экспертов о возможностях нарушителя, которые помогут ему реализовать данную цель до конца;

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

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

Далее, каждую тактическую цель экспертам надо оценить с точ-

StG1

StGз

а) б)

Рис. 3. Варианты идентификации стратегических целей

ки зрения выбранного критерия. Пусть эта оценка выражается весовыми коэффициентами а, X а =1

I

(столбец 3 табл. 3).

3. Тогда осуществимость стратегической цели можно вычислить как

)=Ха>с,

г

т.е. Р^1) - 0.7 + 0.6 - 1.3,

3

Р{Ы02 )=£ а;С; =

1

= 0.4 х 2 + 0.7 х 2 + 0.7 х 3 = 4.3.

Таким образом, СППР делает вывод о том, что, поскольку цель «Получить доступ к файлу паро-

лей» оценена подсистемой мониторинга как «слабая», хотя и с высокой значимостью, то цель «Нанесение деструктивного вреда плоскости <З> (системе безопасности)» нарушитель вряд ли ставил перед собой (степень уверенности Р(StG1) - 1.4) как стратегическую. Также, поскольку в данном примере не реализовывались тактические цели, связанные с плоскостью <ИС>, то вряд ли злоумышленник хочет нанести прямой вред бизнес-процессу, т.е. фазы реализации атаки не произойдет. А вот реализация цели StG2 («Нанесение деструктивного вреда объектам плоскости <А> (системе администрирования ИС)») произойдет с уверенностью 4.3.

Заключение

В статье описан подход, позволяющий а) структурировать механизмы обнаружения аномалий, связанных с нарушением безопасности ИС, в соответствии с функциональной матрицей модели OSE/ ЯМ, что делает возможным осуществить процесс валидации Мо требованиям бизнес-процесса, т.е. производить выбор тех или иных Мо в зависимости от характеристик бизнес-процесса и ситуации, связанной с защитой; б) определить место локализации действий нарушителя в ИС во время атаки; в) оценить вероятность того, что злоумышленник нанесет вред не только системным ресурсам, но и прямой вред данным или функциям бизнес-процесса.

Литература

1. Лукинова О.В. Компьютерные методы мониторинга и анализа защищенности при функционировании автоматизированных бизнес-процессов компании // Открытое образование. - 2011. - №4. - C. 37-47.

2. Бойченко А.В., Лукинова О.В. Отображение механизмов защиты на модель OSE/RM // Труды международных научно-практических конференций «Интеллектуальные системы» (AIS’11) и «Интеллектуальные САПР» (CAD-2011). Т. 2. - М.: Физматлит, 2011. - С. 473-476.

3. ISO/IEC TR 14252-1996 Guide to the POSIX Open Sys-tem Environment.

4. Липаев В.В. Методы обеспечения качества крупномасштабных программных средств. - М.: СИНТЕГ, 2003.

5. ГОСТ ИСО/МЭК 9126-93. Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению.

6. Касперски К. Записки исследователя компьютерных вирусов. - СПб.: Питер, 2005.

7. Скудис Э. Противостояние хакерам. - М.: ДМК, 2003.