Содержание к диссертации
Введение
1. Методы систем искусственного интеллекта, используемые при контроле безопасности программных систем
1.1. Продукционные системы 9
1.2. Нейронные сети 13
1.3. Теорема Байеса 18
1.4. Многоагентные системы 19
1.5. Метод опорных векторов 22
1.6. Онтологии 24
Основные выводы к первой главе 30
2. Обеспечение защищённости информационных систем 31
2.1. Информационная система 31
2.1.1. Уровни информационной системы 32
2.1.2. Политика безопасности 33
2.2. Адаптивная безопасность 34
2.2.1. Управление рисками 39
2.2.2. Средства анализа защищённости 44
2.2.3. Средства обнаружения атак 48
Основные выводы ко второй главе 53
3. Создание эталонов для оценки защищённости корпоративных программных систем 54
3.1. Предмет исследования 54
3.2. Анализ защищённости с применением экспертных систем 55
3.3. Модель безопасности информационной системы 58
3.3.1. Субъектно-объектная модель 59
3.3.2. Статический эталон безопасности 60
3.4. Решение на базе многоагентной системы 71
3.4.1. Агент анализа 74
3.4.2. Агенты настройки 77
3.4.3. Агенты защиты 79
3.4.4. Агент противодействия 85
3.4.5. Агент обучения 86
3.4.6. Формальное описание МАС 86
3.5. Оценка коэффициента отклонения SQL запроса 91
3.5.1. Оценка с использованием статистики 91
3.5.2. Оценка с использованием нейронных сетей 95
Основные выводы к третьей главе 98
4. Разработка средств создания эталонов для оценки защищённости корпоративных программных систем 99
4.1. Разработка онтологии предметной области 99
4.2. Описание используемых систем 109
4.3. Пример использования онтологии 112
4.4. Моделирование многоагентной системы защиты 122
4.5. Реализация алгоритма оценки КО для SQL запроса 136
4.5.1. Реализация с использованием статистики 136
4.5.2. Реализация с использованием нейронной сети 143
Основные выводы к четвёртой главе 149
Заключение. Основные результаты работы 150
Список сокращений 151
Список литературы 152
- Теорема Байеса
- Адаптивная безопасность
- Статический эталон безопасности
- Реализация алгоритма оценки КО для SQL запроса
Введение к работе
Актуальность работы. Современное общество не представляет своё существование без множества программных систем (ПС), в том числе и сложных систем автоматизации производства, управления полётами, управления электростанциями (включая атомные и тепловые) и т.п. И, конечно, без корпоративных информационных систем (КИС), обеспечивающих обработку больших объемов ценной информации.
Качество КИС и корпоративных программных систем (КПС) напрямую влияет на эффективность работы предприятий и организаций, а одним из показателей качества КПС (в соответствии с ISO/IEC 9126:1993) является их защищенность. Обеспечение защиты усложняется тем, что нельзя формально описать и предсказать действия злоумышленника. Постоянное развитие и рост сложности КПС – это ещё один фактор, влияющий на их защищённость. Весьма важной становится задача создания эталонов для оценки текущей защищённости КПС, учитывающих не только известные, но и новые уязвимости и угрозы. Такие эталоны безопасности можно было бы применять как при разработке новых систем, так и для оценки защищённости уже функционирующих систем. Задача получения таких эталонов является слабо формализованной и для её решения требуется детальный анализ множества параметров систем.
На сегодняшний день одной из наиболее перспективных областей для проведения исследований является область искусственного интеллекта (ИИ). На данный момент активно ведутся исследования в области ИИ, результаты которых успешно внедряются в различные сферы человеческой деятельности. Поэтому перспективным направлением исследований представляется применение методов, используемых в системах ИИ, для решения задач контроля безопасности (КБ) ПС. Уже имеется несколько примеров успешного использования продукционных систем, нейронных сетей, многоагентных систем для решения задач КБ. Исследованием различных методов анализа защищённости ПС с применением ИИ занимались и продолжают заниматься отечественные и зарубежные авторы: Котенко И.В., Саенко И.Б., Степашкин М.В., Брюхомицкий Ю.А., Резник А.М., Карпов В.В, Ю.Р. Айдаров, Herzog, N. Shahmehri и др.
Цель работы и задачи исследования.
Целью работы является повышение эффективности средств оценки защищённости корпоративных программных систем на основе статических и динамических эталонов безопасности. Объект исследования – корпоративные
программные системы. Предмет исследования - методы и средства создания эталонов для оценки защищённости корпоративных программных систем. Соответствующие области исследований: модели, методы, алгоритмы, языки и программные инструменты для организации взаимодействия программ и программных систем (п. 3 паспорта специальности ВАК 05.13.11); оценка качества, стандартизация и сопровождение программных систем (п. 10 паспорта специальности ВАК 05.13.11). Для достижения поставленной цели в диссертационной работе должны быть решены следующие научно-практические задачи:
анализ методов, используемых в системах ИИ, и их применимости для создания эталонов защищенности КПС;
анализ требований и принципов обеспечения безопасности КПС для уточнения понятия эталона их защищенности;
разработка методов построения эталонов КПС, позволяющих обнаруживать и устранять как известные, так и новые угрозы безопасности КПС;
программная реализация и проверка эффективности разработанных методов при создании и эксплуатации реальных КПС.
Методы исследования. При выполнении работы использованы методы эмпирического исследования, методы теоретического исследования, метод построения онтологий, метод агентного моделирования, статистические методы, нейронные сети, объектно-ориентированное программирование и тестирование программ.
Научная новизна. Научная новизна работы заключается в следующем:
-
Предложено представление КПС в виде комбинации «прототип-реализация», позволяющее выполнять анализ систем целиком или их подсистем и получать статический эталон безопасности КПС. Для предложенного представления формально описана онтология, позволяющая оценивать защищённость КПС с учётом ценности подлежащих защите ресурсов.
-
На основе введенного понятия динамического эталона разработана многоагентная система (МАС), позволяющая получать оценки защищенности КПС с учетом новых видов уязвимостей и угроз: определены состав агентов и требования к ним, взаимосвязи между агентами, разработаны алгоритмы работы агентов. Выполнена оценка защищенности КПС на базе МАС на моделях реальных систем.
3. Разработаны алгоритмы оценки отклонения SQL-запросов с
использованием статистических методов и нейросетевых технологий,
позволяющие обнаруживать потенциально опасные для КПС запросы.
Достоверность полученных результатов. Достоверность полученных результатов и выводов подтверждается их сравнением с результатами использования существующих средств оценки защищённости КПС, результатами оценки защищённости реальных КПС на основе построенного с применением предложенной онтологии статического эталона, результатами программного моделирования разработанной МАС и результатами внедрения разработанных алгоритмов оценки отклонений в КИС НИУ «МЭИ».
Практическая значимость. Практическая значимость полученных результатов определяется использованием их при анализе защищённости систем КИС НИУ «МЭИ» и подтверждается внедрением интеллектуальных агентов защиты для системы «Планирование учебного процесса» (ПЛУП) и выявленными неправомерными действиями в результате их работы.
Регистрация результатов интеллектуальной деятельности.
Зарегистрировано два программных продукта: «Программа для поиска конфигураций, обеспечивающих минимум издержек компании на защитные средства и возможные потери от компьютерных атак» (заявка № 2014612380) и «Анализатор DML запросов для выявления нарушений целостности базы данных» (заявка № 2014612899).
Апробация работы. Основные результаты диссертации докладывались и
обсуждались на международных научно-технических конференциях
«Радиоэлектроника, электротехника и энергетика» (Москва, 2011, 2012, 2014),
«Информационные средства и технологии» (Москва, 2011-2013),
«Информатизация инженерного образования» (Москва, 2012, 2014),
«Информационные технологии. Радиоэлектроника. Телекоммуникации»
(Тольятти, 2012, заочно), международных научно-практических конференциях «Перспективные инновации в науке, образовании, производстве и транспорте 2012» (Одесса, 2012, заочно), «Science, Technology and Higher Education» (Канада, 2013, заочно).
Публикации по теме работы. Основные результаты, полученные при выполнении диссертационной работы, опубликованы в 14 печатных работах, в том числе в трёх изданиях из списка ВАК: «Вестник МЭИ» (2013, № 3), «Вестник МГТУ Станкин» (2013, № 3(№26)), «Безопасность информационных технологий» (2013, № 2).
Структура и объём работы. Диссертация состоит из введения, четырёх глав, заключения, списка литературы, включающего 97 наименований, списка сокращений и приложений. Диссертация содержит 150 страниц машинописного текста без учёта приложений.
Основные положения, выносимые на защиту:
-
Представление «прототип-реализация», позволяющее произвести сравнение одних КПС с другими и получать статический эталон КПС. Формальное описание соответствующей онтологии в программном средстве Protg и её применение для анализа реальных систем «ПЛУП» и «Студент».
-
Структура МАС для оценки защищенности КПС. Алгоритмы работы агентов защиты, вычисление и использование коэффициентов отклонения (КО) для получения динамического эталона КПС. Моделирование МАС в программном средстве AnyLogic с использованием модели системы «Студент».
-
Алгоритмы вычисления КО для SQL-запросов с использованием статистических методов и нейросетевых технологий для защиты от угроз нарушения целостности данных. Программная реализация разработанных алгоритмов с использованием пакета STATISTICA, платформы Microsoft .NET, языка C#.
Теорема Байеса
Продукционные системы - системы, которые используют продукционную модель представления знаний. Эта модель описывает любые знания как правила вида [1]: ЕСЛИ условие ТО действие . Правила называются продукциями. Левая часть ( условие ) описывает необходимые предпосылки для выполнения правой части - действия . Может быть несколько простых условий, которые объединяются в одно с помощью таких логических операций, как И, ИЛИ, НЕ. Общий недостаток продукционных моделей состоит в том, что при накоплении большого числа продукций они могут начать противоречить друг другу. Часто это возникает из-за того, что правила, на самом деле, являются эвристиками, которые не гарантируют стопроцентного результата. Эвристики обычно описывают эксперты на основании своего опыта, поэтому системы, использующие их называются экспертными системами (ЭС). В общем случае продукционную модель можно представить в следующем виде [2]:
Для упрощения механизма логического вывода продукционная модель расширяется порядком, который вводится на множестве продукций [3]. Порядок означает, что каждая последующая продукция должна проверяться только после попыток применить предыдущие продукции. Другой вариант упрощения - это использование приоритетов [4]. При таком подходе в первую очередь рассматриваются продукции, у которых наивысший приоритет. Проблема роста противоречивости базы знаний решается вводом механизмов исключений и/или возвратов [5]. Основные компоненты продукционной системы это база знаний, рабочая память и механизм вывода [6]. Структура продукционной системы представлена на рис. 1.1:
База знаний описывает предметную область с помощью продукций. Рабочая память содержит множество фактов, которые соответствуют текущему этапу логического вывода. Обычно объём рабочей памяти увеличивается по ходу применения правил. Механизм вывода позволяет определить, какие правила применимы к текущей ситуации, и выполнить соответствующие продукции.
Продукционные системы используются при сигнатурном методе анализа [7]. Такой анализ предполагает, что большинство атак развиваются по схожему сценарию и имеют общие черты. В системах защиты информации сигнатуры описывают характерные особенности, необходимые условия, задействованные устройства и последовательность действий при проведении атаки. Одной из реализаций данного подхода является использование БД с сигнатурами известных вторжений и сверка с ними текущих действий пользователя и параметров системы. В случае частичного совпадения система защиты оповещает системного администратора о возможном вторжении. Полное совпадение сигнатуры с текущей активностью маловероятно, так как сценарий атаки может изменяться или сигнатура «зашумлена» другими пользователями, поэтому необходимо использовать именно частичное совпадение характеристик. Чтобы распознать такое совпадение часто используются продукционные системы. Яркими представителями программ, которые в своей работе используют метод сигнатурного анализа, являются системы обнаружения сетевых атак (например, Snort, RealSecure, eTrust Intrusion Detection и др.) и антивирусные сканеры (например, AVZ, Kaspersky Anti-Virus, Microsoft Security Essentials и др.). Первые используют сигнатуры удалённых атак, а вторые – сигнатуры известных вирусов.
Системы обнаружения вторжений (СОВ) хранят информацию о вторжениях в правилах вида: ЕСЛИ причина ТО решение . Часть ЕСЛИ содержит причины, которые необходимы для выполнения успешной атаки. Текущая активность сравнивается с возможными причинами атак и, в случае совпадения, СОВ пытается не допустить неблагоприятного развития событий за счёт выполнения действий, описанных в части ТО [13].
Ещё одним примером системы, содержащей продукционные правила, является брандмауэр Windows [14]. Он позволяет определять правила, разрешающие и запрещающие обращения к заданным портам машины (рис. 1.2).
В антивирусных сканерах продукционные системы могут быть использованы для подтверждения факта вторжения. Эти системы работают с файлами аудита, а также имеют большое количество функций для сбора информации о системе, например, список запущенных процессов, активные сетевые соединения, открытые порты и многое другое. Продукции позволяют строить эвристический вывод на основании правил, заданных экспертом. Примером системы, использующей такой логический вывод, может быть утилита AVZ [15]. Она использует эвристическую проверку системы на наличие программ-шпионов и вирусов. Правила, которые использует механизм вывода AVZ, описывают косвенные признаки вредоносных программ: определённые записи в реестре, наличие файлов на жёстком диске и в оперативной памяти. Программа активно развивается и набор эвристик постоянно обновляется. Пример продукционного правила выглядит следующим образом: ЕСЛИ процесс использует библиотеки для работы с сетью
И количество обнаруженных сигнатур, типичных для отправки почты X ТО записать в рабочую память факт “программа работает с электронной почтой”
В этом примере, в случае выполнения составного условия, в рабочую память попадает новый факт. Он может использоваться в ходе дальнейшего вывода, результатом которого будет информация о наличии в системе вирусов и сведений об их файлах и процессах.
Ещё одной системой, использующей подобие продукционных правил, является ESSA “Экспертная система для анализа защищённости компьютерных систем и сетей” [9]. Система имеет базу рисков, для каждого из которых задана вероятность возникновения, частота и его воздействие на классы возможных активов компании. Также в системе содержится информация по устранению рисков, которая задаётся с помощью конфигураций безопасности. Пользователю предлагается задать активы, которыми располагает его компания. После чего механизм вывода, реализованный в системе, подбирает конфигурации безопасности, которые позволят снизить возможные потери. При этом анализируется стоимость активов и средств защиты. В ESSA продукционные правила используются для уточнения информации об активах компании и для уточнения приоритета применения конфигурации при выводе.
Адаптивная безопасность
На данный момент не существует регламентирующих документов, указывающих как представлять КПС при проектировании и анализе её механизмов защиты. Поэтому выбор, построение и использование определённого представления КПС остаётся решением компании. Однако ряд требований вносят государственные стандарты. Удовлетворение этих требований и подготовка соответствующих отчётов является неотъемлемой частью работы персонала, участвующего в разработке любой КПС. Новое представление «прототип-реализация», помимо устранения описанного выше разрыва, должно помочь решить проблему подготовки отчётов и стать единым хранилищем всей информации об КПС. Например, для оценки актуальности угроз для КПС, которая на данный момент проходит следующим образом. Применительно к информационным системам персональных данных (ИСПДн) первоочередной задачей является классификация ИСПДн, которая проводится согласно руководящему документу [90] от 2008 года. По этому документу необходимо ответить на ряд вопросов относительно КПС. Вот некоторые из них:
1. Состав персональных данных (ПДн), который определяет одна из четырёх категорий. Четвёртая соответствует обезличенным и общедоступным данным, а первая является самой полной. 2. Объём обрабатываемых в ИСПДн персональных данных задаётся с помощью одной из трёх групп: Г1 – более 100 000, Г2 – от 1000 до 100 000 и Г3 – менее 1000. 3. Характеристики безопасности ПДн – конфиденциальность, целостность, доступность и ряд дополнительных.
Эти характеристики являются достаточно общими и могут быть заданы практически для любой ИС. На их основании КПС присваивается один из четырёх классов. Класс 1 (К1) означает, что потеря ПДн повлечёт за собой серьёзные негативные последствия; Класс 4 (К4) – последствия исключены. Присвоенный класс активно используют другие руководящие документы, например, «Модель угроз и нарушителя безопасности персональных данных, обрабатываемых в типовых информационных системах персональных данных отрасли» от 2010 года. Он требует дополнить информацию об КПС, указав на какие данные ориентирована система (база абонентов услуг связи, бухгалтерский учёт, управление персоналом и т.д.), объект информатизации (автономные автоматизированные рабочие места, локальные вычислительные сети, распределённые вычислительные сети) и другие технические и эксплуатационные характеристики. Дополнительно этот руководящий документ позволяет смоделировать тип нарушителя и, используя «Методические рекомендации по обеспечению с помощью криптосредств безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств автоматизации» [91], определяет соответствие типа нарушителя и классу криптографических средств. Наконец, вместе с документами «Методика определения актуальных угроз безопасности персональных данных при их обработке в информационных системах персональных данных» [92] от 2008 года и «Базовая модель угроз безопасности персональных данных при их обработке в информационных системах персональных данных» [93] от 2008 года по характеристикам ИС определяется исходный уровень её защищённости – коэффициент Y1 (0 – высокая, 5 – средняя и 10 – низкая). Вторым параметром для определения актуальности угроз является частота (или вероятность) реализации угрозы – Y2. Данный показатель выбирается экспертным путём из следующих вариантов: 0 – угроза маловероятна, 2 – низкая, 5 – средняя и 10 – высокая вероятности угрозы. Y1 и Y2 позволяют определить коэффициент реализуемости угрозы (Y) как (Y1+Y2)/20, который принимает одно из следующих значение – низкий (Y 0.3), средний (0.3 Y 0.6), высокий (0.6 Y 0.8), очень высокий (Y 0.8). Для окончательной оценки актуальности угроз экспертам необходимо задать опасность (низкая, средняя, высокая) каждой угрозы и по матрице расчетов актуальности угроз безопасности ПДн определить значение актуальности.
Видно, что для решения задачи определения актуальности угроз необходимо сильно задействовать знания экспертов, но даже при этом информация о вероятностях и опасностях угроз будет недостаточно точной. Частично решить эту проблему позволит разрабатываемое представление КПС.
Характеристики КПС, отмеченные в данном примере, включим в представление эталона, которое мы хотим получить. Однако строго ограничивать их не будем. Введём абстрактное понятие хранилища информации (ХИ) как «нечто», содержащее в себе информационные ресурсы. Описываться это «нечто» будет с помощью свойств. Под свойством будем понимать уникальный идентификатор свойства и значение. Таким образом, КПС – это ХИ с определённым набором свойств и их значениями, или более формально: КПС = ХИ = {Свойство 1, Свойство 2, … Свойство N} Свойство = Идентификатор свойства, Значение Описание представлено пока в достаточно общем виде, но главный смысл в том, что представление «прототип-реализация» будет содержать общую для КПС информацию и собирать в себе данные для возможности дальнейшего анализа по различным стандартам.
Связи между ХИ будут определяться каналами передачи информации. Канал передачи информации (КПИ) – «нечто», с помощью которого информация передаётся от одного ХИ к другому. Можно сказать, что КПИ – это ХИ, в котором нахождение данных строго ограничено по времени. КПИ также описывается с помощью свойств. КПИ = {Свойство 1, Свойство 2, … Свойство N} Любое ХИ и КПС, как его частный случай, декомпозируется на несколько ХИ для уточнения его структуры и внутренних связей. Для того чтобы не потерять связь с «родительским» ХИ, выделим свойства ID и ParentID для задания уникального идентификатора ХИ и уникального идентификатора «родительского» ХИ соответственно: Свойство – уникальный идентификатор = ID, Значение Свойство – уникальный идентификатор «родительского» ХИ = ParentID, Значение Тип значения этих свойств произвольный, например, целое число, строка или GUID (Globally Unique Identifier — статистически уникальный 128-битный идентификатор). В дальнейших примерах будем использовать целочисленное значение данных свойств. С учётом декомпозиции полезной будет возможность указать значение для свойства с помощью функции, определённой над свойствами «дочерних» элементов. Примерами операций, которые будет удобно использовать при описании КПС, могут быть сумма, максимум или минимум. Например, объём всех обрабатываемых КПС персональных данных (ПДн) можно определить с помощью функции SUBSUM, суммирующей значение одинаковых свойств дочерних элементов:
Свойство – Сумма значений «дочерних элементов» = Объём обрабатываемых ПДн, SUBSUM (Объём обрабатываемых ПДн) Все схемы ХИ и КПИ представляются в виде дерева. При этом начальным узлом является схема, состоящая из одного элемента ХИ, описывающего самые общие свойства КПС. Множество схем ХИ и КПИ отнесём к верхнему ярусу представления. Информация на этом ярусе будет основой для анализа рисков и угроз. Представление «прототип-реализация» будет состоять из 2-х ярусов: ый ярус даёт представление высокого уровня о КПС; -ой ярус детально описывает как в КПС реализуются ХИ и КПИ. Рассмотрим элементы 2-ого яруса подробнее. На втором ярусе описывается техническая реализация системы: указываются сервера (хосты), на которых установлено ПО, и состав этого обеспечения – ОС, СУБД, специфические программы, сетевые службы, используемые протоколы и др. При необходимости данный ярус, как и предыдущий, декомпозируется на несколько схем. Важным требованием модели является наличие связи между ХИ и КПИ с набором ПО, отвечающим за реализацию. Понятно, что это условие не удастся выполнить абсолютно на всех схемах, но необходимо к этому стремиться. Данное требование обеспечивает неявную связь уязвимостей с угрозами, которая будет использована для анализа защищённости КПС и поиска эталонов.
Статический эталон безопасности
Однако данный подход для получения эталонов безопасности, как и его развитие с более детальным описанием, упирается в необходимость обладать большим количеством схем. Во-первых, на данный момент схем нет, и никто спешить их разрабатывать не станет, и, во-вторых, информация о технической реализации систем, количестве и результатах атак очень часто бывает закрытой. Кроме того, важно не только изначально спроектировать КПС безопасно, но и уметь потом сохранять, поддерживать и даже расширять заложенный фундамент. Всё это направляет ко второму возможному варианту эталона – динамическому. Эталону, который меняется в ходе функционирования КПС и отображает её поведение во времени.
Как видно из главы 2, защищённость современных КПС должна адаптироваться к новым видам атак [11]. Большинство современных КПС имеют распределённую архитектуру. Важно понимать, что каждая машина, входящая в состав КПС, потенциально уязвима. Поэтому при организации защиты КПС необходимо ориентироваться на все её компоненты. Кроме этого средства защиты должны уметь быстро и адекватно реагировать на добавление новых компонентов, чтобы они становились защищёнными максимально быстро. Существуют и другие требования к защищённости: функциональные, эргономические, экономические, технические и организационные. Эти требования достаточно общие и могут быть применены для любого ПО. Часть из них ложатся непосредственно на разработчиков, а часть накладывается на архитектуру решения. Для удовлетворения выделенных требований архитектура системы защиты, оперирующая динамическими эталонами безопасности, будет базироваться на МАС.
Любую КПС можно разделить на взаимосвязанные (и не очень) компоненты. Для функционирования все они должны быть правильно сконфигурированы, настроены механизмы авторизации и аутентификации, в БД должна содержаться справочная информация, заданы начальные параметры запуска служб и т.д. Эти начальные настройки будем считать эталонным, все они могут (и будут) изменяться в ходе функционирования системы. Каждый из компонентов имеет свой набор настроек, часть из которых входят в состав эталона. В процессе функционирования КПС, компоненты, входящие в её состав, выполняют определённые действия и решают свои задачи. Например, СУБД решает задачу по управлению базами данных, отвечает за механизмы синхронизации и др., веб-сервер – задачу обработки веб-запросов, а специализированные прикладные программы – более специфичные задачи конечного пользователя. Записи об изменении настроек компонентов и выполнении ими операций должны протоколироваться для последующего анализа. Например, анализ запротоколированных записей применяется для выявления несанкционированного доступа (НСД) и его причин. Однако стоит отметить, что, осуществив НСД, злоумышленник захочет получить доступ к файлам аудита и удалить записи, связанные с его активностью в системе. Поэтому механизм протоколирования должен защищаться как любая другая часть КПС.
Таким образом, КПС – набор взаимосвязанных компонент. Компоненты могут быть связаны как напрямую, так и косвенно – лишь как часть единой КПС. Для надёжной защиты необходимо защищать каждый из компонентов.
Опираясь на вышесказанное, можно сделать следующие допущения: 1. КПС состоит из компонентов, которые имеют начальные настройки и выполняют определённый (конечный) набор действий. 2. В процессе функционирования КПС настройки компонент могут изменяться, а сами компоненты выполняют операции, необходимые для решения задач. 3. Изменения настроек и выполнение действий можно отслеживать. Типичными причинами несанкционированного доступа являются ошибки конфигурации, слабая защищённость средств авторизации, ошибки в ПО, злоупотребление служебными полномочиями, прослушивание каналов связи. Эти причины являются достаточно общими проблемами и в целях более эффективной защиты могут дополняться и описываться более подробно. Однако предусмотреть их все невозможно, так как это потребует гигантских усилий со стороны экспертов в области информационной безопасности и огромных технических затрат. Поэтому, стоит отталкиваться от того, что независимо от причины НСД, сам доступ (с технической точки зрения) – переконфигурация компонент и/или выполнение с их помощью несанкционированных операций. Всё это создаёт дополнительную, отличающуюся от обычной, нагрузку на систему. Определение и противодействие этой нагрузке и есть задача обеспечения защиты КПС.
Например, злоумышленник, используя неизвестную уязвимость, получил доступ к БД и считывает полностью таблицу пользователей и паролей. При этом он создаёт непривычную нагрузку на СУБД, так как в ходе ежедневного функционирования КПС из данной таблички выбирается лишь 1 пользователь в 1 запросе. Или в случае проведения атаки, направленной на отказ в обслуживании (Distributed Denial of Service, DDoS), значительно повышается нагрузка на вебсервер. Количество запросов растёт, веб-сервер не успевает их все обрабатывать, что приводит к его отказу для части легальных запросов, а, в конечном счете, и для всех. И в первом и во втором случае злоумышленник выполняет действия компонентов. Причём эти действия являются непривычной нагрузкой для системы.
Реализация алгоритма оценки КО для SQL запроса
Для проверки возможностей онтологии, схемы рассматриваемых систем были введены в Protg. Таблице ПД было выставлено значение 100% для свойства конфиденциальность данных, данным куба OLAP – 100% целостность, веб-серверу – 100% доступность. Выставленное свойство означает важность сохранения указанного свойства в процентах. Рассматривались три возможных нарушения политики безопасности. Во-первых, это угроза конфиденциальности ПД студентов. Злоумышленник может пытаться захватить эти данные и воспользоваться ими в своих интересах. Таким образом, целью (с помощью свойства «Направлена на») для данной угрозы была выбрана таблица ПД, которая присутствует в обеих системах. Во-вторых, можно рассматривать как актуальную – угрозу доступности веб-сервера. Если он на время будет выведен из строя, то это приведёт к определённым потерям. Например, к потере доверия пользователей и потере актуальности информации в БД. В данном случае свойство «Направлена на» было связано с прототипом веб-сервера. В-третьих, злоумышленник может нарушить целостность данных, содержащихся в кубе OLAP, для того чтобы отчёты, сгенерированные на их основе, были неверными.
После ввода исходных данных были проанализированы результаты работы «Рассуждателя», входящего в состав Protg. Его работа была возможна, так как для описания классов, их свойств и индивидов использовался язык OWL DL.
Первое что стало заметно – это то, что введённые угрозы были классифицированы и разделены на три класса: первая попала в класс угрозы конфиденциальности, вторая – угрозы доступности, третья – угроза целостности. Угрозы были разделены на основании классов данных, на которые они направлены. На примере угрозы нарушения доступности вывод строился следующим образом (рис. 4.6): Рис. 4.6. Окно «объяснения» Protg 1. угроза направлена на таблицу с ПД студентов; 2. таблица ПД студентов имеет свойство-характеристику – «Конфиденциальность данных»; 3. к классу «Уязвимые к угрозам конфиденциальности» относятся те индивиды, у которых имеется как минимум одно свойство «Конфиденциальность данных»; 4. к классу «Угрозы конфиденциальности» относятся те индивиды, которые «Направлены на» индивидов, принадлежащих к классам «Уязвимые к угрозам конфиденциальности». Результаты работы «Рассуждателя» Protg
Второе, что удалось определить «Рассуждателю» – это потенциальные уязвимости, которые могут быть задействованы при реализации угрозы. Для примера было добавлено по три индивида для MS SQL Server и MS IIS, которые обладают подсвойствами «Ущерб», и таким образом попадают в класс уязвимостей. Перечень вычисленных отношений представлен на рис. 4.7. Для первой угрозы «Рассуждатель» определил все шесть уязвимостей как потенциальные для реализации угрозы, так как уязвимые данные могут оказаться как в СУБД, так и в кэше веб-сервера. Для второй (угрозы доступности вебсервера) могут быть задействованы только три уязвимости, которые напрямую направлены на веб-сервер. «Вывод» данных связей выглядит сложнее (рис. 4.8). Он основан на определённых выше цепочках связей.
Объяснение работы «Рассуждателя»
Однако при вычислении описанной связи UseVulnerability, соответствующей потенциальным для реализации угрозы уязвимостям, «Рассуждатель» не учитывает тот тип ущерба, который будет нанесён, и ту характеристику, которую следует оберегать. Учесть данную особенность позволяет встроенный в систему Protg язык запросов к данным, представленным в модели RDF – SPARQL. Это ещё одна из рекомендаций консорциума W3C, и поэтому он был использован как в Protg, так и в данном разделе. С помощью SPARQL можно сделать сложный запрос к информации, содержащейся в онтологии. Следующий запрос выведет список тех уязвимостей, которые могут быть использованы при реализации угроз, направленных на SQLAnalysisServices:
Встроенный интерпретатор запросов SPARQL в Protg не позволяет использовать те свойства, которые были выведены «Рассуждателем». Поэтому запрос частично дублирует введённые ранее цепочки свойств-связей.
Теперь, если добавить в пример вторую возможную реализацию СУБД – MySQL, то можно выполнить сравнение двух компонентов реализации и выбрать менее уязвимый. Для такого сравнения в модель были добавлены пять уязвимостей для MySQL и три для MS SQL Server. Это те уязвимости сравниваемых СУБД, которые были выявлены за последний месяц (на дату проведения анализа). Информация об уязвимостях и величине ущерба конфиденциальности, целостности и доступности взята из OSVDB.
Для того чтобы «Рассуждатель» учитывал MySQL, как возможный вариант реализации СУБД, и имел возможность найти потенциальные уязвимости, была добавлена ещё одна связь «Содержит». «Рассуждатель» Protg вывел все пять уязвимостей. Теперь сравним рассматриваемые компоненты по возможному ущербу. Следующий запрос отобразит все возможные значения подсвойств свойства «ущерб» для всех угроз, направленных на элементы представления:
Так как потенциальный ущерб основывается на коэффициентах CVSS, то его сравнение с ценностью характеристик, которые могут быть нарушены, даст ответ на вопрос: стоит ли усиливать защиты или риск будет принят? Автоматизировать этот процесс позволяет система ESSA, разработанная автором [9].
Для дальнейшего тестирования добавим индивидов, которые будут описывать систему ПЛУП. При этом схема всех индивидов в Protg примет следующий вид (рис. 4.11). Можно заметить, что на схеме первого яруса присутствуют похожие хранилища информации (ХИ) – сервера с БД, которые содержат ПД и взаимодействуют с веб-сервером. Признаками схожести являются попадание в одинаковые классы, содержание данных одинаковых классов, наличие одинаковых свойств-связей, описывающих пересылку данных. Конечно, признаков, по которым было выдвинуто предположение о схожести, не так много, но среди них присутствует как структура КПС, так и простые свойства. В данном контексте не говорится об идентичности ХИ, а лишь предполагается их схожесть. На основании выдвинутого предположения делается вывод, что при подборе компонентов для реализации необходимо обратить внимание на то, как они представлены на схемах реализации второго яруса для схожих ХИ. В данном случае имеется один «схожий» ХИ – это ХИ со схемы системы «Студент».
