Компьютерные модели и алгоритмы управления безопасностью информационных систем
Федеральное государственное бюджетное учреждение науки ИНСТИТУТ ПРОБЛЕМ УПРАВЛЕНИЯ
им. В.А. ТРАПЕЗНИКОВА РОССИЙСКОЙ АКАДЕМИИ НАУК
На правах рукописи
ЛУКИНОВА Ольга Васильевна
КОМПЬЮТЕРНЫЕ МОДЕЛИ И АЛГОРИТМЫ УПРАВЛЕНИЯ БЕЗОПАСНОСТЬЮ ИНФОРМАЦИОННЫХ СИСТЕМ
Специальности: 05.13.11 – Математическое и программное обеспечение вычислительных машин, комплексов и компьютерных сетей
05.13.19 – Методы и системы защиты информации, информационная безопасность
АВТОРЕФЕРАТ
диссертации на соискание ученой степени
доктора технических наук
Москва, 2013
Работа выполнена в Федеральном государственном бюджетном учреждении науки Институте проблем управления им. В.А. Трапезникова Российской академии наук
Научный консультант доктор технических наук, профессор, главный научный сотрудник ИПУ РАН
Трахтенгерц Эдуард Анатольевич
Официальные оппоненты доктор технических наук, профессор кафедры информационной безопасности Государственного университета гражданской авиации
Иванилов Евгений Леонидович
доктор физико-математических наук, профессор,
действительный член Академии криптографии РФ Кузьмин Алексей Сергеевич
доктор технических наук, профессор кафедры информационных систем Тверского государственного технического университета,
Семенов Николай Александрович
Ведущая организация – Санкт-Петербургский Национальный исследовательский университет информационных технологий, механики и оптики, кафедра проектирования и безопасности компьютерных систем
Защита состоится « 3 » марта 2013 г. в 11 час. на заседании диссертационного совета №3 (Д 002.226.03) Института проблем управления по адресу: 117977, г. Москва, ул. Профсоюзная, 65.
С диссертацией можно ознакомиться в библиотеке Института проблем управления им. В.А. Трапезникова
Автореферат разослан «_____» _____________2013 г.
Ученый секретарь диссертационного совета
кандидат технических наук А.А. Кулинич
Актуальность. Защита информационных технологий, реализованных в виде информационных систем (ИС), в настоящее время становится одной из критических проблем. Она требует системного подхода к организации защиты, целостного систематизированного представления об объекте защиты, комплексного непрерывного управления информационной безопасностью (ИБ) ИС в интересах предприятия. Однако существующая практика разработки систем защиты, которые должны обеспечивать безопасность ИС, основана на том, что комплекс защитных мер выбирается исходя из возможных потенциально-опасных угроз (атак), свойственных используемой ИС (на основе типизированных списков уязвимостей и неформализованных представлений нарушителя) и соображений приемлемости ущерба (риска).
Развитие существующего подхода видится в более комплексном и системном взгляде на организацию защиты посредством решения следующих задач: выборе средств защиты (СЗ) с учетом архитектурно-функциональной специфики ИС, т.е. ориентироваться на обеспечение безопасности ИС, а не на противодействие угрозам; введение для системы защиты целевой функции, измеряющей безопасность; обеспечения и контроля заданного уровня безопасности процессов, происходящих в ИС; формализованного представления ИС как объекта защиты, на основе которого можно было бы построить технологию выбора защитных средств и механизмов с учетом функциональных особенностей компонент ИС. Эффективность методологической базы защиты информационных технологий предприятий связана с рациональной организацией управления жизненным циклом (ЖЦ) системы защиты, как основы для построения компьютерной системы поддержки управления безопасностью информационных систем. Сегодня ИС и системы защиты разрабатываются разными специалистами. Инструментальные средства и технологии, которые активно используются в практике проектирования ИС, не содержат поддержки решений по безопасности, т.к. последние напрямую не влияют на выполнение основных функций ИС. Фактически, система защиты достраивается к уже спроектированной ИС. В результате такие наложенные средства защиты могут контролировать только результат процесса функционирования ИС, но не могут обеспечить контроль и защиту самого процесса.
Обобщение характера названных задач определило необходимость создания методологических положений, которые позволили бы придать системность, органичность и законченность процессу проектирования и сопровождения защиты ИС.
В работе предлагается «бизнес-процессный» подход, позволяющий встроить вопросы защиты корпоративной информационной системы в современную методологию управления ИT-средой в интересах предприятия. В результате многие вопросы, связанные с определением необходимого уровня безопасности информационных ресурсов, оценкой величины ущерба от вторжений, планированием достаточности средств защиты решаются на качественно другом уровне. Важным фактором, влияющим на эффективность управления средствами защиты, является отсутствие прямых доходов от их использования. Поэтому степень защищенности данных, обрабатываемых информационными системами, и, следовательно, расходы на поддержание этого обеспечения обычно стараются соразмерить с их ценностью (экономической, государственной, военной и т.п.) и рисками потери этой ценности. Эта ценность не всегда определяется в денежном выражении. Поэтому сопоставление расходов на информационную безопасность с ценностью охраняемых данных является нетривиальной и весьма актуальной задачей. Рассмотрение вопросов защиты с точки зрения интересов бизнес-процессов позволит использовать методы, существующие в теории управления предприятием, для оценки и сопоставления возможного ущерба с затратами на безопасность.
Базовым инструментом предлагаемого подхода является методология открытых систем (функциональной стандартизации), основывающаяся на унифицированном представлении информационной системы., которое дает возможность совместить характеристики жизненного цикла (ЖЦ) системы защиты и жизненного цикла ИС.
Разработанный подход является методологической базой для непрерывного управления безопасностью ИС в течение жизненного цикла системы защиты, которое предлагается строить на основе:
- Представления ИС и системы защиты как единого целого;
- Интеграции в единый процесс технологий сбора и анализа данных о состоянии защищаемого объекта, планирования и контроля за функционированием средств защиты, восстановления работоспособности объекта защиты после несанкционированных вторжений.
- Формализации методов формирования и принятия решений, их оценки с учетом субъективных предпочтений лиц, принимающих решения (ЛПР).
Трудность задачи заключается в отсутствии формализмов, описывающих такие слабо формализуемые понятия процесса проектирования системы защиты, как качество информационной безопасности, угроза, возможности злоумышленника, механизмы и объект защиты, поэтому сегодня выбор защитных средств производится вручную. Разработка компьютерных систем поддержки проектированием систем защиты и ее управлением в течение ЖЦ является весьма актуальной проблемой.
Указанные факторы определили направление диссертационного исследования, заключающегося в разработке методологических положений обеспечения безопасности ИС на основе бизнес-процессного подхода, моделей и алгоритмов управления ЖЦ комплексной системы защиты (КСЗ) от процедур поддержки принятия решений при формировании требований к КСЗ до ее сопровождения в рамках предлагаемого подхода.
Степень разработанности темы на концептуальном уровне является полной, что подтвер-ждается тем, что разработаны не только методологические основы проектирования и управления безопасностью ИС, но и их поддержка в виде модельно-алгоритмического обеспечения.
Целью диссертационной работы является разработка методологических основ, моделей и алгоритмов создания компьютерных систем управления безопасностью информационных комплексов, в том числе, концептуального проектирования комплексной системы защиты, принципов создания защищенных ИС с учетом их функционального назначения.
Основными задачами работы являются:
А). Разработка и исследование принципов и положений защиты информационных систем с учетом их функционального назначения (бизнес-процессный подход), а также принципов проектирования программных средств, обеспечивающих безопасность вычислительных комплексов.
Б). Развитие функциональной логической (референсной) модели открытой среды в части вариантов конкретизации ее компоненты защиты, что позволит совместить ЖЦ ИС и ее защиты и явится основой для концептуального и детального проектирования системы защиты.
В). Разработка комплекса моделей и алгоритмов принятия решений для компьютерного управления безопасностью ИС в течение ЖЦ системы защиты ИС в том числе:
1. поддержки принятия решений при формировании требований к системе защиты:
- компьютерное формирование целевых векторов безопасности для объекта защиты на основе оценок значимости информационных ресурсов и угроз среды ИС,
- компьютерный выбор различных стратегий защиты (политики безопасности), задающих условия выбора вариантов системы защиты;
2.поддержки принятия решений при проектировании системы защиты:
- компьютерный выбор рациональных вариантов системы защиты в соответствии с вариантами конкретизации защитной компоненты модели открытой среды и стратегией защиты,
- компьютерное прогнозирование развития атаки и осуществление апробации вариантов системы защиты на списке возможных угроз (сценарный анализ вариантов);
3. принятия решений при эксплуатации/сопровождении системы защиты:
- идентификация и оценка целей нарушителя, фазы атаки и возможных последствий атаки для бизнес-процессов с целью определения режима восстановления бизнес-процессов;
- прогноз развития атаки с целью контроля состояния среды;
- выявление ситуаций, когда необходима модификация системы защиты;
- определение параметров оперативного реагирования для сдерживания атаки, ликвидации ее следов, восстановления ресурсов.
Г). Разработка формализованного представления понятий предметной области «проектирование систем защиты ИС», которое позволяет автоматизировать процесс управления ЖЦ системы защиты.
Д). Разработка функциональной архитектуры системы поддержки управления безопасностью (СПУБ), а также итерационного алгоритма функционирования СПУБ на протяжении ЖЦ системы защиты.
Методы исследования. В процессе исследования использовались методы инженерии и представления знаний, поиска и принятия решений, теории выбора и многокритериальной оптимизации, структурного и системного анализа.
Объектом исследования является безопасность защищаемых информационных систем.
Предметом исследования являются модели, компьютерные методы и алгоритмы обеспечения безопасности информационных систем на протяжении их жизненного цикла.
Научная новизна результатов:
А). Разработаны принципы и положения бизнес-процессного подхода к защите информационных систем, на основе которых представлена методология проектирования программных комплексов управления безопасностью информационных систем.
- Предложен подход, в рамках которого целевым защищаемым активом являются бизнес-процессы предприятия и их непрерывное функционирование с точки зрения угроз информационной безопасности. ИС, как объект защиты, является средством реализации автоматизированных бизнес-процессов предприятия. Поэтому защиту предложено строить исходя из интересов функционирования этого актива. Это дает возможность: рассматривать организацию безопасности информационной системы комплексно с учетом ее архитектурно-функциональных особенностей; оценить достаточность планируемых к использованию механизмов и средств защиты; определить метрики и целевой уровень безопасности для защищаемого актива; соотнести жизненные циклы ИС и системы ее защиты; оценить ущерб вследствие нарушения безопасности актива.
- Предложен вид целевой функции системы защиты в виде основных свойств безопасности (конфиденциальности, целостности, доступности и т.п.), которые могут быть измерены в лингвистических шкалах.
- Предложено использовать для представления ИС функциональную референсную модель открытой среды, что позволяет рассматривать ИС а) как систему, интегрирующую функциональность нескольких аспектов информационной технологии, в частности: прикладную, административную, защитную, б) как единый объект защиты. Единое представление объекта защиты является методологической основой совмещения ЖЦ ИС и системы ее защиты, что позволяет рассматривать проектирование ИС и системы ее защиты как органичный процесс, учитывающий функциональные особенности и взаимосвязи обеих систем.
Б). Разработаны варианты конкретизации модели открытых систем стандарта ISO/IEC TR 14252 (в части защитной компоненты), которые создают основу для концептуального и детального проектирования системы защиты. Разработана структурная процессная модель, которая позволяет формировать концептуальное (межкатегорийное в смысле указанного стандарта) представление системы защиты, и описана связь между бизнес-процессами предприятия и процессами защиты.
В). Разработаны процедуры и алгоритмы поддержки принятия решений при формировании концептуального представления системы защиты в том числе:
1. Модель влияния факторов безопасности, отражающая генеральные стратегии политики безопасности, которые определяют критерии рационального выбора вариантов системы защиты.
2. Процедуры формирования целей безопасности (требований) на основе алгоритмов оценок ценности бизнес-процессов и выбора рациональных вариантов проектируемой системы защиты в соответствии с генеральными стратегиями, целями безопасности и межкатегорийным представлением системы защиты.
3. Алгоритм сценарного анализа на основе прогноза целей нарушителя и развития атаки для компьютерной апробации вариантов системы защиты
Г). Разработаны процедуры и алгоритмы поддержки принятия решений при эксплуатации/сопровождении системы защиты, в том числе для:
1. Анализа инцидента безопасности (атаки) с целью выявления режима и очередности восстановления бизнес-процессов: прогнозирование целей нарушителя, оценка возможности их реализации и выявление фазы атаки, идентификация нарушенного критерия безопасности и оценка серьезности нарушений.
2. Анализа ситуации с целью принятия решения о необходимости модификации системы защиты.
3. Определения параметров оперативного реагирования для решения задач сдерживания атаки, ликвидации ее следов, восстановления ресурсов.
Д). Предложен комплекс семантических моделей, представляющих концептуальную основу баз знаний и данных факторов, связанных с информационным обеспечением разработки и сопровождения системы защиты.
Е). Разработана функциональная архитектура программного обеспечения системы поддержки управления безопасностью (СПУБ) информационных систем, которая включает: 1) инструментальное средство в виде системы поддержки принятия решений (СППР) при проектировании комплексной системы защиты (КСЗ), 2) целевые компоненты: комплексная система защиты, обеспечивающая безопасность ИС, система управления (СУ) комплексной системой защиты при ее эксплуатации и сопровождении, система мониторинга (СМ) функционирования бизнес-процессов, база данных и знаний, система администрирования компонентами СПУБ.
Представлен итерационный алгоритм функционирования компонент СПУБ, который осуществляет непрерывное управление безопасностью ИС посредством процедур поддержки процессов ЖЦ системы защиты.
Положениями, выносимыми на защиту являются:
- Методологические принципы бизнес-процессного подхода к обеспечению безопасности информационных систем с учетом их функционального назначения, включая модели формирования комплекса средств противодействия нарушениям безопасности ИС.
- Методологические основы концептуального проектирования программных систем непрерывного управления безопасностью ИС, включая модели и процедуры создания и сопровождения комплексов средств защиты ИС.
- Компьютерные модели и алгоритмы поддержки принятия решений для управления безопасностью ИС в течение всего ЖЦ системы ее защиты.
Достоверность. Достоверность научных положений и результатов, полученных в работе, обосновывается анализом разработанных методов и алгоритмов, непротиворечивостью современным представлениям в области обеспечения безопасности ИС, систематизацией и развитием в части: использования апробированных подходов в области поддержки принятия решений, широтой применения семантических и концептуальных моделей, многолетним опытом модельных представлений ИС, а также результатами практического использования предложенных в диссертационной работе моделей, алгоритмов и механизмов.
Теоретическая и практическая ценность. Полученные в диссертационной работе результаты позволяют:
- Внести существенный вклад в решение важной народнохозяйственной проблемы создания компьютерных технологий поддержки управления безопасностью информационных систем.
- Разработать методологические основы создания защищенных ИС.
- Разработать ряд теоретических положений, развивающих теорию управления безопасностью ИС.
- Разработанные в работе методологии и модели использованы при создании защищенной ИС в Пенсионом фонде РФ.
- Полученные результаты легли в основу учебного курса по основам проектиро-вания систем защиты базовой кафедры №252 компьютерной безопасности МГТУ МИРЭА.
Диссертационная работа выполнена в рамках плановой тематики Института проблем управления им. В.А. Трапезникова РАН. Часть результатов диссертации получена в рамках НИР, выполнявшихся в Академии криптографии РФ (в интересах ФСБ России).
Апробация работы. Основные положения и результаты диссертационной работы докладывались и представлялись на следующих конференциях: IV Российской научно-методической конференции «Совершенствование подготовки IT-специалистов по направлению «Прикладная информатика» для инновационной экономики» (Москва, 2008), XII научно-практической конференции «Реинжиниринг бизнес-процессов на основе современных информационных технологий» (Москва, 2009), международных научно-практических конференций «Интеллектуальные системы» (AIS’09) и “Интеллектуальные САПР” (CAD-2009), (Дивноморск, 2009), 3-й международной конференции «Управление развитием крупномасштабных систем» (Москва, 2009), международной научно-практической мультиконференции «Управление большими системами-2009» (Москва, 2009), научной сессии НИЯУ МИФИ (Москва,2010), XIII научно-практической конференции «Реинжиниринг бизнес-процессов на основе современных информационных технологий» (Москва, 2010), международных научно-практических конференций «Интеллектуальные системы» (AIS’10) (Дивноморск, 2010), 12-й Национальной конференции по искусственному интеллекту с международным участием (Тверь, 2010), XIV научно-практической конференции «Реинжиниринг бизнес-процессов на основе современных информационных технологий» (Москва, 2011), 5-й международной конференции «Управление развитием крупномасштабных систем» (Москва, 2011), конгрессе по интеллектуальным системам и информационным технологиям, (Дивноморск, 2011), Международной научно-практической конференции «Управление большими системами 2011» (Москва, 2011), Конгрессе по интеллектуальным системам и информационным технологиям, (Дивноморск, 2012), XVIII Всероссийской школе-коллоквиуму по стохастическим методам и XII Всероссийскому симпозиуму по прикладной и промышленной математике (Сочи, 2011), IXX Всероссийской школе-коллоквиуму по стохастическим методам и XIII Всероссийскому симпозиуму по прикладной и промышленной математике (Сочи, 2012), 7-й Международной научно-практической конференции «Интегрированные модели и мягкие вычисления в искусственном интеллекте» (Коломна, 2013), 3-й научно-практической конференции «Актуальные проблемы системной и программной инженерии», (Москва, 2013).
Публикации. Основные результаты исследований по теме диссертации содержатся в 34 публикациях, в том числе 16 публикаций в журналах перечня Высшей аттестационной комиссии.
Структура и объем диссертации. Работа состоит из введения, пяти глав, заключения, трех приложений, списка литературы из 216 наименований.
СОДЕРЖАНИЕ РАБОТЫ
Во введении к диссертационной работе обосновывается актуальность исследованной тематики, формулируются цели, задачи и направления исследований, излагаются научная новизна, достоверность и практическая ценность полученных результатов.
Первая глава посвящена изложению теоретических и методологических основ обеспечения безопасности информационных систем, основанных на процессном подходе и принципах открытой среды.
В стандартах ИБ подчеркивается, что в качестве защищаемых активов необходимо рассматривать активы, имеющие ценность для организации. Методология управления ресурсами современного предприятия, основанная на процессном подходе, определяет основной ценностью бизнес-процесс, т.к. он, наряду с видами деятельности, интегрирует и ресурсы предприятия (материальные, финансовые, информационные, человеческие) в единый функционирующий комплекс, приносящий какой-либо бизнес-результат (в контексте данной работы речь идет о таких бизнес-процессах, средой реализации которой являются информационные системы). Поэтому в диссертации задача организации защиты информационных ресурсов сформулирована как задача обеспечения безопасного функционирования автоматизированных бизнес-процессов предприятия. Безопасность как качество описывается свойствами целостности (C), доступности (D), конфиденциальности (K) и др., которые могут задаваться лингвистическими значениями.
Привязка к бизнес-процессам позволяет понять, каков вклад бизнес-процесса в совокупный результат, каков его приоритет (Pr) для предприятия. Поэтому ЛПР может и оценить ущерб (U), если функционирование бизнес-процесс будет нарушено, и назначить требуемый уровень безопасности
.
Для описания постановки задачи введем следующие понятия, взаимовлияние которых представлено на рис. 1.
А). Объект защиты (ОЗ) – информационная система, ассоциируемая с бизнес-моделью, которая представляется совокупностью бизнес-процессов предприятия {BM}={b/p1, b/p2, …, b/pS}.
Б). Целевую функцию системы защиты введем как вектор критериев основных свойств безопасности 
в нечетком пространстве соответствующих лингвистических переменных. Нарушение уровня вектора 
является конечной целью любой атаки.
В). Защитные механизмы (Мх), равно как и средства защиты (СЗ), реализующие те или иные Мх, являются управляющими параметрами системы защиты. Они обеспечивают требуемый уровень безопасности 
, т.к. обладают свойством стойкости к внешним воздействиям.
Г). Внешние воздействия или атаки, т.е. реализуемые угрозы Y(А). Их реализация зависит от наличия уязвимостей программно-аппаратного обеспечения (возможность реализации угрозы), а также нарушителя, который смог воспользоваться уязвимостью (возможность возникновения угрозы).
Тогда система защиты описывается кортежем следующих объектов: <S>={{ОЗ}, 
, {Y}, {Mx}}. Таким образом, система <S> представляет собой комплекс программно-аппаратных механизмы защиты {Mx}, которые обеспечивают целевую функцию
и противостоят угрозам {Y}. Назовем такую систему комплексной системой защиты (КСЗ).
На рис. 2 представлен цикл проектирования системы <S>, сочетающий традиционного представление и положения предлагаемого подхода.
Далее возникает задача представления объекта защиты в виде некоторой модели, причем модель должна в полной мере отражать функциональность ИС и позволять декомпозировать основные цели по функциональным группам ОЗ. Для этой цели была выбрана референсная модель среды открытых информационных систем OSE/RM (Open Systems Environment/Reference Model), предложенная комитетом IEEE POSIX. Данная модель представляет ИС как сочетание двух компонент: прикладной (приложений, реализующих функции бизнес-процесса) и платформенной, которая обслуживает запросы приложения. Модель структурируется в виде матрицы компонент («клеток»), отражающих функциональные группы ИС (базовая передняя плоскость <ИС>) (рис.3).
Трехмерность модели позволяет структурировать не только функциональность самой ИС (плоскость <ИС>), но и систем администрирования и защиты (плоскости <А> и <З> соответственно) (к сожалению, в указанных стандартах плоскость<З> не проработана).
Таким образом, понятие ИС включает и интегрирует в единую систему функциональность трех граней информационной технологии (хотя могут быть рассмотрены и другие): прикладной (плоскость <ИС>), административной (плоскость <А>) и защитной (плоскость <З>).
Тогда задача обеспечения безопасности для ИС, представленной моделью OSE/RM, формулируется как обеспечение свойств безопасности 
для реализаций «клеток» плоскостей <ИС>, <А>, <З>. В диссертации описана также интерпретация этих свойств для всех функциональных компонент.
Для решения поставленной задачи обеспечения безопасности ОЗ в рамках диссертации разработана референсная структурная модель системы защиты, дополняющая функциональное представление ИС. Это означает, что в развитие модели OSE/RM была построена и проработана плоскость защиты <З>, причем в 3-х вариантах.
1. Межкатегорийном, что означает интеграцию «клетками» плоскости <З> совокупности защитных механизмов, обеспечивающих защиту реализаций соответствующих «клеток» плоскостей <ИС>, <А> и самое себя. Для построения межкатегорийной плоскости <З>: а). разработана классификация множества Мх, б). определены принципы их взаимосвязи, в). построены онтология внутренней структуры механизма и экземпляры основных Мх, г). разработана референсная процессная модель защиты {BZ} (на примере приложения плоскости <ИС>). Она позволяет производить сборку межкатегорийной плоскости <З> с учетом реализации конкретного бизнес-процесса. В ее основу положена структуризация по модели OSE/RM типовых информационных операций IOmk, над данными, осуществляемых в информационной системе и реализующих операции бизнес-процесса. Здесь k- номер операции, m – номер функции s-го бизнес-процесса, которому принадлежит операция. Рассмотрены следующие операции: хранение, обработка данных в системе, передача данных, реализуемая через съемные носители, локальную или внешнюю сеть. Тогда модель защиты s-го бизнес-процесса представляет собой кортеж 
), где
- процесс защиты, т.е. последовательность «клеток», реализующая информационную операцию и «закрытая» защитными механизмами.
Кроме того, показана связь бизнес-процессов предприятия и процессов защиты. Обозначим модель OSE/RМ в виде матрицы M. Тогда IOmk, реализуемая последовательностью «клеток» модели OSE/RM, представляется матрицей 
=||mijk||, i=14, j=14, k K, K -количество операций, реализующих m-ю функцию, такой что:
- mijk =1, если «клетка» задействована в операции,
- mijk =0, если «клетка» не задействована в операции.
Тогда матрица 
представляет собой отдельный бизнес-процесс защиты 
.
Таким образом, семейство матриц ||Mkm|| определяет модель защиты m-ой функции 
, i=14, j=14, m=1M. Матрица 
, s=1,2,…,S - модель защиты s-го бизнес-процесса, а 
- процессная модель защиты, построенная в соответствии с бизнес-процессами предприятия {BM}={b/p1, b/p2, …, b/pS}.
Таким образом, речь идет о разработке технологии сборки комплекса Мх, обеспечивающих защиту «клеток» и их реализаций в соответствиями с целевым вектором 
, т.е.о технологии формирования функциональной архитектуры КСЗ. Проработка технологии на уровне различных алгоритмов: оценки уровня защищенности и потребности в дополнительных средствах защиты, формирования целей и значений критериев безопасности и др. представлены в главах 4, 5.
2. Поскольку система защиты также является информационной системой, то ее функциональность, в свою очередь, должна быть структурирована в соответствии с принципами базовой плоскости <ИС> с поправкой на контекст (рис.4). Это означает, что система защиты должна иметь прикладную компоненту в виде различных приложений, реализующих межкатегорийное представление, платформенную, удовлетворяющую потребности приложений, а также матричную структуризацию, отражающую исходную. Такое представление дает понимание принципов технической проработки КСЗ, базу для выполнения проекта по ее созданию, потому, что выбранные в соответствии с целевыми критериями программно-аппаратные СЗ должны иметь программный АРI-интерфейс, совпадающий с платформенным.
3. Третий аспект заключается в возможности структуризации по «клеткам» модели факторов, связанных с деятельностью нарушителя в системе: идентификации атаки, моделирования распространения атаки, прогнозирования целей нарушителя и т.п. Таким образом, представленная модель OSE/RM, явилась основой, относительно которой строились алгоритмы, приведенные в последующих главах, и структурировались параметры, снимаемые в ходе мониторинга.
Во второй главе исследованы и разработаны состав и функциональная структура СПУБ ИС и ее компонент. Приведен обзор различных типов систем поддержки решений, а также анализ возможностей систем обнаружения вторжений, которые в своем составе содержат технические средства и используются для защиты ИС. Отмечается, что несмотря на интеграцию многих защитных механизмов в рамках единой системы, они не решают всех задач, связанных с управлением безопасностью в контексте ЖЦ системы защиты.
Подход, описанный в главе 1, позволяет совместить ЖЦ ИС и КСЗ. ЖЦ ИС, в соответствии со стандартами ЖЦ ИС и программных систем, состоит из трех стадий, включая «нулевой» этап консалтинговых работ. Тогда стадии ЖЦ системы защиты представляются следующим образом:
- Формирование требований (ТР). Здесь в рамках консалтинга ЛПР определяет стратегические приоритеты организации в области политики безопасности; строится модель бизнес-процессов {BM}. Эта модель служит основанием для выявления целей безопасности
к бизнес-процессам и детализации их по «клеткам» ИС. - Проектирование. Включает а). разработку функциональной архитектуры КСЗ, которая моделируется межкатегорийной плоскостью <З>, б). детальное проектирование, т.е. сборку проектной плоскости <З> из СЗ согласно механизмов межкатегорийной плоскости, интеграцию различных компонент системы с учетом API-интерфейсов.
- Эксплуатация и сопровождение КСЗ. На стадии эксплуатации осуществляется мониторинг функционирования бизнес-процессов, результаты которого являются (при необходимости) входом для стадии сопровождения (модификации, модернизации). Сопровождение заключается в том, чтобы в случае, если КСЗ пропустила атаку, оценить обстановку и сдержать развитие атаки, восстановить работоспособность бизнес-процессов, модифицировать КСЗ.
Таким образом, под управлением ЖЦ системы защиты понимается комплексное решение задач, обозначенных в п.1-3. На рис. 5 изображено детализированное соответствие стадий ЖЦ ИС и КСЗ, приведена «раскладка» задач, моделей и алгоритмов, которые разработаны в рамках предлагаемого в диссертации подхода и составляют основу программного обеспечения СПУБ. На рис.6 изображен компонентный состав СПУБ:
Рис.5 Представление ЖЦ ИС и КСЗ
- Система поддержки принятия решений (СППР), инструментальная система, ориентирована на задачи стадии формирования требований к КСЗ и ее проектирования. Она осуществляет выбор и оценку вариантов КСЗ, предлагает их ЛПР и экспертам для согласования и окончательного решения.
- Система управления (СУ) решает задачи, связанные с сопровождением КСЗ, если произошел инцидент безопасности, зафиксированный системой мониторинга. Комплекс задач сопровождения приведен в главе 5.
- Система мониторинга (СМ) осуществляет сбор данных о функционировании бизнес-процессов и действиях нарушителя в системе, их анализ с точки зрения выявления нарушений (инцидента) безопасности, контроля управляющих воздействий и запись данных в соответствующие базы. Данные мониторинга и анализа нужны для принятия решений и в СППР, и в СУ. Алгоритмы анализа представлены в главах 4, 5.
- Информационное обеспечение СПУБ включает БД и БЗ долговременного и оперативного характера. БД хранят накопленные данные о состоянии объекта защиты, инцидентах безопасности, результатах расчетов; данные об экспертах, включая их «веса», и предпочтениях ЛПР; предварительно сформированные списки критериев оценки для различных алгоритмов и их измерительные шкалы. Базы знаний включают информацию по различным факторам проектирования: средствам и механизмам защиты, компонентам модели угроз, для их построения разработан комплекс семантических моделей, описанный в главе 3.
- Система администрирования, осуществляет взаимодействие, контроль и управление всеми составными компонентами СПУБ.
Таким образом, СПУБ осуществляет контроль, управление и поддержку основных этапов ЖЦ системы защиты.
Принятие решений на этапе консалтинга предполагает учет многих аспектов безопасности ИС. Для этого разработана концептуальная карта (КК) влияния факторов информационной безопасности в процессе проектирования (формирования) вариантов КСЗ (рис.7).
Здесь вершины графа имеют следующую интерпретацию:
- NP – потенциал нарушителя, оцениваемый на основании его возможностей. Модель нарушителя и алгоритмы оценки его потенциала описаны в главе 3.
- R(X) – рейтинг уязвимости «клетки», вычисляется на основе оценок частоты использования уязвимости нарушителем и трудности ее обнаружения (алгоритм приведен в главе 4ЛП). Рейтинг влияет на возможность осуществления угрозы.
- MN – мотивация нарушителя, оценивается экспертами.
- Р(А) – возможность осуществления угрозы (атаки) нарушителем, который обладает потенциалом NP и смог воспользоваться уязвимостью с рейтингом R(X).
- F(A) – сила атаки (угрозы), ассоциируемая с ресурсами (усилиями), затрачиваемыми на преодоление стойкости защитных механизмов.
– вектор критериев, которые оценивают уровень безопасности. - Pr(U) – оценка ценности тех информационных ресурсов ИС, которые используются пользователем при решении своих бизнес-задач. Ценность ресурсов определяет и ущерб U в случае, если эти ресурсы пострадают от атаки. То и другое может быть выражено как в денежном измерении (например, недополучение дохода), так и неденежном (заметим, что если речь вести относительно бизнес-процесса, то существуют методики и методы, позволяющие это сделать).
- R – риски, получения ущерба Pr(U) в случае осуществления атаки и нарушения критериев KS.
- Мх(СЗ) – защитные механизмы, реализуемые программно-аппаратными средствами. Тот или иной набор СЗ образует вариант КСЗ.
Анализ КК позволяет выделить несколько контуров, отражающие различные парадигмы в управлении безопасностью. СППР выводит КК на экран и предоставляет ЛПР возможность выбирать разные стратегии организации защиты (генеральные стратегии), которые определяют те или иные критерии рационального выбора вариантов системы защиты.
Контур 1. Включает вершины F(A), KS, Mx(СЗ). Если ЛПР выбирает вершину F(A), то выбор защитных средств СППР производит только исходя из стандартных угроз, и будет осуществлен традиционный способ управления, по базовому (минимальному) уровню, когда мероприятия по оценке рисков не производятся, а уровень безопасности оценивается постфактум. Если целью выбирается вершина KS, то, даже для базового набора угроз, производится более тонкий подход с назначением руководителем определенного уровня безопасности по алгоритму главы 5.
Контур 2. Вершины F(A), R, Mx(СЗ) отражают политику, требующую разработки повышенных требований к безопасности, основанную на управлении рисками.
Контур 3. Вершины KS, R, Mx(СЗ). Здесь реализуется идея управления исходя из оптимального баланса стоимости КСЗ, рисков и уровня безопасности.
Каждый контур образован двунаправленными отношениями. Это означает, что происхо-дит взаимовлияние факторов и, стало быть, выбор той или иной вершины в качестве цели определит направление стрелок и генеральную стратегию политики безопасности предприятия. Во 2-й главе приводятся расчетные алгоритмы следующих стратегий третьего контура:
- Стратегия наибольшей безопасности - выбор вариантов КСЗ на основе обеспечения по максимуму целевого уровня критериев безопасности
. Этот уровень определяется исходя из интересов бизнеса, нормативных документов и оценок угроз. Тогда можно ожидать, что риски в большинстве нейтрализуются затребованной стойкостью Мх, но стоимость такой системы – немалой: 
(здесь и далее символ «*» означает выбранное, фиксированное значение. - Стратегия пороговой стоимости Stпорог – выбор вариантов КСЗ, когда приоритетом организации является экономия, тогда надо быть готовым к невысокому уровню безопасности и значительному риску:
. - Стратегия приемлемой стоимости - когда выбираются такие защитные средства, чтобы их стоимость St не превосходила возможного ущерба U*. Очевидно, что уровень безопасности получим в пределах от минимально до максимально возможных:
. - Стратегия приемлемого риска и приемлемой стоимости – когда уровень безопасности определяется из уровней ущерба U* и риска R*, который организация готова допустить при нарушении безопасности
.
На основе моделей и алгоритмов, реализуемых в рамках ЖЦ, СППР выполняет многовариантные расчеты, производит оценки, формирует, выбирает варианты решений и т.д. Взаимосвязь задач, которые решает компьютерная система, в виде структуры функциональных блоков, изображена на рис.8.
Рис. 8. Функциональная структура СППР
Блок 1. Служит для выявления предпочтений ЛПР в вопросах организации защиты ИС, т.е. выбора генеральной стратегии защиты. Для этого СППР выводит на экран концептуальную карту, по которой ЛПР отмечает предпочитаемые контур управления и вершину. Тем самым идентифицируется та или иная генеральная стратегия, алгоритм которой будет реализовывать СППР.
Блок 2. На экран выводится список критериев, на основании которых СППР проводит оценку ценности данных, обрабатываемых бизнес-процессом и определяет приоритет Pr(Si) каждого бизнес-процесса с точки зрения бизнеса. Алгоритм процедуры описан в главе 4.
Блок 3. СППР выявляет предпочтения ЛПР по вопросам безопасности, строится дерево целей и критериев безопасности 
, определяется значения целевого вектора безопасности
, где Т* означает фиксированное значение, т.е. тре-буемый уровень защиты для ресурсов Si–х бизнес-процессов. Алгоритм приведен в главе 5.
Блоки 4, 7. Эти блоки выполняют следующие действия СППР:
1. Выявление данных и занесение их в БЗ модели угроз. Онтологические классы уязвимостей, возможностей нарушителя, потенциально-опасных атак для этой модели разработаны и представлены в главе 3.
2. Прогноз и оценку осуществимости атаки (стратегии нападения). Для этого разработаны: алгоритм развития атаки по «клеткам» модели OSE/RM, использующий метод порождающей грамматики, алгоритмы идентификации целей нарушителя и оценки их осуществимости (главы 4,5).
3. Прогноз того, насколько выбранные защитные механизмы и средства смогут противостоять атаке. В главах 4,5 описаны алгоритмы, основанные на сравнении стойкости Мх и силы атаки в каждой р-й «клетке» модели.
Блоки 5,6. Решают следующие задачи:
1. Выбор стратегий защиты, т.е. вариантов КСЗ в виде набора (Мх1,Мх2,…,МхК) (сборка межкатегорийной плоскости <З> в соответствии с процессной моделью BZ) и их оценка на соответствие критериям 
.
2. Выбор вариантов КСЗ в виде наборов из плановых средств защиты 
, реализующих Мх межкатегорийной плоскости и их оценка на соответствие вектору локальных критериев 
: функциональных издержек на инфраструктурное оборудование ИС; стоимости; эксплуатационных характеристик. Здесь осуществляется сборка проектной плоскости защиты <З>.
Задача рационального выбора вариантов описана в главе 5.
Блок 8. Осуществляется в диалоге между ЛПР и СППР, заключается в следующем: ЛПР предлагается список вариантов КСЗ, отранжированных компьютерной системой в соответствии с векторами 
, 
. Если ЛПР выбирает один из вариантов – алгоритм окончен, иначе ЛПР может произвести следующие действия:
- запросить вывести характеристики варианта: оценочные критерии, их веса и базовые шкалы – изменить их, перейти к блоку1,
- поменять процедуру ранжировки и перейти к блоку 1,
- поменять и процедуру ранжировки, и характеристики варианта и перейти к блоку 1.
Блоки 9, 10 реализуют известные методы согласования и ранжирования, поэтому описывать их нецелесообразно.
На этапе эксплуатации КСЗ оперативный контроль и анализ ситуации осуществляют система мониторинга (СМ) и система управления (СУ). Если злоумышленник осуществил некоторое действие
, которое не обнаруживается плановыми средствами защиты {PZ}, из которых состоит КСЗ, будем говорить что произошел инцидент безопасности. Под инцидентом безопасности будем понимать вектор 
, нарушающий уровни Т* критериев 
, заданных для данного бизнес-процесса.
Задача оперативного управления возникает в случае, если КСЗ не смогла нейтрализовать очередную атаку злоумышленника на ИС и, в терминологии ЖЦ, возникает необходимость перейти к стадии сопровождения. Задача заключается в том, чтобы идентифицировать данный инцидент, понять, каковы могут быть его последствия, выбрать методы борьбы с инцидентом, модифицировать КСЗ согласно новой обстановке.
Для решения задачи меры и средства, используемые на практике, были классифицированы по категориям:
1. Средства оперативного сдерживания атаки {OZ}, их назначение – не позволить расп-ространиться негативному воздействию, пока не будут приняты соответствующие меры.
2. Ликвидационные меры {LZ}, т.е. те, с помощью которых можно устранить инцидент, например, переустановить ОС, запустить антивирусную программу в режиме поиска и ликвидации.
3. Меры восстановления функционирования бизнес-процесса {VZ}. Сюда относятся средства резервного копирования программных ресурсов, инсталляции прикладных и системных приложений и т.п.
4. Плановые средства защиты {PZ}, которые в контуре оперативного управления используются для перепланирования КСЗ после устранения последствий атаки.
Охарактеризуем указанные меры и средства следующими параметрами:
- время использования Тисп. При этом семантика данного параметра для каждого метода разная. Для оперативных мер – это время сдерживания атаки ТиспТсдерж; для ликвидационных – время, необходимое для устранения инцидента ТиспТликв; для восстановительных – время восстановления i-м средством j-го ресурса Тисп
; для плановых – время планирования ТиспТплан. Эти параметры являются управляющими при осуществлении оперативных мероприятий. Они определяются в ходе решения задач, описанных в главе 5.
Оперативное управление с помощью мер 1-4, которое осуществляет СУ, заключаются в решении задач, взаимосвязь которых представлена на рис.9.
Рис. 9. Функциональная структура и схема взаимодействия блоков СУ
Блок мониторинга реализован отдельной системой, в ее состав включаются сетевые и хостовые датчики событий, датчики состояния среды бизнес-процессов и контроля безопасности компонент защиты.
Блок 1. В блоке работают процедуры идентификация инцидента, алгоритмы которых описаны в главе 4. Создано три процедуры:
1. Выбор механизмов обнаружения (Мо) инцидента в зависимости от характеристик бизнес-процесса.
2. Идентификации непосредственного объекта атаки, которым всегда является какая-либо «клетка» среды.
3. Идентификация критерия безопасности, который был нарушен для объекта атаки
Блок 2. Работают алгоритмы выбора таких оперативных мер {OZ}, которые позволят сдержать развитие атаки на время Тсдерж, в течение которого СУ будет ликвидировать факт атаки, восстанавливать пораженные ресурсы и модифицировать КСЗ. Задача для выбора рационального набора мер {OZ} ={oz1 oz2,,…, ozК} описана в главе 5.
Блоки 3,5. Среда, в которой действует нарушитель в ходе атаки, представляется моделью OSE/RM, которая имеет три плоскости: плоскость <ИС>, администрирования <А>, защиты <З>. В связи с этим атаку предложено представить двумя фазами:
1-я фаза: нарушитель действует только в «клетках» плоскостей <А> и <З>; это значит, что бизнес-процесс будет обрушен далеко не сразу.
2-я фаза: нарушитель поражает «клетки» <ИС> и, стало быть, степень уверенности в обрушении бизнес-процесса велика.
Поэтому СУ здесь решает следующие задачи (их алгоритмы описаны в главе 4,5):
Задача 1. Определение фазы атаки. Если фаза 1 (развитие), то решается задачи 2 и переход к блоку 5, если фаза 2 (реализация), то переходим к блоку 4.
Задача 2. Оценка возможности перехода от фазы 1 к фазе 2.
Блок 4. На фазе реализации режим восстановления зависит от значимости поражений ресурсов и оценки реализуемости возможных целей нарушителя. Здесь реализованы две процедуры(глава 4):
1. оценки значимости нарушений критериев 
;
2. прогнозирования целей нарушителя с учетом взаимосвязи между стратегическими, тактическими целями и стратегиями их реализации (атак), а также моделирование развития атаки (стратегии нападения) по «клеткам» системы, на основании чего оценивается реализуемость целей нарушителя.
Блок 5. В зависимости от фазы атаки стратегии восстановления бизнес-процесса будут разные. Если идет фаза развития и возможность перехода к фазе реализации низкая, то мероприятия по ликвидации инцидента, восстановлению ресурсов, перепланированию системы защиты СУ может делать без остановки бизнес-процесса, в фоновом режиме. Если возможность перехода высокая, то бизнес-процесс придется останавливать, режим с остановкой. Если возможность перехода средняя – решение за ЛПР. Поэтому СУ инициирует стратегию восстановления В1(фоновый режим), останавливает бизнес-процесс (стратегия В2) или обращается к ЛПР. При этом восстановительные мероприятия проводятся так, чтобы выполнялось соотношение М(Твосст) < Тсдерж – М(Тликв), где М( ) –среднее значение соответствующего критерия.
Блок 6. Произошедшая атака говорит о том, что при проектировании КСЗ была выбрана неадекватная политика безопасности (генеральные стратегии), либо сформированы неточные требования к безопасности, либо модель угроз построена некорректно. Поэтому следует перепроектировать систему защиты в соответствии с новыми приоритетами и оценками, т.е. СПУБ должна инициировать СППР.
Блок 7. Осуществляется ранжирование поврежденных бизнес-процессов с точки зрения серьезности повреждений и СППР формирует рекомендации по очередности восстановления бизнес-процессов.
В последней части главы 2 представлен общий итерационный алгоритм функционирования СПУБ, который осуществляет управление ЖЦ системы защиты: формирование требований проектирование эксплуатация модификация КСЗ. Он заключается в следующем.
Формирование требований
Шаг 1. ЛПР должен определиться с приоритетами в политике безопасности. Для этого СППР выдает на экран концептуальную карту и ЛПР должен выбрать контур управления и вершину в контуре, т.е.для СППР задается генеральная стратегия, которую ей надо расчитать.
Шаг 2. Определение требований безопасности к КСЗ, т.е. целевого вектора критериев безо-пасности бизнес-процессов
. Для этого из БД «Бизнес-модель» СППР запрашивает данные по компонентам критериев безопасности. Здесь же происходит назначение уровня безопа-сности, СППР определяет значения критериев 
и получает целевые вектора 
по i-му бизнес-процессу, где Т*-значения критериев по соответствующим измерительным лингвистическим шкалам).
Параллельно экспертами формируется модель угроз, т.е. СППР в режиме опроса и согласования ответов вносит данные в БЗ по уязвимостям, возможностям нарушителя, атакам.
Шаг 3. Детализация целевых векторов 
по «клеткам» модели ИС. Для этого отрабатывается алгоритм формирования целей, описанный в главе 5. В результате СППР формирует дерево целей и критериев в виде матриц сопоставлений MS. Таким образом, здесь происходит сборка межкатегорийной плоскости функциональных требований к защитным механизмам.
Проектирование
Шаг 4 – концептуальное проектирование. На этом шаге СППР решает две задачи:
Задача 1. Оценивает, нужны ли, помимо встроенных, дополнительные средства. Для этого работает алгоритм главы 4, п.4.1.5.
Задача 2. Выбирает набор защитных механизмов Мх = (Мх1, Мх2,…, Мхр ) которые будут обеспечивать безопасность в соответствии с генеральной стратегией: либо 
, либо некоторый уровень 
, т.е. происходит сборка межкатегорийной плоскости защиты <З> с учетом специфики реализаций «клеток».
Шаг 5 – детальное проектирование. Этот шаг заключается в сборке проектной плоскости <З> (рис.4). Здесь выбираются программно-аппаратные СЗ, реализующие механизмы межкатегорийной плоскости, в соответствии с вектором локальных критериев 
и с учетом совмещения программных интерфейсов прикладных и платформенных компонент СЗ.
Эксплуатация и сопровождение
Шаг 6. Здесь функционируют:
- КСЗ,
- система мониторинга, которая отслеживает функциональные нарушения бизнес-процессов и анализирует инциденты безопасности,
- система управления, которая применяет меры оперативного сдерживания, ликвидирует факт атаки, восстанавливает работоспособность бизнес-процессов так, чтобы М(Твосст) + М(Тликв) Тсдерж.
Шаг 7. Модификация КСЗ, происходит в случаях, если:
А). Произошло вторжение, пропущенное КСЗ:
- вследствие того, что нарушитель оказался умнее и смог найти уязвимость, не учтенную при проектировании КСЗ;
- из-за неточности экспертных оценок компонент модели угроз (уязвимостей, возможностей нарушителя, возможных атак) или целевых векторов
.
Б). Изменились условия ведения бизнеса или требования к безопасности.
В любом случае, необходимо перепроектирование системы защиты, причем оно должно осуществляться так, чтобы М(Тпланв) Тсдерж.
Третья глава посвящена семантическому описанию факторов безопасности ИС. В главе 2 показана концептуальная карта (КК) влияния факторов информационной безопасности ИС, которая является основой для принятия решений при проектировании КСЗ. Для алгоритмической реализации КК в диссертации разработан комплекс моделей, которые служат для вычисления данных к расчету генеральных стратегий.
Для моделирования был использован формализм семантических сетей на основе онтологий, под которой понимается эксплицитная спецификация концептуализации предметной области. Структура рассматриваемой онтологии представляется кортежем О = < ОВ, 
>. Здесь ОВ – онтология верхнего уровня, которая включает понятия, относящиеся к процессу разработки системы защиты. Каждый из объектов верхнего уровня представляют собой сложные понятия, которые нетривиальным образом соотносятся с другими объектами и понятиями предметной области, поэтому для их детализации разработаны онтологии нижнего уровня 
.
Каждая из онтологий описывается формализмом О = <С, R, F, Р>. Здесь
С = {C1, …, Cn }, }, C =CTP CA CAtr CV – конечное непустое множество понятий предметных классов, где
CTP – конечное множество понятий, составляющих таксономии онтологий по отношениям партономии и родовидовым;
CAtr – конечное множество атрибутов онтологий,
CV – конечное множество значений атрибутов онтологий,
CA – конечное множество понятий, не вошедших ни в одно из множеств CTP, CAtr, CV, и вступающих в отношения ассоциации.
R = { R1, …, Rm}, Ri C x C, R = RT RP RA RАtr – конечное множество бинарных отношений, где
RT – антисимметричное, транзитивное, нерефлексивное бинарное отношение между понятиями, задающее таксономию (класс-подкласс) на множестве С и обладающее свойством наследования. Это означает, что потомкам передаются атрибуты и ассоциации всех концептов-предков, стоящих выше по иерархии, а также их отношения;
RP – транзитивное отношение партономии (часть-целое), также обладающее свойством наследования;
RA – конечное множество ассоциативных наследуемых отношений между понятиями С, которые отражают специфику данных предметных классов;
RАtr – конечное множество атрибутов, описывающих свойства понятий С и отношений R;
RV – конечное множество значений атрибутов СAtr.
F – конечное множество описательных интерпретаций понятий.
Р – конечное множество аксиом и правил, определяющих семантику понятий и отношений, которые представляются в виде продукций if < посылка> then <действие>.
Указанные отношения обладают следующими свойствами RT RP =, RT RA =, RT RАtr =, RT RV =, RР RV =, RР RА =, RР RАtr =, RA RАtr =,
RA RV =, RАtr RV =, т.е. отсутствует пересечение множеств Ri.
Взаимосвязь понятий и отношений онтологий описывается следующим образом
RT CTP x CTP, RP CTP x CTP, RA CTP x CTP, RV CAtr x CV, RAtr CTP x CAtr
Были выделены следующие классы понятий, относящиеся к процессу проектирования системы защиты:
- {Бизнес-модель} - множество автоматизированных бизнес-процессов, подлежащих защите.
- Критерии безопасности
, описывают качество безопасности, которым должна обладать информационная система. Их перечень и значения определяются исходя из интересов бизнеса и возможных угроз безопасности. - {Модель угроз}, т.е. совокупность условий и факторов, которые могут привести к возможному нарушению уровня безопасности бизнес-процессов, задаваемого критериями
. - Комплексная система защиты {КСЗ}, представляет собой комплекс защитных средств.
- {Средства и меры защиты}, т.е. некоторые меры процедурного характера, а также программно-аппаратные продукты, реализующие защитные механизмы.
- Защитный механизм {Мх}, обеспечивает какое-либо свойство безопасности в соответствии с определенным уровнем критериев
. - {Риски}, которые несет предприятие в случае, если будет нарушена безопасность его бизнес-процессов вследствие реализации угроз.
На верхний уровень онтологии вынесены следующие концепты СВ={Бизнес-модель, Модель угроз, Риски, КСЗ, KS}, между которыми введены горизонтальные ассоциативные отношения RA = {«Определяет уровень», «Обеспечивает», «Противостоит», «Определяет ущерб», «Определяет возможность наступления»}, {Соотносится}. Указанные концепты представляют собой иерархии вида «целое-часть» и «класс-подкласс», что подчеркивается транзитивным отношением «Включает» и «Это есть».
Глава содержит детальное описание онтологических классов ОВ, 
.
Концепт {Бизнес-модель} в соответствии с моделью {BМ}, идеология построения которой описана в 1-й главе, включает: а) объект {Среда}, который интерпретируется как среда функционирования бизнес-процесса, т.е., на основании модели OSE/RM, платформенная и прикладная составляющие. С точки зрения информационной безопасности среда определяет компоненты модели угроз: уязвимости, объекты и каналы атак. б). концепт {Бизнес-логика}, ассоциированный с видами деятельности и их взаимосвязью. Концепт представляет ограничения Ab/p, накладываемые на защиту в интересах эффективного исполнения бизнес-процессов, ущерб, наносимый бизнес-процессу вследствие произошедшего компьютерного вторжения и цели безопасности (требования).
Отношением {Определяет уровень} {Бизнес-модель} связана с концептом критериев безопасности {KS}, измеряющих цели. Критерии 
задаются как термы лингвистических переменных. Уровни критериев (значение терма) определяются на основании семантики бизнес-процесса, его значимости с точки зрения бизнеса, предпочтений ЛПР (только ЛПР может сказать, что для него важнее, обеспечить, например, конфиден-циальность данных, «лежащих» на сервере или доступность к нему), а также оценок возможных угроз. Процедура формирования целей и назначения значений оценочных критериев описана в главе 5. Концепт включает иерархию целей (требований безопасности) на верхнем уровне – относительно бизнес-процессов, на следующих уровнях – декомпозицию их по клеткам модели OSE/RM в соответствии с глубиной референсности.
Современная теория управления предприятием обладает разными методами оценки материального и нематериального ущерба от нарушения функционирования бизнес-процессов, поэтому концепт {Риски}, как функция от величины ущерба также связан с бизнес-моделью (отношение {Определяет ущерб}). Концепт представляет классификацию рисков информационной системы.
Следует заметить, что концепт {KS} имеет отношение с объектом {Риски}. Эта связь дает возможность реализовать идею управления рисками информационной безопасности. Семантика связи заключается в том, чтобы после выбора варианта системы защиты, обеспечивающей требуемый уровень 
, произвести оценку будущего риска при данном наборе защитных средств и сделать вывод о его приемлемости. Если риск неприемлем, берется другой набор средств защиты и производится сближение оценок и по рискам, и по уровню безопасности.
Реализация угроз возможна лишь в том случае, если информационная система имеет соответствующие уязвимости в технических и программных средствах, позволяющие реализовать ту или иную угрозу, и найдется нарушитель, который использует уязвимость. Тогда угроза переходит в категорию атаки. Таким образом, уязвимость определяет возможность реализации атаки, а нарушитель – возможность возникновения атаки.
Таким образом, модель угроз включает:
- класс уязвимостей, который содержит представление понятий, связанных с уязвимостями среды бизнес-процесса,
- класс нарушителя, включающий объекты, характеризующие возможности потенциального нарушителя,
- класс атак, представляющий экземпляры потенциально-опасных атак.
Класс {Модель угроз} содержит иерархию концептов {Уязвимости среды б-п}, {Нарушитель}, {Потенциально-опасные атаки}, которые, в свою очередь, также представляются онтологиями. Взаимосвязь указанных понятий представлена онтологией на рис.11.
В диссертации разработаны также онтологии модели угроз уровня 
=({Уязвимость среды б/п}, {Нарушитель}, {Потенциально-опасные атаки}).
Комплексная система защиты (рис.12) – концепт {КСЗ} – представляет собой набор программно-технических средств защиты, функционирование которых обеспечивает заданный уровень безопасности бизнес-процессов 
(отношение верхнего уровня {Обеспечивает}). С другой стороны, система защиты служит для нейтрализации угроз посредством отношения верхнего уровня {Противостоит}.
Защитные свойства того или иного средства реализуются комплексом механизмов (Мх), таким образом, класс {КСЗ} описывается иерархией указанных концептов, каждый из которых имеет собственное представление.
Разработанный и предложенный в третьей главе комплекс структурных моделей указанных понятий, их полнота:
- представляют модельную основу для разработки алгоритмов логического вывода данных для расчета параметров концептуальной карты при проектировании КСЗ, которое осуществляет СППР, а также процедур анализа стадии сопровождения;
- обеспечивают целостное и комплексное представление предметной области, имеющее самостоятельное значение, которое может быть использовано при разработке информационно-поисковых и экспертных системы в области ИБ.
В четвертой главе излагаются алгоритмы и процедуры анализа, которые используются на всех стадиях ЖЦ системы защиты. Изложенные в этой главе алгоритмы составляют программное обеспечение системы мониторинга СПУБ.
В результате этапа консалтинга СППР оценивает ценность для бизнеса ресурсов (данных и приложений), включаемых в состав бизнес-процесса и назначает каждому Si-му бизнес-процессу параметр приоритета Pr(Si.), который измеряется лингвистической или балльной шкалой: «высокий-4», «средний-3», «низкий-2», «очень низкий-1», «отсутствует-0». При этом, ценность информационных ресурсов и ущерб от компрометации этих ресурсов – это две стороны одной медали. Например, если клиентская БД страховой компании попала в руки к конкурентам, компания понесет ущерб в объеме недополученных страховых сборов. Поэтому оценка ценности ресурсов одновременно влечет и оценку ущерба от компрометации этих ресурсов (на основании приоритетов Pr(Si.) формируются требования к КСЗ, т.е. вектор 
по алгоритму главы 5).
Информационные ресурсы в виде различных по семантике БД, хранилищ, отдельных файлов привязаны как внешние сущности к бизнес-процессам и, стало быть, включаются в состав соответствующих «клеток» плоскости <ИС> OSE/RM.
Алгоритм оценки ценности/ущерба состоит в следующем.
- СППР предъявляет экспертам список оценочных критериев, которые хранятся в БД:
К1. Нормативные акты, которые регламентируют актив (этот критерий имеет свою лингвистическую шкалу, но она волне согласуется с общей: «закон РФ-4», «ГОСТ-3», «РД-2», «внутренние документы-1» «отсутствует-0»).
К2. Конкурентные преимущества.
К3. Объем недополученного дохода.
К4. Степень личной ответственности ЛПР.
К5. Степень юридической ответственности.
К6. Стоимость восстановления кодов.
К7. Стоимость восстановления аппаратных средств.
К8. Потери от компрометации брэнда.
К9. Стоимость восстановления данных и т.д.
- Согласование или модификация экспертами списка критериев К1-К9. Здесь используются известные методы согласования, система мониторинга предоставляет возможность их выбора.
- Определение и согласование веса критерия
как нормированной суммы рангов. Для этого система предлагает заполнить каждому эксперту таблицу рангов (значимости), которая отражает ранг s-го критерия для р-ой «клетки» (табл.1), на основании которой определяется 
, где rjs – ранг s-го критерия, определенный j-м экспертом для р-ой «клетки», ns – число экспертов, давших данную оценку критерию.
Таблица 1.
| Идентификатор «клетки» бизнес-процесса Si, содержащей ресурс | Важность критерия | ||
| Нормативные акты | Конкурентные преимущества | Объем недопо-лученного дохода | |
| К1 | Высокая-3 | Низкая -1 | Средняя -2 |
| …. | … | … | … |
| КР | Низкая -1 | Средняя -2 | Очень высокая -4 |
- Определение и согласование экспертами по р-м «клеткам» Si-го бизнес-процесса значений xps – оценок ресурсов «клетки» по каждому из критериев К1-К9 и Pr(Kp)=
– совокупной оценки р-ой «клетки». Для этого система мониторинга предлагает заполнить таблицу, аналогичную табл.1, но по всем критериям К1-К9. - Определение совокупной оценки приоритета всего бизнес-процесса Pr(Si)=
. Здесь Pr(Kp)= 
- приоритет ресурсов р-ой «клетки» по s-ому критерию, где арs – вес критерия, xрs – значения критерия.
На стадии проектирования требуется определить, необходимо ли к встроенным в программные продукты ИС, дополнительные наложенные средства защиты. Для ответа на этот вопрос в диссертации разработана алгоритмическая процедура, которая состоит из трех блоков:
Блок1. Оценка осуществимости угрозы Y(Si), i=1I, в среде реализации бизнес-процесса (в платформенной компоненте ИС). Угрозы характеризуются наличием нарушителя, обладающего определенным потенциалом NP, чтобы воспользоваться уязвимостями среды
.
Перечень уязвимостей 
, свойственных «клеткам» бизнес-процесса, выявляется экспертами предварительно и хранится в БЗ онтологического класса {Уязвимость среды б/п}. Для характеристик возможностей нарушителя и определения его потенциала NP разработан онтологический класс {Нарушитель}, где на основе продукционных правил определяются оценки NPn предполагаемых нарушителей.
Алгоритм блока 1.
- Вычисление оценки
, ее рейтинга 
с точки зрения идентификации уязвимости нарушителем, а затем ее использования. Эти действия характеризуются следующими критериями: - временем, которое необходимо для совершения этих действий,
- необходимой квалификацией нарушителя,
- уровнем знаний о среде,
- характером и продолжительностью доступа к среде,
- необходимыми аппаратно-программными ресурсами.
Для каждого критерия в системе мониторинга имеются согласованные экспертами оценочные балльные шкалы (в табл. 2 приведен пример шкалы по критерию а).
Таблица 2
| Время | Идентификация уязвимости | Использование уязвимости |
| < 0,5 часа | 0 | 0 |
| < суток | 2 | 3 |
| < месяца | 3 | 5 |
| > месяца | 5 | 8 |
- Для
система мониторинга получает рейтинг 
уязвимости, принадлежащих р-й «клетке» как аддитивную функцию, т.е. выбранные значения по обоим действиям по всем таблицам суммируются. Если уязвимость можно идентифицировать\использовать несколькими способами, для каждого из них вычисляется рейтинг и из полученных значений выбирается минимальное, т.е. уязвимости ставится в соответствие самый простой метод успешного нападения. - По этому же правилу по всем
«клетки» вычисляется общий рейтинг Rклетки, т.е. 
и оценивается системой мониторинга по шкале табл.3.
Таблица 3
| Диапазон Rклетки | Рейтинг уязвимости |
| < 10 | Низкий-1 |
| 10 – 17 | Умеренный-2 |
| 18 – 24 | Высокий -3 |
| > 24 | Нереально высокий -4 |
- На основании потенциалов каждого предполагаемого нарушителя NPn, которые выбираются по запросу из БЗ {Модель нарушителя} вычисляется совокупный потенциал нарушителя
по правилу: из нескольких сценариев нападения выбирается худший вариант, с наибольшим потенциалом. - Условие успешного нападения заключается в том, что существует NP=
такой, что Rклетки < NP, где j – типы нарушителя. Такие сравнения система мониторинга проводит по каждой «клетке». В результате получает распределение оценок осуществимости угрозы по p-ым «клеткам» среды Yp, p=1,…,P.
Блок 2. Оценка стойкости механизмов защиты Мх, встроенных в платформу ИС.
1. Система мониторинга в интерактивном режиме опрашивает экспертов, сопоставляет каждой «клетке» реализованные в ней механизмы и просит заполнить столбцы 2 k таблицы 4 по шкале«Стойкость»: «базовая-1», «средняя-2», «высокая-3», после чего согласовывает их ответы и заполняет закрашенные ячейки таблицы окончательно.
Таблица 4
| Идентификатор «клетки» бизнес-процесса Si, содержащей Мх | Стойкость механизмов хр | S(Mxp) | ||
| Мх1 | ... | МхК | ||
| 1 | 2 | ... | k | k +1 |
| К1 | Высокая -3 | ... | Базовая -1 | умеренная |
| ... | ... | ... | ... | ... |
| КР | Средняя -2 | Механизм отсутствует | средняя | |
Средняя стойкость  | Средняя-2 | Базовая -1 |  | |
Здесь хр – стойкость k-го защитного механизма.
2. Вычисляет величину средней стойкости k-го механизма 
.
3. Просит заполнить оценки совокупной стойкости механизмов, соответствующих р-ой «клетке» S(Mxp). Они представляет собой суждения экспертов о величине синергетического защитного эффекта от влияния механизмов друг на друга. Например, туннелирование по протоколу IPv6 над стандартным TCP/IP дает достаточно низкую безопасность по конфиденциальности при передаче данных, но вкупе с механизмом шифрования уровень конфиденциальности резко повышается, а, если на концах канала передачи установить межсетевой экран, получим одно из самых надежных средств защиты – виртуальную частную сеть VPN. Ее оценки проставляются экспертами по шкале «Совокупная стойкость»: «низкая-1», «умеренная-2», «высокая-3», «очень высокая-4». В результате система имеет распределение оценок стойкости защитных механизмов по «клеткам».
4. Вычисляет величину средней совокупной стойкости механизмов бизнес-процесса как среднее по столбцу (k+1) 
.
Блок 3. Оценка защищенности встроенными средствами, оценки осуществимости угроз в «клетках» среды.
- В результате алгоритма блока 2 система получает распределение стойкости механизмов по «клеткам». С учетом распределений оценок осуществимости угроз Yp каждая «клетка» среды может оказаться в одном из четырех состояний, рис. 13, где Y+ означает, что угроза для «клетки» существует, Yо – угрозы нет, S+ - механизмы в «клетке» есть, Sо – механизмов нет.
Рис.13. Состояния «клетки» среды по угрозам и стойкости механизмов
- Состояние (Yо,S+) из дальнейшего рассмотрения выбрасываются, остальные требуют уточнений. При этом система мониторинга рассматривает девять ситуаций, представленных на рис.14. Эти оценки угроз Yp система мониторинга выдает на экран и эксперты принимают окончательное решение о необходимости привлекать дополнительные защитные средства.
- В дополнение к полученным оценкам, система мониторинга осуществляет оценку рисков, которые ожидают компанию, если угроза реализуется с уверенностью Yp. На основании оценок ущерба/ и угроз подсистема мониторинга реализует алгоритм расчета оценки риска среды для р-х «клеток»
Riskp=Pr(Kp)*Yp, (2)
где Pr(Kp) – оценка ущерба, Yp – оценка угрозы, p=1,…,P.
Вычисленное значение Riskp отображается на шкалу «Риск клетки», которая формируется из следующих соображений. Произведение оценок Pr на Y может дать 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.
Рис.14. Возможные ситуации при реализации угроз и их оценки
Совокупный по бизнес-процессу риск Risk система мониторинга предлагает ЛПР двумя способами (хотя могут быть заложены и другие алгоритмы): как среднее значение по «клеткам» 
или как мультипли-кативная функция 
с учетом важности риска для «клетки». Процедура назначения и согласования весов «клеток» ар с точки зрения риска осуществляется по алгоритмам, описанным ранее.
4. Пусть Riski* - некоторый порог риска по i-му бизнес-процессу, приемлемого для компании с точки зрения ЛПР. Тогда, если Risk Riski*, то к защитным встроенным средствам необходимы дополнительные.
Вторая часть 4-й главы посвящена алгоритмам стадии эксплуатации. Здесь мониторинг осуществляется с целью сбора и анализа данных по алгоритму рис. 15:
Блок1. Пусть
- вектор эталонных функциональных характеристик бизнес-процесса. Они выявляются на основе связи с техническими характеристиками загрузки среды вектора 
. Значения 
снимаются на этапе внедрения и вводятся в БД. Параметры 
известны и отслеживаются программами администрирования ИС. В диссертации предложено их структурировать в соответствии с плоскостью модели OSE/RM. Перечень характеристик приведен в Приложении. Система мониторинга (СМ) производит оценку отклонений параметров вектора 
от эталонных. Для этого по каждому 
вводятся однородные шкалы оценки степени критичности (Кр(Si)) нарушения по шкале: «Степень критичности»: «критическое-3» «среднее-2», «слабое-1», «норма-0». Пример такой шкалы приведен в табл. 5. Подобные шкалы должны быть сформированы и согласованы экспертами на этапе предпроектного проектирования по каждому параметру 
, подлежащему мониторингу и оценке.
Если нарушение среднее, система выводит предупредительное сообщение администратору и продолжает наблюдение. Если нарушение критическое – система производит дальнейший анализ.
Таблица 5.
| Терм | Критическое | Среднее | Слабое | Норма |
| Диапазон | 0 – 100 | 100 – 500 | 500 – 700 | 700 – 1000 |
Блок 2. Здесь выявляются аномалии, связанные с нарушением критериев
, т.е. выявляются инциденты безопасности, пропущенные КСЗ. Подчеркивается, что аномалии можно классифицировать на сетевые и локальные в зависимости от принадлежности к той или иной «клетке» ОSE/RМ. Приведен обзор механизмов обнаружения сетевых и локальных аномалий, их структуризация по «клеткам» модели. Решена задача выбора механизма обнаружения (Мо) аномалий в зависимости от характеристик бизнес-процесса (типу бизнес-процесса TSi, его приоритета Pr, критичности нарушений Kp), для этого:
- Сформулированы (и детализированы) критерии оценки механизмов по:
- функциональной пригодности,
- функциональной приемлемости (правильности) (Prieml),
- эффективности использования (Eff),
- нагрузки на пользователя
- Разработан 2-х этапный алгоритм выбора механизма.
1 этап. Вначале выбираются Мо по критериям функциональной приемлемости и эффективности, т.е. выбор осуществляется исходя из интересов выполнения бизнес-процесса. Эти критерии определяют ограничения на выбор Мо, которые приемлемы по количеству пропущенных (O1P), ложных (O2P) срабатываний, надежности детектирования (Nd), нагрузке на систему (Ngr) и временным затратам (Time). Таким образом, решающие правила представляет собой продукции вида
if Kp=<значение> & Pr=<значение > & TSi = <значение >
then Eff {[ Ngr=< значение/диапазон >] &
[Time=< значение/диапазон >}] &
Prieml {[Nd=< значение/диапазон >] & (*)
[O1P=< значение/диапазон >] &
[O2P=< значение/диапазон > ]}.
Например, если система мониторинга для Si-го основного бизнес-процесса (ТSi), обладающего высокой ценностью для предприятия (Pr), зафиксировала критические функциональные нарушения (Kp), ясно, что должны быть использованы Мо аномалий с оптимальными характеристиками по эффективности и приемлемости:
If Kp=’Критическая’ & Pr=’высокий’ & TSi=’основной_процесс’
then Eff { Ngr= min & Time=min} &
Prieml { Nd=max & O1P=min & O2P=min}.
Если же требования по Kp, Pr, и ТSi не столь критичны, можно задействовать и Мо с более слабыми характеристиками, задаваемыми диапазоном значений.
Множество таких продукций составляет продукционную систему, которая представляется тройкой вида: 
, где F – рабочая память (РП), содержащая текущие данные; P – база знаний (БЗ), содержащая множество продукций, т.е. правил вывода вида (*). Система, перебирая множество правил типа (*), формирует набор из k механизмов обнаружения {Mo1, Mo2,…, Mok}, функционально приемлемых для каждой «клетки» OSE/RM, включенной в информационные операции IOl по Si-му бизнес-процессу.
2 этап. На втором этапе из набора {Mo1, Mo2,…, Mok} экспертами выбираются те Мо, которые окажутся приемлемыми по функциональной пригодности.
Блок 3. Анализ обнаруженных аномалий (инцидента безопасности) с целью принятия решения о режиме восстановления работоспособности бизнес-процесса. Режим может быть фоновый – без остановки (стратегия В1), либо с остановкой (стратегия В2). Это зависит от характера нарушений. Общий алгоритм анализа и принятия решений при различных последствиях представлен на рис.20 и заключается в следующем.
А). Выявлении фазы атаки и определении вероятности перехода из одной фазы в другую. Предполагается, что атака имеет две фазы: фазу развития, когда атакой поражаются «клетки» плоскостей <А> и <З>, т.е. нарушаются характеристики 
,
, и фазу реалии-зации, и тогда ущерб наносится непосредственно функциям бизнес-процесса, т.е. характеристики
принимают аномальные значения. Важность задачи выявления фазы определяется тем, что от фазы зависит выбор стратегии восстановления бизнес-процесс: либо стратегия блока В1, либо стратегия блока В2 (рис.16).
Для решения указанных задач разработано две процедуры.
Процедура определения фазы атаки
Обозначим (р1, р2, …, рL) – вектор аномальных параметров, зафиксированных СМ. Каждый из них относится к перечню характеристик 
, l=1,2,…,L. Этот перечень, структурированный по плоскостям и «клеткам» модели OSE/RM, приведен в Приложении № 3.
- Если СМ обнаружила, что значения всех параметров рi, отнесенных к «клеткам» плоскости <ИС>
, выходят за пределы штатных, то осуществляется фаза реализации. - Если все аномальные параметры
, то осуществляется фаза развития. - Если значения некоторых параметров рi, отнесенных к «клеткам» плоскости <ИС>
, выходят за пределы штатных, то осуществляется фаза реализации. - Если некоторые аномальные параметры рi относятся к «клеткам» столбца С, то для определения фазы следует искать подтверждение на локальном компоненте. Это значит, что
- если
и 
, 
, то осуществляется фаза реализации; - если
и 
, 
, то фаза развития; - если
, и ни один рj не принадлежит «клеткам» локального компонента, т.е. 
, 
, то происходит фаза развития;
Процедура определения возможности перехода к фазе реализации
Алгоритм второй процедуры основан на модельном прогнозе целей нарушителя и оценке возможности их реализации.
Множество целей нарушителя {C} подразделяется на стратегические цели {StG}, когда объектом атаки являются «клетки» плоскости <ИС>, и тактические {TkG}, т.е. нарушитель действует на плоскостях <А> и <З>. Для достижения цели StGj необходимо реализовать набор тактических целей 
, поэтому чтобы понять, каковы намерения нарушителя в будущем – его стратегическая цель, необходимо понять, какую цель он осуществляет в данный момент.
Алгоритм процедуры следующий.
1. Каждой тактической цели поставлен в соответствие набор признаков 
, т.е реакций ОС, которые фиксируются системой мониторинга. Например, если TkGi – выявление пароля пользователя, то набор признаков 
может быть следующим: отключение механизма аутентификации, обращение к файлу паролей, блокировка IP-адреса, с которого осуществлялось воздействие, количество попыток подбора пароля и.т.п. Идентификация TkGi происходит по признакам 
по следующему правилу:
- если система мониторинга зафиксировала 0-30% нарушенных признаков от их общего числа, будем считать, что данная TkGi осуществляется слабо,
- если 31-70% признаков – осуществляемость средняя,
- диапазон нарушений в 71-100% говорит о высокой степени осуществляемости.
Разумеется, границы диапазонов могут быть пересмотрены и согласованы экспертами. Дальше оценка осуществимости целей рассмотрена на примере.
Пусть системой мониторинга получены оценки тактических целей, приведенные в табл. 6 (столбцы 4, 5, 6).
Таблица.6.
| Стратегическая цель | Тактическая цель | Значим-ость аi | Оценка сi | ||
| Слабо | Средняя | Высокая | |||
| 1 | 2 | 3 | 4 | 5 | 6 |
| StG1 - Деструктивный вред <З> | Получить доступ к файлу паролей | 0,7 | 1 | ||
| Получить учетную запись | 0,6 | 1 | |||
| StG2 - Деструктивный вред <А> | Получить список открытых портов, незащищенных модемов | 0,4 | 2 | ||
| Получить карту сети | 0,7 | 2 | |||
| Получить сведения об ОС, ПО | 0,7 | 3 | |||
2. Далее СМ предлагает экспертам список критериев для оценки значимости цели, который сформирован предварительно и хранится в БД:
- предположение о важности реализуемой тактической цели для нарушителя,
- уверенность экспертов в стойкости механизмов защиты, которые противостоят нарушителю,
- предположение экспертов о возможностях нарушителя, которые помогут ему реализовать данную цель до конца,
- оценка опасности, которую повлечет данная реализованная цель функционированию бизнес-процесса,
- оценка опасности, которую повлечет данная реализованная цель для защиты ИС в целом.
Пусть был выбран 1-й критерий «Важность реализуемой цели для нарушителя».
2.2. Каждую тактическую цель эксперты оценивают с точки зрения выбранного крите-рия. Пусть эта оценка выражается весовыми коэффициентами аi, 
(столбец 3 табл. 6).
3. Тогда предполагаемую реализуемость стратегических целей Р(StG1), Р(StG2)с точки зрения важности для нарушителя тактических целей можно вычислить как 
, 
.
Таким образом, СМ делает вывод: поскольку цель «Получить доступ к файлу паролей» оценена как «слабая», хотя и с высокой значимостью, то стратегическую цель «Нанесение деструктивного вреда плоскости <З>» нарушитель вряд ли ставил перед собой (степень уверенности Р(StG1)=1.4). Также, поскольку в данном примере не реализовывались тактические цели, связанные с плоскостью <ИС>, то вряд ли злоумышленник хочет нанести прямой вред бизнес-процессу, т.е. фазы реализации атаки не произойдет. А вот реализация цели StG2 («Нанесение деструктивного вреда объектам плоскости <А> (системе администрирования ИС)») произойдет с уверенностью 4.3.
Таким образом, восстанавливать ИС после действий нарушителя можно без остановки бизнес-процесса в фоновом режиме (стратегия В1).
Б). Анализе и определения того критерия из множества
, нарушение которого привело к проблемам функционирования бизнес-процесса. Здесь разработаны:
1). процедура идентификации нарушенного критерия, которая производит анализ принадлежности параметров (р1, р2, …, рL) к множествам 
, 
, 
, описывающим принадлежность к критериям безопасности
.
2). процедура оценки нарушений, которая также проводится с целью выявления режима восстановления бизнес-процессов: с остановкой (стратегия В2) или фоновый (стратегия В1). Она основана на том, что: а). по критерию С: на основании критериальных оценок, например, объема поврежденных данных, времени, в течении которого приложение будет работать в ненарушенном виде и т.п. СМ сама принимает решение о режиме восстановления; б). по критерию D: на основе таблицы, приведенной в диссертации в п.4.2.3.3; по критерию K: на основании решения ЛПР.
3). процедура ранжирования бизнес-процессов Si. Цель ранжировки – оценить значимость повреждений с разных точек зрения и тем самым установить порядок восстановления бизнес-процессов. В табл.7 приведен пример оценки по различным критериям, а табл.8 демонстрирует переход к семантически единой шкале, на основании которой вычисляются ранги.
Таблица 7.
| Наименование Si-го бизнес-процесса | Сколько критериев  нарушено | Совокупная значимость критерия  | Приоритет бизнес-процесса | Тип бизнес-процесса |
| S1 | Один | Средняя | Высокий | Обеспечивающий |
| S2 | Все | Средняя | Низкий | Вспомогательный |
| ... | … | … | … | … |
| SN | Два | Высокая | Средний | Основной |
Таблица 8.
| Наименование Si-го бизнес-процесса | Сколько критериев безопасности нарушено | Совокупная значимость критерия  | Приоритет бизнес-процесса | Тип бизнес-процесса | Оценка | Ранг |
| S1 | Удовл.-1 | Плохо-2 | Очень плохо-3 | Плохо-2. | 8 | 2 |
| S2 | Очень плохо-3 | Плохо-2 | Удовл.-1 | Удовл.-1. | 7 | 3 |
| ... | … | … | … | … | ||
| SN | Плохо-2 | Очень плохо-3 | Плохо-2 | Очень плохо-3 | 10 | 1 |
В). В процедуре оценки нарушений был выявлен режим восстановления по каждому бизнес-процессу(S1,…,SN), поэтому СМ в качестве рекомендованного плана действий выдает на экран для модификации, согласования или утверждения, например, следующую табл.9.
Таблица 9.
| Наименование Si-го бизнес-процесса | Ранг | Режим восстановления |
| SN | 1 | Фоновый |
| S1 | 2 | Остановка |
| ... | ... | ... |
| S2 | 3 | Фоновый |
В пятой главе описаны задачи, процедуры и алгоритмы формирования целей, стратегий защиты и нападения. Эти алгоритмы работают на всех стадиях и этапах ЖЦ КСЗ.
Для этапа консалтинга в СППР задействован алгоритм выбора генеральной стратегии. Они отражают приоритеты ЛПР в области безопасности ИС и определяют критерии цикла проектирования, их алгоритмы описаны в главе 2. Алгоритм выбора стратегий реализован в трех вариантах:
- автоматически, на основе оценок риска, производимых системой мониторинга;
- на основе выбора вершин концептуальной карты, которая выводится на экран;
- в автоматизированном режиме на основе опроса и согласования мнений экспертов в соответствии со списком критериев, который представлен в 5-й главе.
При реализации любой из стратегий выбор защитных механизмов (Мх1, Мх2,…,МхК) СППР осуществляет в соответствии с целевым вектором безопасности 
, алгоритм формирования которого представлен на рис. 17. Алгоритм построен на сочетании опросов экспертов и оценок, полученных в системе мониторинга. В результате СППР сформирует списки целей безопасности для бизнес-процессов и для «клеток» среды ИС, которыми реализуются информационные опе-рации бизнес-процессов (см. про-цессную модель защиты, глава 1).
Далее СППР реализует процедуру определения целевых значений векторов 
. Ее алгоритм построен на основе эвристик, которые могут быть модифицированы, дополнены или заменены прямым вводом экспертных оценок. В тексте диссертации этот алгоритм показан на примере. Он работает и для бизнес-процессов, и для «клеток» информационных операций и состоит из следующих шагов:
Шаг1. Определение базового уровня критериев в соответствии с оценками ценности Pr(Si) бизнес-процесса и ценности ресурсов, сопоставленных «клеткам» Pr(Кр), полученных в системой мониторинга (алгоритм главы 4).
Шаг 2. Определение предпочитаемого уровня. Базовые значения критериев подправляются за счет субъективной значимости критериев для эксперта.
Шаг 3. Определение ожидаемого уровня. Здесь предпочитаемые значения подправляются оценками угроз среды Yp, полученными в системой мониторинга. Задейст-вованы следующие эвристики:
- Поднять предпочитаемые уровни на величину оценки угрозы (тогда сознательно допускаем некоторую «дырку» в защите, если полученная сумма окажется меньше максимально возможного значения критерия),
3. Поднять оценки К, С, D до максимального уровня.
- Если оценка опасности нулевая, то уровень защиты для этого бизнес-процесса по данному критерию снизить также до 0.
Если Si-ый бизнес-процесс обменивается данными с Sj, то целевые значения должны быть выровнены: если входящий в Sj -ый бизнес-процесс информационный поток имеет больший уровень по некоторому критерию, то значение Sj–го бизнес-процесса по этому критерию надо увеличить. Таким образом, СППР получает набор целевых векторов для Si-ых бизнес-процессов 
. Если описанный алгоритм отработает в детализиро-ванном режиме, то СППР будет иметь наборы векторов безопасности по «клеткам» 
.
Вторая часть 5-й главы посвящена описанию задач рационального выбора стратегий защиты или вариантов КСЗ. Согласно онтологическому классу {КСЗ}, описанному в главе 3, формирование вариантов идет в два этапа:
А). В рамках одной из генеральных стратегий, в соответствии межкатегорийной плоскостью функциональных требований 
, l=K/C/D, выбираются механизмы защиты Мх, удовлетворяющие критериям безопасности 
. Здесь, для выбора (Мх1, Мх2,…,Мхк) целесообразно использовать метод идеальной точки, в качестве которой выступает вектор 
, а онтология БЗ по Мх включает атрибут {Уровень критерия}. Это означает, что каждый экземпляр механизма Мх, представленного в БЗ, предварительно оценен по соответствующему критерию K, C, D. Тогда вектор оценок набора Мх ранжируется на основе евклидовой метрики 
по отношению к идеальной точке 
. Ранжированные наборы (Мх1, Мх2,…,Мхк) предъявляются экспертам, которые выбирают один или несколько вариантов.
Б). На втором этапе под выбранные наборы механизмов (Мх1, Мх2,…,Мхк) подбираются реализующие их средства защиты. Назовем такие СЗ плановыми и обозначим 
, l = K/C/D. Выбор здесь идет по критериям 
, т.е. 
i=1,…,n, l = K/C/D ставится в соответствие следующие оценочные критерии (назовем их локальными):
- Влияние функциональных издержек на работу бизнес-процесса
, которое задается лингвистической переменной «Функциональные издержки» и определяется для каждого 
такими параметрами как: оценка изменения производительности аппаратных средств бизнес-процесса, оценка изменения уровня загрузки серверов бизнес-роцесса, оценка изменения объема трафика бизнес-процесса, оценка изменения скорости транзакций к БД бизнес-процесса и т.д. - Оценка стоимости (StZ),
- Возможность модификации соответствующих
при изменении требований к защищаемой системе (Mod), - Оценка эксплуатационных характеристик средства,
.
Оценки 
по этим критериям также отражены в онтологии БЗ по средствам защиты. Но решение здесь заключается в формировании Парето-оптимального множества недоминируемых альтернатив, которые также предъявляются экспертам и ЛПР для окончательного выбора.
Для контроля описанный алгоритм может быть реализован в двух режимах: в виде прямой и обратной задачи:
Прямая задача:
Какой уровень безопасности бизнес-процесса можно обеспечить, если средства защиты обладают заданным качеством 
и будет ли этот уровень достаточен, чтобы защита соответствовала приоритету бизнес-процесса Pr при угрозах Y и уязвимостях 
(символ «*» означает выбранное значение).
Обратная задача:
Какими средствами защиты pzi*, отвечающими необходимым технологическим, финансовым и прочим ограничениям, можно обеспечить определяемый приоритетом Pr уровень безопасности KS бизнес-процесса, описываемый требованиями безопасности с учетом уязвимостей и угроз, существующих в среде функционирования?
В третьей части главы представлены алгоритмы для проведения сценарного анализа вариантов КСЗ (Мх1, Мх2,…,МхК), выбранных в соответствии с целями 
, на потенциальных атаках в соответствии со схемой рис.2. Сценарный анализ заключается в осуществлении следующих шагов.
Шаг1. Формирование списков предполагаемых целей нарушителя и реализующих их стратегий нападения, т.е. атак.
Цели, которые ставит перед собой нарушитель, планируя атаку на ИС, могут быть различны. Это может быть, например:
- обрушение какого-либо вида деятельности предприятия (например, электронного магазина); это значит, что бизнес-процессы (и соответствующие приложения ИС), моделирующие эту деятельность – в зоне риска;
- кража или модификация каких-либо данных;
- обрушение ОС или ее подсистем;
- взлом механизмов системы защиты;
- использование сервера для организации DDOS-атак («зомби», Smarf-усилитель);
- желание продемонстрировать свое умение, амбиции и т.п.
Анализ списка говорит о том, что цели нарушителя с точки зрения нанесения вреда бизнес-процессу далеко не равнозначны. Исследования, проведенные в диссертации, позволили классифицировать цели нарушителя на стратегические StGi, i=1,…,I,, тактические TkGs, s=1,…,S и стратегии нападения {
}, а также установить взаимосвязи между ними. Например, чтобы постоянно подправлять данные в БД клиентов банка (бизнес-процесс: расчетно-кассовое обслуживание физических лиц) (StG1), нарушитель должен получить доступ в сеть банка (TkG1) и скрыть свое присутствие там (TkG2). Стратегии реализации тактических целей могут быть самые разные. Таблица взаимосвязей целей и стратегий представлена в тексте главы 5. Таким образом, цели StGi всегда предполагают нанесение прямого вреда функционированию бизнес-процессов (приложению ИС), они направлены на нарушение критериев 
в «клетках» плоскости <ИС> модели OSE/RM, в то время как реализация тактических целей TkGs, нарушает критерии в «клетках» <А>, <З>, поэтому влияет на безопасность бизнес-процесса опосредованно.
Поэтому разработанный алгоритм формирования списка атак, основан на учете взаимосвязи целей и стратегий нападения и специфики представления плоскостей <ИС>, <А>, <З>. Его концептуальная схема приведена на рис. 18. Алгоритм заключается в следующем:
1. СППР выводит на экран дерево стратегических целей нарушителя, чтобы эксперты выбрали те цели, которые им кажутся актуальными и проставляют оценки актуальности по 4-х балльной шкале: «неактуальна»-1, «малоактуальна»-2, «актуальна»-3, «весьма актуальна»-4.
2. СППР проводит процедуру согласования актуальных целей, выбранных экспертами и оценок актуальности по известным алгоритмам.
3. СППР выбирает из БЗ модели угроз необходимые данные или предлагает ввести недостающие:
- возможности нарушителя N (тип, используемые средства, время действия, характер знаний, место действия, степень информированности);
- возможные каналы проникновения КА(носитель информации, физическая среда, канал связи);
- уязвимости, свойственные «клеткам»
..
4. Аналогично пп.1, 2 СППР проводит процедуры выбора и согласования тактических целей {
}, но с учетом их взаимосвязей со стратегическими { StGi}.
5. СППР запускает блок логического вывода стратегий нападения (атак) для каждой стратегической цели из списка, сформированного в пп.1,2,3. Алгоритм логического вывода реализован в виде продукционной системы, на множестве правил вида: if (<посылка>) then <действие>. Примеры указанных продукций для достоверных утверждений:
if (NP=’аутсайдер’) then КА= ‘визуальный’
if (КА= ‘визуальный’ & NP=’аутсайдер’)
then OA=’экранные формы’
if (StG= ‘бизнес-процесс ’ & OA=’экранные формы’)
then TkG=’ кража данных ’
if ( TkG=’ кража данных ’ & OA=’экранные формы’)
then Str=’ просмотр экрана компьютера через окно помещения’
6. СППР выводит полученный список атак на экран для просмотра экспертами. Если они согласны, то утверждают список. Если нет, система дает возможность поступить двумя способами:
- модифицировать список атак вручную и, затем, согласовывать;
- изменить исходные данные и запустить блок логического вывода снова.
Шаг 2. Моделирование атак по «клеткам» модели OSE/RM.
Следующая задача, которая поставлена и решена в диссертации, это моделирование атак из сгенерированного перечня {
} с учетом особенностей конкретной ИС, которые отражаются на модели OSE/RM. Пусть 
- множество возможных стратегий, соответствующих тактической цели 
. Достичь цель 
в рамках 
означает, что нарушитель должен осуществить некоторые действия в определенных «клетках», направленные на нарушение критериев безопасности 
, т.е. преодоление Мх, установленных в «клетке». Назовем последовательность таких «клеток» цепочкой реализации Аk атаки 
. Таким образом, каждая цепочка представима кортежем Аk(a1,a2,…,aH), где ah, h=1H, - номер «клетки», входящей в цепочку. В свою очередь каждую стратегию 
нарушитель может осуществить несколькими способами, т.е. 
можно поставить в соответствие одну или несколько цепочек Аk : 
(A1, A2,…, АK). Для автоматической генерации цепочек Аk, т.е. номеров включенных в цепочку «клеток» предлагаются алгоритмы анализирующих грамматик G={T, V, N, P, S, F}, где T – множество терминальных символов, т.е. номеров «клеток» 116, V –переменные грамматики. Начальный символ N определяется номером «клетки», соответствующей каналу проникновения (КА) в систему. F=||fij ||, i,j=116 - матрица переходов, определяющая возможность перехода из «клетки» в «клетку», S=||sil||, i=116, l=1,…,L - матрица стратегий, которая содержит экспертные оценки возможности использования i-й «клетки» при реализации l-й стратегии. Р- правила вывода, определяют правила формирования цепочек Аk, из «клеток» в соответствии с матрицами S, F.
Определение. Совокупность 
, в которой 
(A1, A2,…, АK) назовем моделью атак (МА) или моделью стратегий нападения.
Такая модель атак позволит решать задачи прогнозного и оперативного характера, задействованные в контуре управления СПУБ (в 5-й главе эти задачи сформулированы и определены алгоритмы их решения):
Задача 1. Осуществлять контроль «клеток», задействованных во всей цепочке Аk, если в одной из «клеток» зафиксировано действие нарушителя.
Задача 2. Оценить возможность реализации атаки (стратегии 
(A1, A2,…, АK)).
Задача 3. Оценить интервал времени до того момента, когда, вследствие реализации той или иной стратегии нападения, бизнес-процесс «рухнет».
Задача 4. Оценить возможность того, насколько бизнес-процесс защиты (цепочка защитных механизмов b/zj-я, см. главу 1) сможет противостоять Аk-ой цепочке атаки, т.е. оценить возможность (вероятность) противодействия механизмов b/zj-го бизнес-процесса защиты цепочке Аk-ой.
Шаг 3. Оценка возможности противодействия
Здесь решаются задачи 2 и 4.
Шаг 4. Оценка реализуемости целей, соответствующих атаке Аk-ой.
Осуществляется с помощью алгоритмов, приведенных в главе 4.
В результате сценарного анализа эксперты делают вывод о том, насколько эффективно будут срабатывать выбранные варианты КСЗ и, если выводы их устроят, проектирование заканчивается, иначе, согласно схемы рис.2, надо пересмотреть исходные требования и идти на следующую итерацию.
На стадии эксплуатации, когда атака произошла, система мониторинга фиксирует нештатные значения параметров, ассоциированные с какой-либо «клеткой» плоскостей <ИС>, <А>, <З>. Тем самым становится известен объект атаки (ОА) – «клетка». Дальше СУ запускает алгоритм вывода стратегий и целей нарушителя и решает задачи 1-4. Он заключается в следующем:
- По ОА с помощью описанного ранее алгоритма грамматик СУ моделирует цепочки развития атаки Ак(a1,a2,…,aH), в которые входит пораженная «клетка». Пусть это будут цепочки А1(а1, а6, а10), А2(а13, а5, а6,а12, а7), А3(а5, а10, а6, а7, а3), а пораженная «клетка» (зафиксированный в ходе мониторинга ОА) – это «клетка» а6 (она присутствует в каждой цепочке).
- Тогда ясно, что «клетки», стоящие в цепочках до а6, могут быть поражены и СУ должна (задача 1):
- включить механизмы проверки состояния ресурсов данных «клеток»,
- оценить степень и причины поражения,
- или выдать предупреждающее сообщение администратору о необходимости проведения проверки состояния ресурсов данных «клеток» и принятия соответствующих мер.
- «Клетки», стоящие в цепочке после а6, это путь дальнейшего развития атаки. При этом, каждая «клетка» защищена тем или иным Мх. СУ запускает алгоритм задачи 4, чтобы оценить степень противодействия установленных Мх атаке. В результате каждая цепочка получает оценочное число ri, характеризующее возможность дальнейшей осуществимости цепочки, т.е. А1(r1), А2(r2), А3(r3).
- СУ идентифицирует стратегии из списка возможных по цепочкам А1(r1), А2(r2), А3(r3), для этого в БД хранятся соответствия цепочек и стратегий, выявленных ранее, и оценивает их реализуемость (задача2).
- На основании известных стратегий
СУ прогнозирует тактические 
и стратегические StGi цели нарушителя. СУ может это сделать двумя способами: - по таблице взаимосвязи целей и стратегий,
- по алгоритмам, описанным в главе 4, п.4.2.3.
При этом, каждая тактическая и стратегическая цель получает оценочное число ri.
- СУ выводит на экран список стратегий, тактических и стратегический целей, ранжированных по оценочным числам ri. Для критических целей решается задача 3.
Тем самым ЛПР получает компьютерную оценку ситуации при вторжении нарушителя.
В четвертой части главы разработан цикл оперативного управления СУ в рамках стадии сопровождения КСЗ. Он реализует стратегии автоматического восстановления функционирования бизнес-процессов, которые на рис.20 представлены блоками В1 и В2. Сформулированы критерии оценки, ограничения и задачи, позволяющие производить компьютерную оценку возможности восстановления в рамках цикла управления сопровождением КСЗ. Данные для решения задач поступают из БЗ по средствам и мерам защиты. Для решения задач выбора альтернатив по многим критериям здесь используется метод главного критерия, когда ЛПР объявляет, какой критерий важный, а какие перевести в ограничения.
Атаку (инцидент безопасности), нарушающую уровни Т* критериев безопасности, заданных для данного бизнес-процесса, будем описывать вектором 
. Для ее устранения и восстановления штатного режима работы бизнес-процессов СУ выполняет цикл из задач, описанных ниже.
Задача 1. Управление оперативными мерами для сдерживания атаки.
Обозначим 
- оперативные меры, предотвращающие распростра-нение атаки или ее вредоносных последствий, которые надо применить с целью выиграть время для восстановления ресурсов и модификации системы защиты;
Тсдерж – время сдерживания атаки оперативными мерами 
;
Уoz – оценка ущерба, наносимого бизнесу при использовании экстренных мер 
.
Тогда задача формулируется следующим образом: какое время Тсдерж можно обеспечить мерами 
, если эти меры сдерживают дальнейшее распространение атаки 
и причиняют ущерб Уoz
.
Очевидно, минимизация может идет либо по времени, либо по ущербу, либо двухкритериальная оценка.
Задача 2. Ликвидация факта атаки (инцидента безопасности).
Пусть 
- ликвидационные меры,
Тликв – время ликвидации инцидента средствами 
,
Тlz – временные характеристики средства lzi,, например, время развертывания средства,
Stech – технологические параметры сервера в данный момент (например, объем файловой системы и т.п.).
Кроме того, lzi поставим в соответствие оценку инцидента по шкале: «полная_ ликвидация», «возможная_ ликвидация», «неопределенность».
Задача заключается в том, чтобы определить такой рациональный набор ликвидационных мер 
, что 
, при максимально полном устранении инцидента 
, если 
.
При этом, если такого 
не найдется, т.е. 
, то возможны два варианта действий:
1. ослабить требования по устранению инцидента 
, т.е. перейти к значению «возможная_ликвидация»,
2. пересмотреть решение задачи 1 при ослабленном значении требований по ущербу оперативными мерами Уoz(Тj) < Уoz(T* ).
Если решение завершилось успешно, то определяется время 
, которое необходимо, чтобы успеть восстановить нарушенную работоспособность бизнес-процесса.
Задача 3. Восстановление ресурсов бизнес-процессов после ликвидации инцидента.
Обозначим 
– средства и действия, предпринимаемые для восстановления штатной работоспособности элементов бизнес-процесса.
Тvz – время восстановления ресурса средствами{vzi},
Sвосст – затраты на восстановление ресурса.
Задача состоит в том, чтобы выбрать такие средства 
, чтобы при восстановлении ресурсов можно было уложиться в отведенное время, а стоимость восстановления всех ресурсов не превосходила бы понесенных ущербов, т.е. max(Tvz(
)) < Tвосст, и при этом 
, где r – все ресурсы, подлежащие восстановлению, УА-ущерб от атаки.
Если такой набор средств не находится, то необходимо:
- либо оптимизировать затраты и график выполнения восстановительных работ,
- либо пересматривать условия оптимизации задач 1 и 2.
Задача 4. Перепроектирование системы защиты.
Для этого решается задача рационального выбора таких плановых средств 
с учетом модифицированного вектора уязвимостей
, чтобы успеть перепроектировать КСЗ в течение времени сдерживания атаки Тплан Тсдерж. При этом среднее время развертывания этих средств 
, l = K,C,D, было меньше допустимого интервала 
.
Если такого 
не найдется, т.е. 
, то необходимо последовательно возвращаться к задачам 3, 2,1 для ослабления условий оптимизации
Таким образом, описанные задачи составляют цикл управления восстановлением работоспособности бизнес-процессов и их защиты.
В заключении сформулированы основные результаты проведенных исследований и разработок, выполненных в соответствии с заявленными целями.
ОСНОВНЫЕ РЕЗУЛЬТАТЫ ДИССЕРТАЦИОННОЙ РАБОТЫ
В рамках диссертационной работы на основе проведенных автором исследований проведено теоретическое обобщение и получено решение важной научно-технической проблемы создания методологических основ, моделей и алгоритмов компьютерной поддержки проектирования и сопровождения программных средств, обеспечивающих непрерывное управление безопасностью информационных систем.
Цели, поставленные в работе, выполнены полностью, в рамках решения указанной проблемы автором получены следующие основные результаты:
- Разработана методология проектирования систем защиты вычислительных комплексов, реализующая предложенные принципы обеспечения безопасности информационных систем и основанная на принципах открытой среды и процессном подходе.
- Предложена технология работы с референсной моделью открытых информационных систем, которая дает основу концептуальному и детальному проектированию системы защиты
- Предложен механизм, позволяющий совместить представления жизненных циклов ИС и системы защиты. Разработанный модельно-алгоритмический ряд позволяет осуществить компьютерную реализацию управления ЖЦ системы защиты:
- разработаны концептуальная модель и алгоритмы поддержки принятия управленческих решений по выбору стратегий политики безопасности предприятия и формированию целей и требований для системы защиты, основанные на эвристических предпочтениях экспертов и объективных данных;
- разработана структурная процессная модель защиты, позволяющая выстроить для бизнес-процессов предприятия соответствующее обеспечение их безопасности при концептуальном проектировании;
- разработаны компьютерные процедуры и алгоритмы анализа и оценки результатов мониторинга функционирования бизнес-процессов при различных последствиях несанкционированных вторжений на стадиях эксплуатации и сопровождения системы защиты;
- разработаны компьютерные процедуры и алгоритмы поддержки принятия решений при оперативном управлении восстановлением работоспособности бизнес-процессов после вторжений, а также принятия решений по модификации системы защиты.
- Предложен комплекс семантических моделей, структурирующих факторы процесса проектирования, составляющий концептуальную основу базы знаний для обеспечения необходимой информацией процедур проектирования системы защиты.
- Разработана функционально-структурная архитектура компьютерной системы управления безопасностью ИС, включающей как инструментальное средство поддержки проектирования системы защиты, так и целевые, обеспечивающие компьютерную поддержку итерационного управления безопасностью на протяжении ЖЦ системы защиты.
Систематизированное представление функциональности защитного аспекта ИС (п.2 перечисленных результатов) позволяет (на основе методологии функциональной стандартизации): а) специфицировать систему защиты в виде профилей стандартов и/или спецификаций, регламентирующих как ее проектирование, так и эксплуатацию; б) приобрести системе защиты свойства открытости: расширяемости, масштабируемости, переносимости приложений и пользователей, интероперабельности.
Публикации ПО теме диссертационной работы в изданиях из списка ВАК
- Лукинова, О.В. Чего не хватает российским предприятиям? / О.В. Лукинова, В.П. Разбегин // Автоматизация в промышленности. – 2004. – № 3. – С. 14-18.
- Лукинова, О.В. Онтологически ориентированный подход к выявлению типовых моделей деятельности бизнеса / О.В. Лукинова, В.П.Разбегин // Обозрение прикладной и промышленной математики. – 2006. – Т.14. Вып. 1. – С. 127-128.
- Лукинова, О.В. Подходы, стандарты и методы экономического обоснования принятия решений при инвестировании в IT / О.В. Лукинова // Обозрение прикладной и промышленной математикиг. Т.14. – Вып. 5. – 2008. – С.1108-1109.
- Лукинова, О.В. Формализация задачи планирования защиты распределенной компьютерной сети на основе бизнес-процессного подхода / О.В. Лукинова // Надежность». –№1. – 2009. – С.72-80.
- Лукинова, О.В. Задачи управления защитой активов распределенной компьютерной сети при обнаружении атаки / О.В. Лукинова //Надежность. №2. – 2009. – С.30-39.
- Лукинова, О.В. Методы компьютерного управления защитой распределенной корпоративной сети / О.В. Лукинова // Обозрение прикладной и промышленной математики. 2009. –Т.16. – Вып.4. – С.678-679.
- Лукинова, О.В. О семантической формализации понятий процесса проектирования систем защиты / О.В. Лукинова // Обозрение прикладной и промышленной математики. – 2010. – Т.17. – Вып.4. – С.578-580.
- Лукинова, О.В. Компьютерные методы мониторинга и анализа защищенности при функционировании автоматизированных бизнес-процессов компании / О.В. Лукинова //Открытое образование. – 2011. – №4. - С.37-47.
- Лукинова, О.В. Компьютерная поддержка формирования целей при проектировании защиты информационной систем / О.В. Лукинова // Проблемы управления. – 2012. – №4. – С.52-59.
- Лукинова, О.В. Компьютерный мониторинг состояния среды бизнес-процессов при эксплуатации системы защиты / О.В. Лукинова // Открытое образование. – 2012. – №4. - С. 37-47.
- Лукинова, О.В. Методология проектирования систем защиты, построенных на основе референсной модели POSIX OSE/RМ / О.В. Лукинова // Системы высокой доступности. – 2012. – №3. – С.38-45.
- Лукинова, О.В. Представление информационных угроз на основе модели открытой среды / В.С. Кузнецов, О.В. Лукинова // Научно-технический вестник информационных технологий механики и оптики. 2013. – №4. – С. 138-143.
- Лукинова, О.В. Компьютерное формирование целей и стратегий нарушителя безопасности информационной системы / О.В. Лукинова // Открытое образование. 2013. – №4. – С.83-90.
- Лукинова, О.В. Семантическое описание факторов безопасности информационных систем при проектировании систем защиты / О.В. Лукинова // Системы высокой доступности. 2013. – № 3. – С. 149-156.
- Лукинова, О.В. Методологические предпосылки к совмещению жизненных циклов информационной системы и системы ее защиты / О.В. Лукинова // Информационное общество. 2013. – № 5. – С.44-55.
- Лукинова, О.В. Метод конструирования бизнес-процессов, обеспечивающих безопасность информационной системы, на основе межкатегорийного представления плоскости защиты модели OSE/RM / О.В. Лукинова // Надежность. – 2013. - №4. – С.118-127.
ПУБЛИКАЦИИ ПО ТЕМЕ ДИССЕРТАЦИОННОЙ РАБОТЫ
- Лукинова, О.В. Задача планирования защиты РКС / О.В. Лукинова // Труды IV Российской научно-методической конференции «Совершенствование подготовки IT-специалистов по направлению «Прикладная информатика» для инновационной экономики». Москва. - 2008. – С.136-139.
- Лукинова, О.В. Формирование модели угроз безопасности компьютерной сети при бизнес-процессном подходе / О.В. Лукинова // Труды XII научно-практической конференции «Реинжиниринг бизнес-процессов на основе современных информационных технологий». 2009. – С.170-176.
- Лукинова, О.В. Схема управления защитой компьютерной сети / О.В. Лукинова, В.П Разбегтн // Труды Международных научно-практических конференций «Интеллектуальные системы» (AIS’09) и “Интеллектуальные САПР” (CAD-2009). Т. 2. – 2009. – С.439-441.
- Лукинова, О.В. Обобщенная схема принятия компьютерных решений для защиты автоматизированных бизнес-процессов предприятия / О.В. Лукинова // Материалы 3-й международной конференции «Управление развитием крупномасштабных систем». MLSD’2009 – 2009. – Т.2. – С.265-268.
- Лукинова, О.В. Вопросы построения системы защиты компьютерной сети / О.В. Лукинова // Труды международной научно-практической мультиконференции «Управление большими системами- 2009». 2009. – С.247-251.
- Лукинова, О.В. Принятие решений при планировании защиты компьютерной сети на основе бизнес-процессов / О.В. Лукинова // Труды научной сессии НИЯУ МИФИ-10. Т.5. – С. 49-52.
- Лукинова, О.В. Вопросы автоматизации разработки политики информационной безопасности компании на основе онтологий / О.В. Лукинова // Труды XIII научно-практической конференции «Реинжиниринг бизнес-процессов на основе современных информационных технологий». – 2010. – С.194-199.
- Лукинова, О.В. Применение модели POSIX OSE/RM при построении подсистем информационной безопасности / О.В. Лукинова, А.В. Бойченко // Труды Международных научно-практических конференций «Интеллектуальные системы» (AIS’10) и “Интеллектуальные САПР” (CAD-2010). Т. 2. – 2010. – C.473-476.
- Лукинова, О.В. Семантический подход к проектированию системы защиты информационной системы на основе бизнес-процессов / О.В. Лукинова // Труды 12-й Национальной конференции по искусственному интеллекту с международным участием КИИ-10. – 2010. – Т.4. – С.180-185.
- Лукинова, О.В. Задачи компьютерного мониторинга бизнес-процессов при проектировании системы защиты / О.В. Лукинова // Труды XIV научно-практической конференции «Реинжиниринг бизнес-процессов на основе современных информационных технологий». – 2011. – С.184-190.
- Лукинова, О.В. Структуризация механизмов защиты и отображение их на модель OSE/RM / О.В. Лукинова // XII Всероссийский симпозиум по прикладной и промышленной математике.–2011. – Т.18. – Вып.3. – С.450-452.
- Лукинова, О.В. Анализ защищенности автоматизированных бизнес-процессов компании встроенными средствами / О.В. Лукинова // Материалы 5-й международной конференции «Управление развитием крупномасштабных систем». MLSD’2011, М., ИПУ РАН, 2011. – Т.2. – С.262-266.
- Лукинова, О.В. Отображений механизмов защиты на модель OSE\RM / О.В. Лукинова, А.В. Бойченко // Труды Конгресса по интеллектуальным системам и информационным технологиям. 2011. – Т. 2. –С. 372-377.
- Лукинова, О.В. Формирование СППР целей обеспечения безопасности информационной системы / О.В. Лукинова // Труды Международной научно-практической конференции «Управление большими системами 2011». 2011. – Т.3. – С. 90-95.
- Лукинова, О.В. Двойственное представление плоскости функций защиты в модели OSE/RM / О.В. Лукинова, А.В. Бойченко // Труды Конгресса по интеллектуальным системам и информационным технологиям. 2012. – Т. 2. – С. 379-383.
- Лукинова, О.В. Структуризация функций защиты в соответствии с моделью OSE/RM / О.В. Лукинова // XIII Всероссийский симпозиум по прикладной и промышленной математике. 2012. - Т. 9. – Вып.3. – С. 450-452.
- Лукинова, О.В. Когнитивный подход к анализу влияния факторов информационной безопасности / О.В. Лукинова, А.В. Бойченко // Труды 7-й Международной научно-практической конференции «Интегрированные модели и мягкие вычисления в искусственном интеллекте». 2013. – Т. 2. – С. 583-586.
- Лукинова, О.В. Итерационный алгоритм управления жизненным циклом системы защиты / О.В. Лукинова, А.В. Бойченко // Сборник трудов 3-й научно-практической конференции «Актуальные проблемы системной и программной инженерии». 2013. – С. 40-45.
