WWW.DOC.KNIGI-X.RU
БЕСПЛАТНАЯ  ИНТЕРНЕТ  БИБЛИОТЕКА - Различные документы
 

Pages:   || 2 | 3 |

«Исследование и разработка методов и средств создания эталонов для оценки защищённости корпоративных программных систем ...»

-- [ Страница 2 ] --

Свойства компонентов второго яруса, которые описывают аппаратное и программное обеспечение разрабатываемой КПС. Используются для управления уязвимостями.

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

Имеются и другие вероятные варианты использования. Например, выделив наиболее ценные ХИ на этапе анализа рисков, необходимо сразу направить ресурсы на их защиту. Для ценной БД необходимо потребовать её шифрование при реализации. Данный процесс легко автоматизировать и динамически изменять уровень защиты, достигая баланс между затратами на защиту и возможными потерями. Для типовых ХИ, таких как веб-сервер или БД, полезно использовать опыт существующих систем на базе их представлений ХИ-КПИ.

Это позволяет выработать так называемые «best practices», то есть лучшие подходы. Идея заключается в сравнении прототипов и выявлении схожих среди них по свойствам и структуре. При разработке новых решений необходимо обращать внимание и учитывать результаты работы существующих решений.

Возможно, брать их за основу. Количество инцидентов, связанных с действиями компьютерных злоумышленников, определяет обоснованность реализации ХИ с точки зрения безопасности. Наконец, представление «прототип-реализация»



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

Это требует очевидных временных и финансовых затрат. Верхний ярус связывает логические компоненты КПС с набором актуальных угроз, определённых на этапе анализа рисков. По прошествии некоторого времени работы КПС, необходимо подсчитать количество реализованных угроз для компонентов первого яруса и учесть задействованные уязвимости. При этом и появится связь между угрозами и используемыми для их реализации уязвимостями. Таким образом, обладая достаточно большой выборкой представлений и результатов по проведению анализа рисков, а также информацией об атаках, можно связать между собой конкретные угрозы и уязвимости. Эта же информация является основой и для оценки вероятности угроз, что позволит снизить ручной труд при анализе рисков.

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

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

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

Кроме того, важно не только изначально спроектировать КПС безопасно, но и уметь потом сохранять, поддерживать и даже расширять заложенный фундамент.

Всё это направляет ко второму возможному варианту эталона – динамическому.

Эталону, который меняется в ходе функционирования КПС и отображает её поведение во времени.

3.4. Решение на базе многоагентной системы Как видно из главы 2, защищённость современных КПС должна адаптироваться к новым видам атак [11]. Большинство современных КПС имеют распределённую архитектуру. Важно понимать, что каждая машина, входящая в состав КПС, потенциально уязвима. Поэтому при организации защиты КПС необходимо ориентироваться на все её компоненты. Кроме этого средства защиты должны уметь быстро и адекватно реагировать на добавление новых компонентов, чтобы они становились защищёнными максимально быстро.

Существуют и другие требования к защищённости: функциональные, эргономические, экономические, технические и организационные. Эти требования достаточно общие и могут быть применены для любого ПО. Часть из них ложатся непосредственно на разработчиков, а часть накладывается на архитектуру решения. Для удовлетворения выделенных требований архитектура системы защиты, оперирующая динамическими эталонами безопасности, будет базироваться на МАС.

Любую КПС можно разделить на взаимосвязанные (и не очень) компоненты. Для функционирования все они должны быть правильно сконфигурированы, настроены механизмы авторизации и аутентификации, в БД должна содержаться справочная информация, заданы начальные параметры запуска служб и т.д. Эти начальные настройки будем считать эталонным, все они могут (и будут) изменяться в ходе функционирования системы. Каждый из компонентов имеет свой набор настроек, часть из которых входят в состав эталона. В процессе функционирования КПС, компоненты, входящие в её состав, выполняют определённые действия и решают свои задачи. Например, СУБД решает задачу по управлению базами данных, отвечает за механизмы синхронизации и др., веб-сервер – задачу обработки веб-запросов, а специализированные прикладные программы – более специфичные задачи конечного пользователя. Записи об изменении настроек компонентов и выполнении ими операций должны протоколироваться для последующего анализа. Например, анализ запротоколированных записей применяется для выявления несанкционированного доступа (НСД) и его причин. Однако стоит отметить, что, осуществив НСД, злоумышленник захочет получить доступ к файлам аудита и удалить записи, связанные с его активностью в системе. Поэтому механизм протоколирования должен защищаться как любая другая часть КПС.

Таким образом, КПС – набор взаимосвязанных компонент. Компоненты могут быть связаны как напрямую, так и косвенно – лишь как часть единой КПС.

Для надёжной защиты необходимо защищать каждый из компонентов.

Опираясь на вышесказанное, можно сделать следующие допущения:

1. КПС состоит из компонентов, которые имеют начальные настройки и выполняют определённый (конечный) набор действий.

2. В процессе функционирования КПС настройки компонент могут изменяться, а сами компоненты выполняют операции, необходимые для решения задач.

3. Изменения настроек и выполнение действий можно отслеживать.

Типичными причинами несанкционированного доступа являются ошибки конфигурации, слабая защищённость средств авторизации, ошибки в ПО, злоупотребление служебными полномочиями, прослушивание каналов связи. Эти причины являются достаточно общими проблемами и в целях более эффективной защиты могут дополняться и описываться более подробно. Однако предусмотреть их все невозможно, так как это потребует гигантских усилий со стороны экспертов в области информационной безопасности и огромных технических затрат. Поэтому, стоит отталкиваться от того, что независимо от причины НСД, сам доступ (с технической точки зрения) – переконфигурация компонент и/или выполнение с их помощью несанкционированных операций. Всё это создаёт дополнительную, отличающуюся от обычной, нагрузку на систему. Определение и противодействие этой нагрузке и есть задача обеспечения защиты КПС.

Например, злоумышленник, используя неизвестную уязвимость, получил доступ к БД и считывает полностью таблицу пользователей и паролей. При этом он создаёт непривычную нагрузку на СУБД, так как в ходе ежедневного функционирования КПС из данной таблички выбирается лишь 1 пользователь в 1 запросе. Или в случае проведения атаки, направленной на отказ в обслуживании (Distributed Denial of Service, DDoS), значительно повышается нагрузка на вебсервер. Количество запросов растёт, веб-сервер не успевает их все обрабатывать, что приводит к его отказу для части легальных запросов, а, в конечном счете, и для всех. И в первом и во втором случае злоумышленник выполняет действия компонентов. Причём эти действия являются непривычной нагрузкой для системы.

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





Для распределения этих затрат, как было замечено выше, будет использован такой подход искусственного интеллекта как многоагентные системы (МАС). В соответствии с данным подходом, каждому компоненту КПС необходимо сопоставить агента [12]. Компоненты типовой КПС распределены по нескольким узлам, поэтому агенты МАС будут также функционировать на разных узлах, что обеспечит экономию вычислительных ресурсов. Такое решение позволит не только распределить затраты на работу системы защиты, но и будет легко адаптироваться к изменениям в сетевой архитектуре. Кроме того, за счёт возможности создания новых агентов обеспечивается гибкость решения и высокая масштабируемость. Наконец, за счёт распределения достигается и повышенная отказоустойчивость. При выходе одного агента из строя, остальные продолжают функционировать, и МАС в целом также продолжает работать и решать свои задачи. В случае возникновения несанкционированных действий распределённое расположение системы защиты даёт плюс. Её сложнее атаковать и вывести из строя, нежели системы с единым сервером защиты. Распределенная по сети информация и распределенная защита требуют от злоумышленника проводить атаку многих узлов одновременно.

Однако, несмотря на раздельность отдельных агентов, управление всей СКБ может производиться централизованно. Таким образом, использование МАС как фундамент для разработки системы защиты даёт большие преимущества.

Выделим те классы агентов, которые должны быть представлены в СКБ, основанной на МАС, и рассмотрим варианты их взаимодействия.

3.4.1. Агент анализа Для организации защиты на базе МАС назначим каждому компоненту или классу компонентов защищаемой КПС агентов. Пусть имеется КПС, защиту которой необходимо организовать. Изначально каждый из её компонентов потенциально уязвим, и, вероятно, уже используется злоумышленником. Поэтому первая часть по построению защиты – это анализ и проверка текущей защищённости. Каждый из компонентов КПС должен анализироваться на наличие уязвимостей. За этот анализ и будут отвечать агенты анализа (АА).

Варианты работы АА схожи с методами работы САЗ: это механизмы сканирования и зондирования. Как и в случае САЗ, сканирование не даёт точного ответа на вопрос имеется ли уязвимость в компоненте, однако не может привести и к сбою в его работе. Зондирование, как активный метод анализа, опасен для реализации в агенте, так как это может привести к сбою в работе компонента, а в случае одновременного зондирования несколькими агентами, и к более опасным последствиям.

Команды АА выполняют сложные, составные проверки. Исходными данными для таких проверок выступает граф атак. Граф атак – это граф, представляющий всевозможные последовательности действий нарушителя для достижения угроз (целей).

Существуют различные виды графов атак:

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

графы, у которых вершины соответствуют результатам атак, а дуги – элементарным атакам;

графы, у которых вершины являются результатом атаки или элементарной атакой, а дуги описывают необходимые условия для осуществления атаки.

Элементарная атака – это использование любой уязвимости, например, переполнение буфера. Используя различные графы атак, АА способны моделировать поведение злоумышленника и проверять систему и её компоненты не только на наличие уязвимости, но и на возможность реализации атаки, как правило, состоящей из использования нескольких «брешей» в защите. Примером простейшего сценария атаки является получение локального доступа к машине, затем повышение прав до уровня администратора, и, наконец, обращение к конфиденциальной информации и очистка логов для заметания следов. По отдельности каждая из уязвимостей маловероятно станет причиной серьёзных потерь, но их грамотная комбинация может быть очень опасна.

Можно выделить два подкласса АА – агент анализа уровня компонента (ААУК) и агент анализа уровня хоста (ААУХ). Первый является более примитивным и обладает достаточно простой задачей – провести проверку (опрос) одного компонента. Этот агент начинает работу по расписанию либо по инициативе агента уровня хоста. По окончанию работы ААУК сообщает о результатах ААУХ. ААУК ничего не знает о своих «собратьях» и работает согласно своим убеждениям и обещаниям, данным ААУХ. Для функционирования данного агента ему необходимы знания о проверяемом компоненте или классе компонентов, условной стоимости каждой из проверок, потенциальном ущербе и вышестоящем агенте уровня хоста.

ААУХ – более «интеллектуальный» и является агентом «мета-уровня» по отношению к ААУК, т.е. агентом, который способен координировать распределённое решение общей задачи анализа.

У этого агента больше возможностей и обязанностей:

1. Выполнение проверок уровня хоста.

2. Инициализация проверок ААУК, сбор и обработка результатов.

3. Организация сложных проверок хоста на основании графа атак. Агент выступает в роли субординатора, декомпозирует атаку, определяет, имеются ли у него и подчинённых агентов технические возможности (необходимые действия агентов реализованы в них) для проведения атаки, и инициирует соответствующие проверки. При этом он работает c подчинёнными агентами как последовательно, передавая результаты их работы по цепочке, так и параллельно.

4. Взаимодействие с другими ААУХ. На основании графа атак ААУХ должны быть в состоянии организовать сложную, распределённую проверку. Для этого, как и в случае составной локальной проверки, ААУХ, являющийся инициатором проверки, определяет, имеются ли необходимые возможности у агентов анализа, и координирует проведение атаки. Кроме того, так как данные агенты взаимодействуют преимущественно через сетевые интерфейсы, в них может быть заложен функционал и по проверке траффика.

5. Управление популяцией агентов уровня компонентов для уменьшения нагрузки на машину и организации распределённых проверок.

Применительно к одной машине должен присутствовать как минимум один ААУХ, и, возможно, несколько ААУК. Для функционирования агенту уровня хоста необходимы те же знания, что и ААУК, плюс информация о других агентах анализа уровня хоста.

Таким образом, цель агентов анализа проверить имеются ли бреши в защите, оценить потенциальный ущерб и сообщить об этом другим агентам, входящих в состав МАС. Когда АА находит уязвимость, он начинает поиск агента настройки, который её устранит. В случае проведения составной проверки агент защиты ожидает её завершения. Другой возможный вариант – это сброс обещания по прошествии определённого времени. Таким образом, ещё одна цель каждого агента анализа – это поиск агента для устранения найденной ошибки.

3.4.2. Агенты настройки Класс агентов настройки (АН) отвечает за устранение уязвимостей, которые были обнаружены агентами анализа. ПО, отвечающее за поиск уязвимостей, обычно содержит средства по их устранению. Например, антивирус, определив подозрительные файлы, предлагает удалить их или переместить в карантин. Для этого он использует обновляемую базу знаний. Однако поиск проблемы и её решение лучше разделять на два модуля – на два класса агентов. В этом случае будет обеспечена большая гибкость, так как разные АН смогут одновременно исправлять ошибки конфигурации и использовать для этого различные механизмы. Доработка и/или добавление новых алгоритмов устранения уязвимостей состоит в работе над одним агентом. Наконец, агентом настройки может быть и системный администратор, что является крайне сложным для роли агента анализа. Таким образом, поиск ошибок и их устранение разделено на два класса агентов, в каждом из которых необходимо сосредоточиться на поставленной задаче.

Получив сообщение о наличии уязвимости, которую необходимо устранить, АН начинает поиск способов решения. Например, новую конфигурацию, которую следует применить, или обновление (патч), которое следует загрузить и установить. Найдя решение, АН договаривается с АЗ и начинает его применение.

На каждом узле должен располагаться как минимум один АН. В случае если несколько АН расположены на одной машине, то АЗ выбирает и договаривается только с одним из них. При этом агенты защиты общаются только с агентами настройки, которые установлены на той же машине. Есть вероятность, что устранение проблемы потребует изменение нескольких компонентов, в том числе и на различных машинах. Для реализации такого варианта АН кооперируются в команды. При этом инициатор становится координатором, и остальные агенты ему подчиняются. Другая возможная проблема – это сокращение популяции ААУК при наличии договорённости между конкретным ААУК и АН. Для разрешения этой проблемы обязательства АН должны перейти на ААУХ, который всегда присутствует на машине как минимум в одном экземпляре.

Таким образом, цель агентов настройки – это устранение уязвимостей. Для того чтобы подтвердить выполнение этой цели, АН вправе инициировать повторную проверку АА. Для работы АН необходима информация об окружающих компонентах, агентах защиты на текущем узле и агентах настройки на других узлах. Интересной особенностью является то, что в роли более «интеллектуального» АН может выступить «натуральный» агент – системный администратор.

Рис. 3.4. Структурная схема работы агентов анализа и агентов настройки АА и АН обеспечат первичную проверку КПС и устранение найденных уязвимостей. Схема их работы представлена на рис 3.4. Вторая, но не менее важная часть защиты, – это анализ текущей активности и обнаружение вторжений. За это будут отвечать агенты защиты.

3.4.3. Агенты защиты Задача агентов защиты (АЗ) проверять соответствует ли работа компонента его привычному поведению и определять подозрительную активность. Под привычным поведением компонента будем понимать наиболее частое его использование, ту совокупность операций, которые он наиболее часто выполняет.

Оцениваться соответствие может по-разному – например, на основании статистики по использованию, по общему объёму операций или с использованием сведений об их последовательности. Ещё одним вариантом оценки является анализ нагрузки на процессор и другие аппаратные ресурсы хоста. Выбор зависит от специфики компонента, главное чтобы действия злоумышленника давали отклонения от привычного поведения.

Важным требованием к классу АЗ является возможность адаптации к новым видам атак. По отдельности каждый АЗ может использовать свой алгоритм распознавания несанкционированных действий и реализовывать различные методы кластеризации и классификации, наиболее подходящие по функциям и задачам компонента. Однако можно заметить, что для такой работы АЗ необходимо «следить» за работой подопечного компонента и, возможно, прогнозировать значения снимаемых характеристик. Именно агенты защиты представляют наибольший интерес, и в их контексте далее будет определён динамический эталон безопасности.

«Следит» АЗ одним из двух способов. Первый вариант - это пассивное получение информации на основании сбора значений конфигурационных файлов, их сравнения и выявления изменений, и анализ файлов аудита и логов для получения информации о выполненных операциях. Плюс такого подхода в том, что агенты практически не будут влиять на функционирование КПС, так как не будут вмешиваться в её работу для отслеживания активности компонентов.

Однако надо понимать, что в этом случае агенты будут слегка «запаздывать» за изменениями в КПС. Размер «задержки» определяется частотой опроса необходимых файлов. Частота опроса должна изменяться пропорционально размеру изменения собираемых значений – чем сильнее изменения (подозрительней активность), тем «внимательней» (чаще) необходимо следить. В этом случае злоумышленник имеет возможность выполнить несанкционированное действие прежде, чем оно будет обнаружено. Технически такие агенты реализуются как ПО, работающее в фоновом режиме. Например, службы Windows или демоны в Unix системах.

Второй способ – это активный сбор информации, то есть прямое вмешательство в работу КПС с целью контроля производимых операций.

Данный подход является в некотором роде противоположенным предыдущему, так как приводит к задержкам в работе самой КПС. Однако агент всегда обладает самой актуальной информацией и способен ограничить выполнение операции, которая, по его мнению, несанкционирована. Технически данный подход реализуются как обработчики определённых событий, например, для ОС MS Windows – это хуки, а в MS SQL Server – это триггеры.

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

В отличие от АА, у которых среди экземпляров, работающих на одном узле, выделяется агент уровня хоста, осуществляющий координацию остальных АА, все АЗ равноправны. Для АА выделение координатора оправдано тем, что анализ защищённости это периодическая операция, которая выполняется по расписанию или инициируется системным администратором. Успешный запуск и рабочее состояние ААУХ определяет запланированный ход анализа узла. Анализ компонентов контролирует ААУХ. Для подтверждения легальности исполняемого кода необходимо проверять цифровые подписи запущенного ПО.

Это снимет возможные проблемы при атаках на АА.

Защита, в отличие от анализа, должна осуществляться постоянно. Потеря одного АЗ не должна привести к ошибкам в работе системы защиты и должна быть ими обнаружена. Поэтому среди АЗ нельзя выделить одного агента координирующий всех агентов узла и все АЗ должны контролировать работоспособность друг друга. Таким образом, одно из требований к функциональности АЗ – это их периодический контроль над состоянием «коллег»

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

Остальных агентов на машине он проверит сам. Другая возможная проблема для системы защиты это подмена одного из её АЗ. Решение, как в случае агентов анализа, заключается в проверке электронной цифровой подписи АЗ, которую необходимо проводить вместе с проверкой работоспособности.

Для общения между хостами используется следующая схема: сначала агенты защиты выбирают своего представителя – агента, который будет отвечать за отправку и получение сообщений на определённый хост, и он шлёт приветственное сообщение. Агенты на другом хосте, получив это сообщение, выбирают своего представителя для связи, и он начинает взаимодействие с первым представителем. В обоих случаях представитель выбирается случайным образом или с учётом загруженности агентов в плане общения между хостами.

При сбоях в передаче сообщений процедура может повторяться и представитель хоста меняться. Именно работоспособность представителя на других хостах необходимо проверять.

Условимся, что АЗ с заданной периодичностью опрашивает подопечный компонент и оценивает типичность его работы коэффициентом отклонения (КО) со значением от нуля до ста (ноль – привычное поведение, сто – явное несанкционированное действие). Для оценки АЗ сравнивает текущее вычисленное значение с эталонным, которое было вычислено на одном из предыдущих шагов.

Так как эталонное значение меняется в ходе работы КПС, то оно и является динамическим эталоном компонента. Набор этих значений для КПС является динамическим эталоном всей КПС. Отклонение в функционировании, то есть увеличение КО, является подозрительным и требует оповещения системных администраторов.

Опасная активность определяется одним из следующих способов. Вопервых, каждый АЗ имеет полное представление о защищаемом компоненте и способен при выполнении всего одной операции «забить» тревогу и присвоить своему КО максимальное значение. Во-вторых, каждый АЗ содержит внутренний порог, превышение которого выглядит подозрительно. Стоит отметить, что величина порога подбирается опытным путём, но, увеличивая или уменьшая её, можно учитывать ценность защищаемого ресурса. Наконец, реализация как минимум одного АЗ на хосте должна работать на основании значений других АЗ, расположенных на хосте. Назовём такого агента – агентом защиты хоста (АЗХ).

АЗХ будет собирать значения КО остальных АЗ на хосте и проверять допустимо ли их отклонение (например, небольшое отклонение нескольких компонентов, скорее всего допустимо, но небольшое отклонение всех или сильное отклонение нескольких выглядит подозрительно, даже если по отдельности АЗ их «пропускают»). Таким образом, задача АЗХ – это анализ допустимости отклонения всех компонентов, работающих на машине. Для вычисления общего значения хорошо подходят меры центральной тенденции: арифметическое среднее, взвешенное среднее (возможно, с динамическим вычислением весов), винсоризованное среднее и др. До того как общее значение будет вычислено, могут быть применены эвристики к КО компонентов по отдельности. Например, проверка, что все КО не превышают заданный порог или N наибольших КО не превышают заданный порог. Так как общее значение КО вычисляется только на основании других КО, которые отображают отклонение от привычной работы и в которых уже отражена адаптация агентов, то для АЗХ адаптация не нужна.

На одном хосте может располагаться несколько АЗХ. При запуске каждый из них сообщает другим АЗ о своих намерениях и, если другие АЗ уже реализуют вариант работы на основании всех КО хоста (тоже являются АЗХ), они его просто игнорируют – не участвуют как в его вычислениях, так и не опрашивают его для получения своих значений. Друг для друга АЗХ невидимы или находятся в «чёрном списке». Получается, что на одном узле располагается несколько агентов, которые являются «сенсорами» для других, и как минимум один АЗХ, который эти значения обрабатывает для получения КО хоста. Известность о намерении АЗХ использовать значение КО других агентов исключит возможность образования рекурсивных ссылок, которые приведут к неконтролируемому росту КО узла. Блок-схема работы АЗ представлена на рис. 3.5. В зависимости от наличия ролей АЗ выполняет разные действия.

–  –  –

именно АЗПС оповещаются об этом через представителей. На рис. 3.6 представлена схема работы АЗ. Зелёным выделены агенты-представители, штриховые стрелки – проверка работоспособности, обычные – выбор представителя и сбор значений КО.

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

Заканчивая рассмотрение системы защиты на базе МАС, выделим ещё два класса вспомогательных агентов – агенты противодействия и агенты защиты.

Рассмотрим их и перейдём к примеру реализации АЗ, который покажет подходы для вычисления КО одного компонента.

3.4.4. Агент противодействия Цель агентов противодействия – организовать ответные действия на проведение несанкционированных операций. Конечно, часть из защитных действий реализуются и в агентах защиты. По большей части – это блокировка выполнения компонентом подозрительных действий, которая, несомненно, должна присутствовать в системе защиты. Более хитроумные защитные меры должны быть вынесены в отдельный класс агентов. Такие меры могут быть как защитными, так и атакующими. Например, в целях защиты можно фильтровать запросы с определённого диапазона адресов, а можно определить IP местоположение злоумышленника и попытаться призвать его к ответственности (уголовной или административной). Более «реальным» примером активного противодействия является запуск нового экземпляра АЗ в случае его отключения.

3.4.5. Агент обучения Агент обучения – это вспомогательный класс агентов, который используются другими агентами для получения новых сведений об уязвимостях, сигнатур для проверки, возможных схемах атаки и т.д. Агент обучения представляет собой общий интерфейс для обучения остальных агентов. Сам агент обучения может получать информацию от человека, использовать собственные алгоритмы обучения на основании данных, представленных в различных базах данных, или работать в связке с агентами защиты. Выявив атаку с помощью своего адаптированного механизма, агент защиты делится «знаниями» с агентом обучения, а тот в свою очередь с агентом анализа. Это позволит устранить проблему ещё на этапе анализа КПС.

3.4.6. Формальное описание МАС

Формализованное определение МАС выглядит следующим образом [8]:

MAS = (A, E, R, ORG, ACT, COM, EV), где MAS – многоагентная система; А – множество агентов; E – множество сред, в которых функционируют агенты; R – множество взаимодействий между агентами; ORG – множество базовых организационных структур; ACT – набор индивидуальных и совместимых действий агентов; COM – возможные коммуникативные действия; EV – стратегия эволюции.

Множество агентов состоит из следующих типов агентов:

1. агенты анализа – АА:

o агент анализа защищённости уровня хоста – ААУХ;

o агент анализа защищённости уровня компонента – ААУК;

2. агент настройки – АН;

3. агент защиты – АЗ:

o агент защиты программной системы – АЗПС;

o агент защиты хоста – АЗУХ;

o агент защиты компонента – АЗУК;

o агент-представитель (общение между хостами);

o агент-ревизор (проверка работоспособности других агентов защиты);

4. агент противодействия – АП;

5. агент обучения – АО.

Таким образом, А = {ААУХ, ААУК, АН, АЗПС, АЗУХ, АЗУК, агент представитель, агент-ревизор, АП, АО}. При этом роли агент-представитель и агент-ревизор совмещаются с одной из остальных ролей агентов защиты.

Каждая команда агентов преследует свои цели:

Таблица 3.1.

Цели агентов Агенты Цель Агент анализа Провести анализ среды и дождаться устранения проблемы.

Агент настройки Устранить проблему и подтвердить её отсутствие.

Агент защиты Обеспечить вычисление коэффициентов отклонений отдельных компонентов и всей среды в целом.

Обнаружить подозрительные действия.

Агент Устранить процесс осуществления противодействия несанкционированных действий, их источник и последствия.

Агент обучения Собрать, обработать и распространить данные для обучения.

E = {множество компонентов КПС, объединённых в общую компьютерную сеть}.

Для среды E можно выделить следующие свойства:

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

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

динамичная, так как меняется от внешних факторов;

–  –  –

R2 – отношения управления между АЗУХ и «подчинёнными» АЗУК;

R3 – отношения коммуникации между АА и АН для оповещения;

R4 – отношения кооперации между АН для устранения уязвимости;

R5 – отношения кооперации между всеми АЗ для выбора представителей;

R6 – отношения кооперации для проверки работоспособности АЗ на хосте;

R7 – отношения кооперации для проверки работоспособности представителей;

R8 – отношения кооперации между АЗ для организации защиты;

R9 – отношения коммуникации между АЗ и АП для оповещения;

R10 – отношения кооперации между АП для процесса противодействия;

R11 – отношения коммуникации между АА, АЗ и АО для процесса обучения.

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

В множество базовых организационных структур ORG входят:

1. Иерархия для поиска и устранения уязвимостей. В неё входят АА и АН.

Взаимодействие осуществляется за счёт отношений R1-R4 и представлено на рис.

3.4.

2. Сеть для общения между хостами, проверки работоспособности и обеспечения защиты. Она состоит из АЗ и АП. Взаимодействие осуществляется за счёт отношений R5-R10 и представлено на рис. 3.6.

3. Сеть для обучения. В неё входят АА, АЗ и АО. Связанное отношение R11 заключается в запросе АО данных у АЗ и предоставлении подготовленных для обучения данных агентам анализа и защиты.

Развитие МАС состоит в добавлении агентов на новые или неохваченные до этого компоненты КПС и в управлении ААУХ популяцией ААУК с целью снизить нагрузку на компонент. В этом и заключается стратегия эволюции EV.

Для взаимодействия агенты используют непрямой (косвенный) обмен сообщениями. Такой способ обеспечивает гибкость линий связи и позволяет быть МАС распределённой. Сообщения описываются с помощью одного из декларативных языков взаимодействия. Например, с помощью KQML или FIPA ACL. Для передачи сообщений в среде (по сети) они «оборачиваются» в протоколы нижнего уровня, такие как TCP/IP, HTTP и др. Таким образом, можно сказать, что.

Выделенные агенты в основном являются искусственными, хотя в качестве агента настройки может выступить и натуральный агент – компьютерный пользователь. Сложно разделить агентов на типы, которые являются строго виртуальными или строго материальными. Например, агент защиты может быть как программой, анализирующей запросы к базе данных, так и аппаратным решением для контроля движения в периметре. Аналогичным образом выглядит ситуация с разделением агентов на интеллектуальные и реактивные. Например, агент анализа, который проверяет по прошествии определённого времени открытые порты на машине, безусловно, является реактивным. Но агент анализа, работающий с пополняемой базой правил и сигнатур для выявления вирусов, является интеллектуальным. У каждого из агентов имеются цели и внутреннее состояние. При этом агенты не ищут выгоду, а работают в кооперации. Все они правдивы, т.е. передают истинную информацию, и благонамеренны, так как делают то, что от них требуются и избегают конфликтных ситуаций.

В качестве подходящих архитектур агентов можно выделить вертикальную архитектуру InteRRaP (рис. 3.7) и композиционную. InteRRaP интересна тем, что способна использовать реакцию поведенческого уровня и более сложные реакции с использованием локального и кооперативного планирования. Это позволит агенту в стандартных ситуациях реализовывать своё поведение без привлечения затрат на планирование. Композиционная архитектура «собирает» сложное поведение агентов из базовых компонентов, которые решают простые задачи.

Рис. 3.7. InteRRaP архитектура Это общие размышления относительно возможной реализации и функционирования агентов. При моделировании же будут использоваться реактивные и интеллектуальные виртуальные агенты, которые построены с помощью диаграмм состояний и языка Java. Можно сказать, что в агентах был реализован один из видов гибридных горизонтальных архитектур, так как все уровни агента связаны с уровнем восприятия и действий. Для организации взаимодействия использовались простые текстовые сообщения, формат JSON и общая память.

3.5. Оценка коэффициента отклонения SQL запроса 3.5.1. Оценка с использованием статистики Рассмотрим пример АЗ, который анализирует SQL запрос и оценивает его КО. Пусть агент защищает данные в базе только от угрозы нарушения целостности. Эту угрозу может реализовать инсайдер, т.е. злоумышленник, который скрывается за сотрудником компании. Получив на небольшой промежуток времени доступ к компьютеру сотрудника с большими правами, он может выполнить запрос от его имени, чтобы изменить записи в БД нужным ему образом. Например, изменить реквизиты компании, которые используют клиенты для оплаты своих счётов, или изменить размер счёта за полученную услугу.

Теоретически такую угрозу может реализовать и удалённый нарушитель, не имеющий физический доступ к компьютеру сотрудника. Для этого ему будет необходимо найти способ для выполнения SQL запроса (например, с помощью SQL-инъекций) и пару логин/пароль пользователя, от которого он будет выполнять запрос (возможно даже и обычного аккаунта «гостя»). Так как мы рассматриваем угрозу целостности данных, то в терминах SQL запроса – это в основном операция обновления данных (update). Однако также возможны случаи и с операциями удаления (delete) и вставки (insert). Например, в случае редактирования записей в промежуточной таблице, которая реализует связь многие ко многим.

Формально задача такая: имеется SQL запрос, КО которого необходимо вычислить.

Пусть SQL имеет следующие характеристики, которые можно использовать:

1. имя пользователя, который выполняет запрос;

2. дата и время запроса;

3. операция (обновление, удаление или вставка);

4. набор полей (столбцов), которые изменяются;

5. набор пар старое – новое значение.

Считаем, что имеется обучающая выборка, т.е. АЗ начинает анализировать запросы к тому моменту, когда система проработала некоторый период времени.

Как же можно анализировать запрос, чтобы получить его КО? Для анализа «привычности» и вычисления КО запроса применимы различные эвристики: связь между временем и типом операции, связь между типом операции и табличкой, связь между временем и табличкой и т.д. Их справедливость сильно зависит от контекста функционирования КПС и должна проверяться опытным путём.

Остановимся на наиболее общих, которые подойдут практически к любым системам, и покажем один из возможных подходов получения КО.

Первое что необходимо сделать – это отфильтровать обучающую выборку и оставить только те значения, которые связаны с текущим пользователем. Далее можно заметить то, что у нас имеется дата и время запроса. К конкретным датам, месяцам или годам привязываться сложно. А вот время запроса использовать можно. Большинство компаний имеет нормированный рабочий день с фиксированным промежутком его начала, когда сотрудник должен прийти на работу, и фиксированным периодом его окончания. Обычно имеется и перерыв на обед, промежуток которого либо строго регламентирован, либо выбирается лично сотрудником. Таким образом, для каждого сотрудника можно выделить «привычные» часы активности, в которые он осуществляет запросы. Для этого необходимо просто просуммировать количество запросов по каждому из 24 часов и разделить на общую сумму. Максимальное значение можно считать наиболее вероятным и оценивать отклонение от него.

Если имеется запрос пользователя в час Х, то КО будет равен:

Если пользователь работает примерно в одно и тоже время, то данный КО будет большим при его запросе в другой, новый промежуток времени. Если же работа пользователя связана со всеми промежутками дня равномерно (например, это может быть учётная запись, от которой работает служба), то при обращении в любой момент КО будет небольшим.

Второе, что можно использовать – это то, что по своей работе большинство пользователей связано с ограниченным количеством таблиц в базе. Т.е. каждый пользователь работает с ограниченным набором таблиц и попытка его обращения к таблице, не входящей в этот набор, выглядит подозрительно. Аналогичным образом, что и с часами работы пользователя определяется наиболее востребованная пользователем таблица и вероятность обращения к ней.

КО вычисляется как отклонение вероятности текущей таблицы от наибольшей:

Если пользователь действительно использует не все таблицы, то КО будет большим при обращении к новой таблице. Если же это не так, и пользователь оперирует данными во всех таблицах примерно одинаково, то КО будет минимальным при обращении к любой из них.

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

Злоумышленник в свою очередь, может писать запрос вручную (например, в случае SQL-инъекции) и включать туда менее типичные комбинации столбцов.

Это отклонение имеет смысл учесть. Для этого, как и в предыдущих случаях, необходимо найти вероятность наиболее популярной комбинации. Лучше это сделать заранее, так как число вариантов может быть высоко – оно равняется, где n число столбцов. Вычисление необходимо повторять через какое-то время (например, каждую ночь). Это обеспечит адаптацию.

КО получаемый по этой эвристике равен:

Таким образом, мы применили три эвристики: связь пользователя и времени запроса, связь пользователя и таблицы, связь таблицы и набора полей. Они могут быть использованы как по отдельности, например каждый из трёх АЗ реализует свой алгоритм вычисления КО. Тогда они все попадут в АЗХ, который использует их для вычисления общего КО хоста. Либо один АЗ может использовать все три и получать общее КО по своему компоненту как среднее значение. В данном случае адаптация к новым видам атак происходит автоматически, так как алгоритм вычисления КО не пытается определить вид атаки и её составляющие, а выявляет подозрительную активность, которая появляется независимо от механизмов реализации угрозы.

(а) (б) Рис. 3.8. Количество запросов пользователей по часам рабочего дня (а) и количество запросов к таблицам КПС (б) В качестве примера на графике (рис. 3.8а) отображено количество запросов пользователей КПС (по вертикали) в разные часы активности (по горизонтали).

Видно, что у каждого из пользователей есть рабочее «окно» и запросы, не попадающие в него, являются подозрительными. На графике (рис. 3.8б) отображено количество запросов пользователей КПС (по вертикали) к разным таблицам (по горизонтали). Видно, что каждый пользователь обладает «ролью» в КПС и определённым набором связанных таблиц. Запросы к другим таблицам являются подозрительными. Более сложные, скрытые связи может обнаружить и задействовать НС.

3.5.2. Оценка с использованием нейронных сетей Возможны и другие подходы для вычисления КО. Например, обучение нейронной сети для распознавания пользователей.

В последнее время НС стали широко использоваться в различных областях

– медицине, геологии, технике и др. Они используются для решения таких задач как прогнозирование и классификация. Интерес к НС определяется несколькими причинами. Во-первых, это огромные возможности по анализу сложных, возможно, нелинейных зависимостей. Во-вторых, это возможность работать с исходными данными большой размерности. Наконец, НС относительно просто использовать. Необходимо подготовить набор данных и обучить НС, используя один из стандартных алгоритмов. Конечно, разработчику необходимо иметь некоторые представления и предположения о том, как отбирать и подготавливать исходные данные, какую выбрать архитектуру сети, но требуемый уровень знаний гораздо скромнее, чем, например, при использовании традиционных методов статистики [96]. Можно выделить и другие особенности НС: устойчивость к шумам во входных данных, адаптивность к изменениям окружающей среды, потенциально высокое быстродействие за счёт использования параллельных вычислений.

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

НС состоят из одного входного слоя, одного выходного слоя и нескольких (возможно, и не одного) скрытых слоёв.

Для задачи классификации пользователя по запросу выделим следующие входные нейроны:

24 нейрона для указания часа запроса;

3 нейрона для типа операции (создать, обновить, удалить);

n нейронов для таблицы, к которой делается запрос;

m нейронов для описания столбцов, которые присутствуют в запросе.

Каждый из выделенных входных нейронов будет принимать единицу или ноль в зависимости от того, присутствует ли соответствующая характеристика в запросе, который необходимо классифицировать. Число нейронов n определяется как количество таблиц в БД, а число нейронов m – как сумма столбцов во всех таблицах. Выбранное количество нейронов позволит задать все характеристики запроса от пользователя: время запроса, тип операции, целевая таблица и её столбцы. Комбинация единиц на входах у соответствующих нейронов будет однозначно соответствовать этим характеристикам.

Чтобы иметь возможность применить один из алгоритмов обучения «с учителем», в качестве выходных сигналов будем использовать учётные записи пользователей, которым соответствует запрос. На этапе обучения сеть будет учиться распознавать пользователя по характеристикам запроса. На этапе вычисления КО для каждого из запросов будем получать вероятность того, что запрос принадлежит текущему пользователю. Если эта вероятность максимальна, то КО равен нулю.

Если же НС считает, что вероятнее всего запрос принадлежит кому-то из других пользователей, то будем определять КО так (формула верна и для первого случая):

,где вероятность наиболее вероятного пользователя;

вероятность текущего пользователя.

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

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

Основные выводы к третьей главе Определены понятия статического и динамического эталонов защищённости КПС. Проанализированы варианты их получения и использования, преимущества и недостатки.

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

Разработаны архитектура МАС для получения динамического эталона безопасности, состав агентов и алгоритмы их работы. Разработаны алгоритмы вычисления коэффициентов отклонения (КО) для SQL запросов с использованием накопленной статистики и с использованием нейронной сети.

4. РАЗРАБОТКА СРЕДСТВ СОЗДАНИЯ ЭТАЛОНОВ ДЛЯ ОЦЕНКИ

ЗАЩИЩЁННОСТИ КОРПОРАТИВНЫХ ПРОГРАММНЫХ СИСТЕМ

4.1. Разработка онтологии предметной области В данном разделе будет описана онтология, соответствующая подходу построения статических эталонов безопасности, а также построены схемыпримеры для реальных систем.

Для формального определения онтологий существуют различные языки. Их основная задача предоставить возможность для описания, как самих данных, так и метаданных. Опираясь на метаданные при интерпретации данных, машины могут более полно учитывать положение вещей в реальном мире. Это позволяет упростить машинную обработку данных и машинное обучение. Последнее время широкое распространение получили языки, основанные на Web-стандартах. Они используются для обмена данными по сети и большинство из них основано на формате XML. Но в отличие от XML в языках для описания онтологий присутствует семантика.

Основной проблемой использования разработанного представления для анализа и получения статического эталона КПС является отсутствие необходимого количества схем. Чтобы облегчить их создание и распространение для описания соответствующей онтологии, воспользуемся одним из языков, основанных на Web-стандартах. Эти языки имеют мощную выразительность и знакомы большинству ИТ-специалистов. Кроме того, данные языки разработаны для описания ресурсов, а КПС в нашем представлении и есть набор ресурсов – компонентов.

Консорциум всемирной паутины (W3C), начиная с 2004 года, рекомендует использовать язык OWL, который объединяет лучшее из своих предшественников и расширяет их (RDFS, RDF, XML). Используем данную (DAML+OIL, OIL) рекомендацию и остановимся на языке OWL. Язык OWL состоит из классов, свойств и ограничений. Так как OWL расширяет RDF и RDFS, то в нём присутствуют базовые элементы из этих языков.

OWL имеет несколько разновидностей – OWL Lite, OWL DL и OWL Full.

OWL Lite прежде всего используется для построения иерархий и указания простых ограничений. В текущей версии языка OWL (OWL 2.0) разновидность OWL Lite отсутствует. OWL DL расширяет версию Lite и вносит в него вычислительные механизмы, которые соответствуют дескрипционной логике.

Описательная или дескрипционная логика сочетает в себе богатые выразительные возможности и хорошие вычислительные свойства, такие как разрешимость и относительно невысокая вычислительная сложность основных логических проблем. OWL Full расширяет версию OWL DL и вносит неё высокую синтаксическую свободу, однако при этом теряются вычислительные гарантии.

Маловероятно, что какое-либо ПО будет в состоянии полностью поддержать каждую особенность OWL Full. Для описания онтологии наиболее подходит версия OWL DL, поэтому далее, говоря о языке OWL, будем иметь в виду OWL DL. Каждый элемент, используемый при создании онтологии, будет кратко описан.

Чтобы сократить рутинную работу по заданию XML разметки, было создано большое количество графических редакторов для определения онтологий на OWL. На первых этапах разработки онтологии использовалось средство Enterprise Architect, разработанное компанией Sparx Systems. Изначально оно разрабатывалось как редактор UML схем и хорошо поддерживает работу в графическом режиме. Бесплатный, триальный период использования позволил применить данной средство для создания онтологии. Впоследствии онтология стала усложняться, и потребовалось средство, специализирующееся на работе с языком OWL. Таким средством оказался кроссплатформенный редактор Protege, разработанный в Стэндфордском университете. Этот редактор является открытым и доступен бесплатно. Одно из его преимуществ – это поддержка OWL 2.0.

Как было описано ранее в представлении «прототип-реализация» имеются 4 класса:

1. «Хранилище информации» (ХИ) – WarehousePrototype 2. «Канал передачи информации» (КПИ) – LinkPrototype

3. Компонент, реализующий ХИ – WarehouseImplementation

4. Компонент, реализующий КПИ – LinkImplementation Первые два класса относятся к первому ярусу, последние два – ко второму.

Логичным является введение двух «надклассов»: «Прототип» (Prototype) и «Реализация» (Implementation), которые будут объединять в себе общие свойства классов по каждому из ярусов, и одного «надкласса»: «Элемент данных»

(DataObject), который будет объединять все элементы модели. Добавим в онтологию класс «Данные» (Data), «Угроза» (Threat) и «Уязвимость»

(Vulnerability). Таким образом, онтология будет содержать 10 именованных классов. Именованные классы – один из способов определения классов, который является наиболее простым и фундаментальным. Соответствующее описание классов на XML выглядит следующим образом:

owl:Class rdf:about="http://www.semanticweb.org/sec#Data"/ owl:Class rdf:about="http://www.semanticweb.org/sec#DataElement"/ owl:Class rdf:about="http://www.semanticweb.org/sec#Implementation" rdfs:subClassOf rdf:resource="http://www.semanticweb.org/sec#DataElement "//owl:Class owl:Class rdf:about="http://www.semanticweb.org/sec#LinkImplementation" rdfs:subClassOf rdf:resource="http://www.semanticweb.org/sec#Implementation"//owl:Class owl:Class rdf:about="http://www.semanticweb.org/sec#LinkPrototype" rdfs:subClassOf rdf:resource="http://www.semanticweb.org/sec#Prototype"/ /owl:Class owl:Class rdf:about="http://www.semanticweb.org/sec#Prototype" rdfs:subClassOf rdf:resource="http://www.semanticweb.org/sec#DataElement "//owl:Class owl:Class rdf:about="http://www.semanticweb.org/sec#Threat"/ owl:Class rdf:about="http://www.semanticweb.org/sec#Vulnerability"/ owl:Class rdf:about="http://www.semanticweb.org/sec#WarehouseImplementation" rdfs:subClassOf rdf:resource="http://www.semanticweb.org/sec#Implementation"//owl:Class owl:Class rdf:about="http://www.semanticweb.org/sec#WarehousePrototype" rdfs:subClassOf rdf:resource="http://www.semanticweb.org/sec#Prototype"/ /owl:Class Описание онтологии с помощью OWL строится на утверждении множества фактов-триплетов: («объект», «свойство», «субъект»). Такие факты говорят о том, что указанный объект обладает выбранным свойством, и значением свойства является субъект. Для описания триплетов используются различные нотации. На

XML данные триплеты определяются следующим образом:

”Элемент RDF” rdf:about=”Объект” ”Свойство 1” rdf:resource=”Субъект”/ ”Свойство 2” rdf:resource=”Субъект”/ ”Свойство 3” rdf:resource=”Субъект”/ /”Элемент RDF”

При определении были использованы:

rdf:RDF – элемент, определяющий начало RDF(OWL)-описания;

owl:Class – элемент, позволяющий ввести новый OWL класс;

rdf:about – свойство, указывающее на ресурс, свойства которого будут описаны;

rdfs:subClassOf – свойство, определяющее, что субъект является подклассом класса.

Для последующего добавления индивидов, принадлежащих к классам, понадобятся свойства. В языке OWL имеется два типа свойств: свойствахарактеристики (DatatypeProperty) и свойства-связи (ObjectProperty). Первые связывают классы с данными определённых типов, а вторые связывают классы друг с другом. На свойства могут быть наложены ограничения в виде доменом и диапазонов. Домены определяют классы, объекты которых могут обладать указанными свойствами. А диапазоны задают классы, объекты которых могут быть значениями указанных свойств. Добавим следующие свойствахарактеристики: «Характеристика данных» (DataCharacteristic) с доменом «Данные» и диапазоном положительные целые числа, «Ущерб» (Impact) с доменом «Уязвимости» и диапазоном положительные целые числа.

Уточним свойство «Характеристика данных» тремя подсвойствами для описания данных, от которых требуется доступность (DataAvailability), конфиденциальность и/или целостность (DataIntegrity); а «Ущерб» – (DataConfidentiality) подсвойствами для определения воздействия на эти характеристики данных:

ущерб доступности (ImpactAvailability), конфиденциальности (ImpactConfidentiality) и/или целостности (ImpactIntegrity).

Для связи классов будем использовать следующие свойства:

1. «Реализует» (Implement) и инверсное ему свойство «Реализуется»

(Implements by) для связи прототипов и их реализаций.

2. Транзитивное свойство «Содержит» (Contain) и инверсное ему свойство «Содержится» (Contains in) для связи элементов с дочерними. А также подсвойства «Содержит прототип» (Contain prototype) и «Содержит реализацию»

с соответствующими доменами, диапазонами и (Contain implementation) инверсными свойствами.

3. «Передаёт данные» (Send data to) и инверсное ему свойство «Получает данные из» (Receive data from) для обозначения обмена данными между элементами.

4. «Направлена на» (Directed at) для обозначения цели угрозы.

5. «Имеет уязвимость» (HasVulnerability) для связи уязвимостей и реализаций.

Инверсность свойства A свойству B означает, что если справедливо A(x,y), то справедливо и B(y,x). Транзитивность предполагает, что если справедливо A(x,y) и A(y,z), то справедливо и A(x,z). Домены и диапазоны добавленных свойств можно увидеть на рис.4.1 или найти в полном описании онтологии в приложении 2.

Рис. 4.1. Описание классов онтологии и их свойств в Erwin

В качестве примера на XML можно привести следующий участок описания:

owl:ObjectProperty rdf:about="http://www.semanticweb.org/sec#Contain" rdfs:range rdf:resource="http://www.semanticweb.org/sec#DataObject"/ rdfs:domain rdf:resource="http://www.semanticweb.org/sec#DataObject"/ /owl:ObjectProperty owl:ObjectProperty rdf:about="http://www.semanticweb.org/sec#Contains_in" owl:inverseOf rdf:resource="http://www.semanticweb.org/sec#Contain"/ /owl:ObjectProperty owl:DatatypeProperty rdf:about="http://www.semanticweb.org/sec#DataAvailability" rdfs:subPropertyOf rdf:resource="http://www.semanticweb.org/sec#DataCharacteristic"/ /owl:DatatypeProperty owl:DatatypeProperty rdf:about="http://www.semanticweb.org/sec#DataCharacteristic" rdfs:domain rdf:resource="http://www.semanticweb.org/sec#Data"/ rdfs:range rdf:resource="&xsd;nonNegativeInteger"/ /owl:DatatypeProperty Элемент owl:ObjectProperty вводит новое свойство-связь, owl:ObjectProperty

– свойство-характеристику, rdfs:domain и rdfs:range задают для них домены и диапазоны соответственно. В примере вводится свойство «Содержит» с доменом и диапазоном элемент данных, инверсное ему «Содержится в», свойство «Характеристика данных» и дочернее «Характеристика доступности».

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

Существуют и другие, локальные характеристики, например, ограничения на кардинальность или на диапазон внутри подкласса. Enterprise Architect не позволяет задать ряд необходимых свойств онтологии, поэтому дальше онтология разрабатывалась в Protg. Protg не только позволяет ввести ряд дополнительных ограничений, но и учитывает их при описании индивидов. Кроме того, в Protg встроен интерпретатор языка SPARQL, с помощью которого можно делать запросы к онтологии.

Одно из ограничений, которое можно использовать для описания эквивалентных классов, – это ограничение кардинальности или количества элементов связи. Например, для уточнения класса уязвимости, как уязвимости, несущей ущерб доступности данных, был создан класс «Уязвимость доступности» (AvailabilityVulnerability), эквивалентный классу, у которого есть хотя бы одно свойство ImpactAvailability. Аналогичным образом были определены классы «Уязвимость конфиденциальности»

(ConfidentialityVulnerability) и «Уязвимость целостности» (IntegrityVulnerability).

Стоит отметить отличие между использованием подкласса и эквивалентного класса. В первом случае выполняется необходимое условие для принадлежности к указанному классу, а во втором ещё и достаточности. То есть, если для индивида выполнено условие эквивалентности для какого-то класса, то он принадлежит этому классу. В нашем случае, если индивид уязвимости несёт ущерб доступности, то он также принадлежит к классу «уязвимость доступности».

Похожим образом данные можно уточнить тремя классами: данные, у которых заданы значения конфиденциальности, целостности и/или доступности, попадают в классы уязвимых по соответственному свойству: «Уязвимое по свойству конфиденциальности» (ConfidentialityVulnerableData), «Уязвимое по свойству целостности» (IntegrityVulnerableData), «Уязвимое по свойству конфиденциальности» (AvailabilityVulnerableData).

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

Класс угрозы доступности описывается следующим образом:

owl:Class rdf:about="&sec;AvailabilityThreat" owl:equivalentClassowl:Restriction owl:onProperty rdf:resource="&sec;Directed_at"/ owl:someValuesFrom rdf:resource="&sec;AvailabilityVulnerableData"/ /owl:Restriction/owl:equivalentClass rdfs:subClassOf rdf:resource="&sec;Threat"/ /owl:Class Элемент owl:equivalentClass начинает определение эквивалентного класса, owl:Restriction вводит ограничение, owl:onProperty указывает на какое свойство действует ограничение, owl:someValuesFrom требует как минимум наличия одной связи с AvailabilityVulnerableData, то есть с данными, доступность которых может пострадать при реализации угрозы. Таким образом, угроза на основании своей цели может попасть в один или несколько подклассов угроз.

После доработки онтологии в Protg она приняла следующий вид:

Рис. 4.2. Диаграмма классов онтологии и их связей в Protg На вкладках классов (рис. 4.3а), свойств-характеристик (рис. 4.3б) и свойств-связей (рис. 4.3в) можно увидеть определённые элементы онтологии.

–  –  –

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

Соответствующие утверждения в Protg описываются следующим образом:

Directed_at o Contains_inPrototype - Directed_atPrototype Directed_at_prototype o Implements_by- Directed_at_implementation Directed_at_prototype o Implements_by o Contain Implementation Directed_at_implementation Directed_at_implementation o HasVulnerability Запись вида X o Y - Z, означает, что если справедливо X(a,b) и Y(b,c), то справедливо и Z(a,c).

В случае направленности угрозы на прототип, условие описывается одной цепочкой, так как в её описание входит транзитивное свойство «Содержится в». И прототип, у которого заданы свойства данных, будет являться одновременно и «Данным» и «Прототипом», что позволит организовать транзитивную связь и найти дополнительные, целевые для угрозы, прототипы.

Ещё фактор, который необходимо учесть, – это пересылка данных. Если элемент схемы пересылает данные, то их будет содержать и тот элемент, который их получает, и его родительский. Таким образом, они будут также находиться под угрозой. Эти связи описываются так: Contain o Recieve_data_from - Contain и Recieve_data_from o Contain - Contain.

Введение цепочек свойств-связей позволит Protg выводить их автоматически. Рассмотрим, как будет работать онтология на примере. Для этого определим индивидов.

4.2. Описание используемых систем Для примера будем использовать архитектуру системы «Студент» и системы «Планирование учебного процесса» (ПЛУП), в разработке которых участвовал автор. Эти системы разработаны ИВЦ МЭИ – информационновычислительным центром Национального Исследовательского Университета Московского Энергетического Института, и служат для автоматизации деятельности ВУЗа.

Первая из них предназначена для информационного обеспечения большинства бизнес процессов, связанных с подготовкой специалистов в системе высшего образования. Система «Студент» поддерживает централизованное ведение справочников, поиск любых информационных объектов (персоны, студенты, сотрудники, приказы и т.д.) по любым критериям, гибкий режим разграничения полномочий между пользователями в зависимости от их должностных обязанностей и административной принадлежности, поддерживает ведение архива приказов, архива отчетных форм, хранение истории изменений всех информационных объектов. В системе осуществляется реальное движение контингента студентов посредством приказов. Любые изменения свойств студента осуществляются посредством ввода в действие приказа (перевод, изменение состояние, изменения свойств личности и т.д.). Предоставляется гибкий механизм настройки шаблонов приказов и маршрутов движения проектов приказов. В разработанном решении представлен мощный функционал по построению статистических отчётов на основе куба OLAP.

Система ПЛУП охватывает весь учебный процесс в части составления учебных планов, календарных графиков учебного процесса, планов теоретического обучения, семестровых учебных планов. Модуль предоставляет удобный инструментарий для создания графиков учебных процессов, учебных планов, в том числе планы теоретического обучения, семестровые учебные планы и планы индивидуального обучения. Весь процесс планирования учебного процесса сопровождается оперативным контролем на соответствие государственным стандартам. Разработанные в системе документы могут быть экспортированы в форматы WORD или Excel.По аналогии с системой «Студент»

предусмотрены ряд отчётов, однако для их построения не используется куб OLAP.

Система «Студент» реализована на платформе Microsoft Dynamics CRM.

Данная платформа состоит из «обёртки» над MS SQL Server, с помощью которой происходит взаимодействие пользователя с базой данных для просмотра и изменения данных. Взаимодействие осуществляется посредством Webинтерфейса поверх HTTP. HTTP-запросы обрабатывает MS Internet Information Services. Для реализации куба OLAP выбрана технология Analysis Services, входящая в состав MS SQL Server. Сами отчёты готовятся с помощью технологии Reporting Services, также входящей в состав MS SQL Server. Система функционирует на трёх серверах, которые работают под управлением Windows Server 2008 R2. Первый из них служит для обработки HTTP-запросов, второй поддерживает работу СУБД, и третий отвечает за процессинг куба OLAP.

Наиболее ценная информация (паспортные данные студентов) хранится в БД и на короткое время она может быть закэширована веб-сервером. Куб OLAP содержит обезличенную статистическую информацию (например, количество студентов из Москвы). Схемы, которые соответствуют такой архитектуре, можно увидеть на рис. 4.4. Получилось пять схем первого яруса и две схемы второго яруса. Как и в предыдущей главе, штриховые линии обозначают отношение «Содержит», а мелкие штриховые – отношение «Реализует».

Рис. 4.4. Пример схемы ХИ-КПИ для системы «Студент»

Для реализации системы ПЛУП использовались примерно те же технологии, за исключением платформы MS CRM Dynamics 2011. Работа с данными организована также через Web-интерфейс, однако его реализация полностью «самописная». Поэтому потребовалась разработка ряда дополнительных сервисов, таких как сервис чтения данных из Active Directory и сервис загрузки файлов на сервер с машины пользователя и наоборот, c сервера на машину пользователя. Для создания пользовательского веб-интерфейса используется Silverlight 5 вместе с WCF RIA Services. Вспомогательные сервисы реализованы так же с использованием технологии WCF. Решение работает на двух серверах: первый отвечает на HTTP-запросы пользователей, на втором функционирует MS SQL-Server. За уровень ОС отвечают системы Windows Server 2008 R2. Схемы ХИ-КПИ для ПЛУПа представлены на рис. 4.5.

Рис. 4.5. Пример схемы ХИ-КПИ для системы ПЛУП

4.3. Пример использования онтологии Для проверки возможностей онтологии, схемы рассматриваемых систем были введены в Protg. Таблице ПД было выставлено значение 100% для свойства конфиденциальность данных, данным куба OLAP – 100% целостность, веб-серверу – 100% доступность. Выставленное свойство означает важность сохранения указанного свойства в процентах. Рассматривались три возможных нарушения политики безопасности. Во-первых, это угроза конфиденциальности ПД студентов. Злоумышленник может пытаться захватить эти данные и воспользоваться ими в своих интересах. Таким образом, целью (с помощью свойства «Направлена на») для данной угрозы была выбрана таблица ПД, которая присутствует в обеих системах. Во-вторых, можно рассматривать как актуальную

– угрозу доступности веб-сервера. Если он на время будет выведен из строя, то это приведёт к определённым потерям. Например, к потере доверия пользователей и потере актуальности информации в БД. В данном случае свойство «Направлена на» было связано с прототипом веб-сервера. В-третьих, злоумышленник может нарушить целостность данных, содержащихся в кубе OLAP, для того чтобы отчёты, сгенерированные на их основе, были неверными.

После ввода исходных данных были проанализированы результаты работы «Рассуждателя», входящего в состав Protg. Его работа была возможна, так как для описания классов, их свойств и индивидов использовался язык OWL DL.

Первое что стало заметно – это то, что введённые угрозы были классифицированы и разделены на три класса: первая попала в класс угрозы конфиденциальности, вторая – угрозы доступности, третья – угроза целостности.

Угрозы были разделены на основании классов данных, на которые они направлены.

На примере угрозы нарушения доступности вывод строился следующим образом (рис.

4.6):

1. угроза направлена на таблицу с ПД студентов;

2. таблица ПД студентов имеет свойство-характеристику – «Конфиденциальность данных»;

3. к классу «Уязвимые к угрозам конфиденциальности» относятся те индивиды, у которых имеется как минимум одно свойство «Конфиденциальность данных»;

4. к классу «Угрозы конфиденциальности» относятся те индивиды, которые «Направлены на» индивидов, принадлежащих к классам «Уязвимые к угрозам конфиденциальности».

Рис. 4.6. Окно «объяснения» Protg

Второе, что удалось определить «Рассуждателю» – это потенциальные уязвимости, которые могут быть задействованы при реализации угрозы. Для примера было добавлено по три индивида для MS SQL Server и MS IIS, которые обладают подсвойствами «Ущерб», и таким образом попадают в класс уязвимостей. Перечень вычисленных отношений представлен на рис. 4.7. Для первой угрозы «Рассуждатель» определил все шесть уязвимостей как потенциальные для реализации угрозы, так как уязвимые данные могут оказаться как в СУБД, так и в кэше веб-сервера. Для второй (угрозы доступности вебсервера) могут быть задействованы только три уязвимости, которые напрямую направлены на веб-сервер. «Вывод» данных связей выглядит сложнее (рис. 4.8).

Он основан на определённых выше цепочках связей.

–  –  –

Рис. 4.8. Объяснение работы «Рассуждателя»

Однако при вычислении описанной связи UseVulnerability, соответствующей потенциальным для реализации угрозы уязвимостям, «Рассуждатель» не учитывает тот тип ущерба, который будет нанесён, и ту характеристику, которую следует оберегать. Учесть данную особенность позволяет встроенный в систему язык запросов к данным, Protg представленным в модели RDF – SPARQL. Это ещё одна из рекомендаций консорциума W3C, и поэтому он был использован как в Protg, так и в данном разделе. С помощью SPARQL можно сделать сложный запрос к информации, содержащейся в онтологии. Следующий запрос выведет список тех уязвимостей, которые могут быть использованы при реализации угроз, направленных на

SQLAnalysisServices:

SELECT DISTINCT ?a ?b ?dataProp ?dataValue ?e ?f ?i ?j WHERE { ?a :Directed_at ?b.

?dataProp rdfs:subPropertyOf :DataCharacteristic.

?b ?dataProp ?dataValue.

?b :Contains_inPrototype* ?c.

?c :Implements_by ?d.

?d :ContainImplemetation ?e.

?e rdfs:label ?label. filter (str(?label) = "SQLAnalysisServices").

Optional {?e :HasVulnerability ?f.

?f :ImpactIntegrity ?i}. } order by ?a Встроенный интерпретатор запросов SPARQL в Protg не позволяет использовать те свойства, которые были выведены «Рассуждателем». Поэтому запрос частично дублирует введённые ранее цепочки свойств-связей.

Теперь, если добавить в пример вторую возможную реализацию СУБД – MySQL, то можно выполнить сравнение двух компонентов реализации и выбрать менее уязвимый. Для такого сравнения в модель были добавлены пять уязвимостей для MySQL и три для MS SQL Server. Это те уязвимости сравниваемых СУБД, которые были выявлены за последний месяц (на дату проведения анализа). Информация об уязвимостях и величине ущерба конфиденциальности, целостности и доступности взята из OSVDB.

Для того чтобы «Рассуждатель» учитывал MySQL, как возможный вариант реализации СУБД, и имел возможность найти потенциальные уязвимости, была добавлена ещё одна связь «Содержит». «Рассуждатель» Protg вывел все пять уязвимостей. Теперь сравним рассматриваемые компоненты по возможному ущербу.

Следующий запрос отобразит все возможные значения подсвойств свойства «ущерб» для всех угроз, направленных на элементы представления:

SELECT DISTINCT ?a ?b ?c ?d ?e ?f ?i ?j WHERE { ?a :Directed_at ?b.

?b :Contains_inPrototype* ?c.

?c :Implements_by ?d.

?d :ContainImplemetation ?e.

Optional {?e :HasVulnerability ?f.

Optional { ?i rdfs:subPropertyOf :Impact.

?f ?i ?j }. }. } order by ?a

Результаты данного запроса выглядят следующим образом:

Рис. 4.9. Вероятный ущерб КПС Добавив фильтрацию и агрегацию результатов по сравниваемым компонентам, получим результаты, представленные на рис. 4.10. Видно, что вероятный ущерб при использовании MySQL в качестве СУБД выше, чем при использовании MS SQL Server, поэтому лучше остановить свой выбор на СУБД от Microsoft.

Рис. 4.10. Сумма вероятного ущерба по прототипу СУБД Так как потенциальный ущерб основывается на коэффициентах CVSS, то его сравнение с ценностью характеристик, которые могут быть нарушены, даст ответ на вопрос: стоит ли усиливать защиты или риск будет принят?

Автоматизировать этот процесс позволяет система ESSA, разработанная автором [9].

Для дальнейшего тестирования добавим индивидов, которые будут описывать систему ПЛУП. При этом схема всех индивидов в Protg примет следующий вид (рис. 4.11). Можно заметить, что на схеме первого яруса присутствуют похожие хранилища информации (ХИ) – сервера с БД, которые содержат ПД и взаимодействуют с веб-сервером. Признаками схожести являются попадание в одинаковые классы, содержание данных одинаковых классов, наличие одинаковых свойств-связей, описывающих пересылку данных. Конечно, признаков, по которым было выдвинуто предположение о схожести, не так много, но среди них присутствует как структура КПС, так и простые свойства. В данном контексте не говорится об идентичности ХИ, а лишь предполагается их схожесть.

На основании выдвинутого предположения делается вывод, что при подборе компонентов для реализации необходимо обратить внимание на то, как они представлены на схемах реализации второго яруса для схожих ХИ. В данном случае имеется один «схожий» ХИ – это ХИ со схемы системы «Студент».

Поэтому если бы стоял вопрос о компонентах для реализации сервера БД, то в первую очередь надо было бы рассмотреть Windows Server и SQL Server – то ПО, с помощью которого реализована система «Студент».

Разработанная онтология была использована для сравнения различных стеков технологий: LAMP (Linux, Apache, MySQL, PHP), WAMP (Windows, Apache, MySQL, PHP), WIMP (Windows, IIS, MySQL, PHP), WISA (Windows, IIS, SQL Server, ASP.NET), WISP (Windows, IIS, SQL Server, PHP). На дату проведения сравнения минимальные издержки обеспечивал стек WISA.

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

Чтобы эталон являлся не просто уже реализованным и используемым ПО, но и наименее эксплуатируемым злоумышленником, подключим к онтологии информацию об успешных атаках. Для этого добавим свойство «Количество эксплуатаций» (UseCount) для домена «Уязвимость». Оно позволит воспользоваться неявной связью уязвимостей и классов угроз, которая была описана в предыдущей главе. Значение этого свойства берётся из логов по функционированию ПО и отчётов СКБ. В тестовые данные были добавлены ещё несколько угроз, для которых Protg определил классы угроз. При этом часть угроз попали не в один класс, а в несколько. Для этого угрозы были направлены на разные данные с разными классами. На рис. 4.12 приведён пример запроса, с помощью которого получается сумма инцидентов по каждому из классов угроз.

Рис. 4.12. Сумма инцидентов по классам угроз Несомненно, эта информация полезна как для анализа рисков, так и для градации эталонов. Реализации, в которых было найдено и использовано большое количество ошибок, не являются эталонами.

Их можно назвать лишь «антиэталонами». Однако многие компании не захотят делиться информацией о внутренних инцидентах безопасности. Большое количество атак, пусть даже и не доведённых до успешного завершения, вполне вероятно, испугает клиентов компании, и она потеряет прибыль. С другой стороны мировые корпорации имеют большое число проектов, работающих на различном ПО. В этом случае данные о проблемах могут быть раскрыты и успешно использованы различными подразделениями одной компании.

Сбор информации об инцидентах безопасности и об ошибках в целом встроен во многое современное ПО. Например, в решениях компании Microsoft (MS Dynamics CRM, приложения для операционных систем Windows 8 и Windows Phone 8) имеется механизм по автоматической отсылке данных о проблеме на сервер. Это хороший источник данных для разработанного представления.

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

Реификация позволяет сделать утверждение об утверждении. С помощью вспомогательных классов можно определить, кто сделал утверждение, и проверить его надёжность.

Главная проблема и причина, которая замедляет и крайне усложняет дальнейшее изучение, разработку и использование статических эталонов, – это отсутствие набора схем ХИ/КПИ, который позволил бы проверить подход на большом наборе «тестовых данных». Чтобы повысить заинтересованность в схемах первого яруса, предлагается внести в них дополнительные возможности по описанию КПС согласно руководящим документам. Это удобно сделать, разработав новую онтологию, например, для определения класса ИС. Такая онтология будет состоять из класса «Категория» и четырёх возможных значений, свойства-связи КПС с категорией, свойства-характеристики «объём персональных данных» и из 4-х классов, к одному из которых будет отнесена ИС.

Для каждого из классов описываются элементарные условия эквивалентности.

Например, принадлежность к классу К4 эквивалентна связи с четвёртой категорией. Схема такой онтологии представлена на рис. 4.13. Подключив её к своему набору данных, пользователь получит возможность легко определять класс ИС.

Рис. 4.13. Пример онтологии для определения класса ИС Кроме того, построение схем второго яруса может быть автоматизировано.

Так как OWL – это язык, который «понятен» машинам, то реализация будет заключаться в опросе ПО, получении значений для свойств и компоновки XMLдокументов, описывающих индивидов. Что касается определения и использования новых функций, то это реализуется вводом новых классов и свойств, и, возможно, разработки их интерпретатора. Решение трудоёмко, но плюсы от его реализации могут оказаться большими. Ещё одно возможное направление для дальнейших исследований – это интеграция с другими существующими онтологиями. Например, в [97] определена онтология, которую можно использовать для более детальной классификации угроз.

Приведённые примеры показывают состоятельность идеи в целом и отображают возможности предлагаемого подхода. Однако отмечается, что для дальнейшего развития требуется большее количество схем. Описанное решение позволит изначально спроектировать КПС с учётом безопасности, что является важной частью разработки. Однако никак не учитывается сопровождение системы. Заложенную изначально безопасность нужно уметь поддерживать и расширять. Поэтому дальше рассматривается динамический эталон безопасности

– эталон, который учитывает изменения в ходе работы КПС.

4.4. Моделирование многоагентной системы защиты В предыдущей главе был предложен подход для организации защиты на базе МАС. Выделено пять классов агентов, которые должны входить в такую систему. Это агенты анализа, агенты настройки, агенты защиты (АЗ), агенты противодействия и агенты обучения. Наиболее интересными для настоящей работы являются АЗ, так как именно в ходе их работы получается динамический эталон безопасности одного компонента и КПС в целом. Такие агенты привязываются к компонентам КПС и оценивают коэффициент отклонения (КО) их работы. Каждый из агентов может использовать свой алгоритм для оценки КО и должен уметь его адаптировать. Команда АЗ вместе с агентами защиты хоста (АЗУХ) определяет общее отклонение в работе хоста, и предоставляет эту информацию агенту защиты программной системы (АЗПС), который, в конечном счёте, и оповещает о проблеме системного администратора.

Разработка с нуля МАС защиты полностью достаточно трудоёмка и выходит за рамки данной работы. Кроме того, перед разработкой требуется некоторый прототип, который подтверждает выдвинутые предположения.

Получить и оценить результаты работы такого прототипа можно с помощью моделирования. Поэтому постараемся показать, что предложенная концепция справедлива и действительно представляет ряд преимуществ при защите реальных систем на основании имитационного моделирования. Для этого сначала смоделируем поведение АЗ для оценки отклонения в работе моделей реальных систем, а затем реализуем рассмотренный ранее пример алгоритма для оценки КО одного из возможных компонентов КПС – СУБД.

Для моделирования воспользуемся программой AnyLogic. Это инструмент одной из ведущих компаний в области инструментов и бизнес-приложений имитационного моделирования – компании The AnyLogic Company. AnyLogic поддерживает различные подходы имитационного моделирования, среди которых присутствуют системная динамика, «процессное» дискретно-событийное и агентное моделирование. Последнее как раз и будет использовано в данном разделе. AnyLogic поддерживает описание поведения агентов на языке Java, а также с помощью вложенных диаграмм состояний, которые позволяют создавать агентов практически любой сложности. Также данный инструмент позволяет выносить ряд параметров на уровень пользовательского интерфейса и изменять ход событий на этапе «прогонки» модели. Для значений различных переменных имеется возможность построения сводных графиков, которые позволяют сравнивать и анализировать их значения на временном промежутке.

Для моделирования МАС будем использовать упрощённые варианты агентов и компонентов КПС. В анализе участвуют АЗ, агенты противодействия, а также агенты, моделирующие поведение обычного пользователя, злоумышленника и компонента – агент-пользователь, агент-злоумышленник и агент-компонент соответственно.

Для начала рассмотрим логику работы отдельных агентов. Наиболее простая часть модели – это агенты-пользователи. Их поведение достаточно примитивно. Они обращаются к компонентам с запросами, которые необходимо обработать, и тем самым имитируют нормальное поведение КПС. Обращение происходит с определённой вероятностью, которая вынесена в параметр каждого экземпляра агента, и моделируются отправкой сообщения связанным ресурсам.

Все связи задаются на уровне модели. В случае получения ответа на запрос, агент-пользователь переходит в промежуточное состояние «Успешный ответ» и через один шаг переходит в состояние «Ожидание», из которого запрос может быть повторён. В случае отсутствия ответа от компонента, пользователь переходит в состояние «Нет ответа» по таймауту (5 шагов) и далее в состояние «Ожидание» (1 шаг). Диаграмма состояний этого класса агентов приведена на рис. 4.14.

Стрелки с «таймером» обозначают переход по прошествии заданного промежутка времени, стрелки с «конвертом» – переход при получении сообщений от других агентов, ромб – проверка выполнения условия, стрелки с надписями – переход при выполнении определённого условия. Стоит отметить, что проектирование агентов заключалось как в создании диаграммы состояний, так и в описании действий при переходах на языке Java. Поэтому возможно перемещение из одного состояния в другое по двум разным переходам, но с разными действиями.

Рис. 4.14. Диаграмма состояний агента-пользователя Следующая часть модели – команда агентов атаки, которая состоит их агентов-злоумышленников. Так как для работы АЗ необходимо наличие некоторого периода обучения, в течение которого они накапливают статистику о привычном состоянии компонентов, то агенты атаки начинают свою работу с задержкой. Величина этой задержки зависит от параметра (WaitTime)

MinWaitTime:

Функция random() выдаёт случайное значение от 0 до 1. Параметр MinWaitTime задаётся на уровне модели для каждого из агентов атаки по отдельности. После окончания задержки агент переходит в состояние «Wait», случайным образом выбирает атакуемый компонент и симулирует атаку, отсылая соответствующий запрос. Логика вероятности успеха или провала атаки вынесена в агент-компонент, так как, независимо от результата, сам факт атаки должен существовать. Повторное нападение осуществляется с определённой интенсивностью (параметр Intensity). Логика работы проста и представлена на рис. 4.15.

Рис. 4.15. Диаграмма состояний агента атаки Для моделирования произвольных компонентов КПС был спроектирован агент-компонент. Этот агент имеет достаточно сложный механизм работы, диаграмма состояний которого представлена на рис. 4.16.

Рис. 4.16. Диаграмма состояний агента-компонента Будем считать, что каждый агент-компонент имеет две характеристики.

Первая характеристика – текущая нагрузка на компонент. Она увеличивается любым из агентов при взаимодействии и через некоторое время возвращается к своему значению по умолчанию – нулю. При получении сообщения, в случае если нагрузка не превышает ста процентов, запрос обрабатывается. Если же нагрузка максимальна (сто процентов), то компонент переходит в состояние «перегружен»

и не обрабатывает полученный запрос. После трёх шагов модели нагрузка компонента начинает снижаться. Получив запрос от пользователя, компонент обрабатывает этот запрос за один шаг. В случае если текущему компоненту (например, веб-серверу) необходим запрос к другим компонентам (например, к СУБД), то он выполняет эти запросы и ожидает ответа. Обработав запрос, компонент отвечает пользователю сообщением «ResponseOK».

Вторая характеристика – это степень защищённости компонента от атак нарушителя. Для краткости условимся называть это характеристику «барьер».

Значение барьера уменьшается при запросах от агента-злоумышленника. Для моделирования результата нападения используется параметр «AttackProb». Он задаёт вероятность, с которой происходит успешная атака. Только в случае успешной атаки значение барьера понижается. Если агент атаки осуществляет успешный запрос-нападение к компоненту, у которого отсутствует барьер (имеет нулевое значение), будем считать, что этот компонент скомпрометирован.

Компрометация — факт доступа постороннего лица к защищаемой информации.

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

Кратко модель можно описать так: агенты-пользователи обращаются к компонентам и моделируют нормальное поведение КПС. При этом изменяется характеристика, отвечающая за нагрузку компонента. Агент-злоумышленник «выжидает» и начинает атаку компонентов, уменьшая барьер. Когда барьер «снят», злоумышленники получают конфиденциальные данные компонента и используют захваченный компонент для атаки следующего. Разработанные компоненты были добавлены в модель и между ними заданы связи (рис. 4.17). Так как определение связей между агентами и их параметры при реализации были вынесены в параметры агента, то это позволило легко моделировать различные связи между компонентами, между пользователями и компонентами, а также между злоумышленниками и компонентами.

Рис. 4.17. Моделирование системы «Студент»

В модель были добавлены агенты-пользователи, агенты-злоумышленники и график, который отображает нагрузку рассматриваемых компонентов. В ходе проверки моделировалось различное количество пользователей (от 3 до 5), различные вероятности генерации запроса (от 0,1 до 0,9), разное время ожидания злоумышленника (от 5 до 100), разная интенсивность (от 5 до 10) и разная вероятность успеха атаки (от 0,1 до 0,9).

В зависимости от выбранных значений получались разные результаты, которые можно разделить на две группы:

Агенты-пользователи перегружали атакуемые компоненты до начала атаки злоумышленником. При этом атака злоумышленника всё равно приводила к успеху через некоторое время, так как часть его запросов (как и запросов пользователей) обрабатывалась.

Агенты-пользователи не перегружали атакуемые компоненты и спокойно работали. Агент атаки после нападения повышал нагрузку атакуемого компонента в зависимости от выбранной интенсивности. Как и в первом случае, независимо от того перегружался компонент или нет, злоумышленник через некоторое время «сокрушал» барьер.

В реальном мире архитектура компонентов, их возможности и количество подбираются так, чтобы пользователи могли нормально работать с системой, то есть получать ответы на все свои запросы без задержек. Таким образом, первую группу результатов можно считать ошибочной с точки зрения подбора исходных параметров. Пример графика для второй группы представлен на рис. 4.17 (правый верхний угол). На нём отчётливо видно, что, начиная с трёхсотого шага, а именно столько ожидает злоумышленник, повышается нагрузка на компонент IIS1. При этом нагрузка на полностью аналогичный компонент IIS2 не изменяется. Таким образом, в данной модели нагрузка – это та характеристика, которая подходит для получения КО. То есть цель агентов защиты заключается в том, чтобы получить высокий КО до того, как злоумышленник получит доступ к конфиденциальным данным.

В ходе моделирования испытывались разные алгоритмы работы АЗ для вычисления КО нагрузки компонентов. Были попытки определить среднюю загрузку и считать отклонение от неё. При этом средняя нагрузка определялась как за весь период работы, так и за небольшой, недавний промежуток.

Отклонение при этом высчитывалось в процентах от средней нагрузки. Этот подход оказался неэффективным. Другой метод, который также не привёл к положительным результатам, – это вычисление среднеквадратичного отклонения нагрузки. После неудач по анализу значений нагрузки похожие методы определения КО были применены к размерам разрывов между снимаемыми показаниями. В данном случае было большое количество ложных срабатываний.

Наконец, был найден способ, который успешно определял продолжительное увеличение нагрузки, и пропускал небольшие изменения, вероятные для привычной работы. Заключается данный подход в анализе величины угла между двумя прямыми. Для этого АЗ снимает N показаний нагрузки. Вычисление угла происходит на каждое N-ое снятие.

По снятым показаниям получается 3 точки:

(x1,y1), (x2,y2) и (x3,y3). Здесь x1 – это время первого снятия, y1 – его значение, x2 – усреднённое время N снятий, y2 – усреднённое значение N снятий, x3 – время последнего снятия, y3 –значение. Под временем понимается условное время в модели AnyLogic, которое представляет собой рациональное число. Для значений y1, y2 и y3 испытывались и другие значения – различные усреднения снятых показаний. Описанные выше значения дали наибольшее количество верных срабатываний. Для полученных трёх точек строятся две прямые, каждая из которых описывается уравнением по точке и угловому коэффициенту. Первая прямая проходит через первую и вторую точку, вторая – через вторую и третью.

По угловым коэффициентам вычисляется тангенс угла между прямыми, а по нему и сам угол:

, где, Данный подход несколько «запаздывает», так как при анализе N значений угол определяется для N/2 снятия. Однако он даёт минимальное количество ложных срабатываний, что является проблемой для других подходов.

Адаптивность заключается в работе на основании N недавно снятых значений.

Описанный подход был реализован в окончательной версии АЗ. Дополнительным признаком, который требовал постороннего вмешательства, стало предельное значение нагрузки (равное 100). Независимо от значения КО при такой нагрузке оповещается агент противодействия. На рис. 4.18а представлена диаграмма состояний АЗ, а на 4.20б – код для анализа КО на языке Java, который срабатывает при переходе из состояния «CheckState» в состояние «HandleState».

(а) (б) Рис. 4.18. Диаграмма состояний АЗ (а) и анализ КО (б) Алгоритм работы АЗ также подразумевает, что он может быть атакован как и любой компонент. При успешной атаке (её вероятность задаётся параметром «AttackProb») АЗ выходит из строя и прекращает собирать показания защищаемого компонента. Как было описано в третьей главе, агенты защиты контролируют работу друг друга и, в случае обнаружения поломки, оповещают агента противодействия. Данные проверки были реализованы на Java.

Наконец, был реализован и добавлен в модель агент противодействия, которого, в случае обнаружения атаки, оповещал АЗ. После получения оповещения, агент противодействия обнаруживал нападающего агента атаки и переводил его в состояние «BeforeAttack», то есть завершал атаку. Стоит отметить, что злоумышленник через заданное время снова выбирал случайную цель и начинал её атаку. Если проблема заключалась в неработающем АЗ, то он переводился в состояние «Repair» и вскоре возвращался в строй. В случае если нагрузка на компонент была 100, то агент противодействия «перезагружал»

компонент и устанавливал нагрузку в 0. Также в модель был добавлен АЗПС, который собирал значения от АЗ, определял максимальное и среднее значение и выводил их на условный экран администратора.

Один из прогонов модели представлен на рис. 4.19. Имеется два нарушителя, которые с задержкой 600 и 700 шагов начинают атаковать КПС. Их выбор падает на компоненты IIS1 и IIS2 соответственно. После атаки нагрузка на эти компоненты возрастает: синяя и красная линия на правом графике отображают соответствующие изменения. Агенты защиты Defender2 и Defender3 успешно определяют подозрительную активность для защищаемых компонентов.

На левом графике – это скачки функций KO2 и KO3 соответственно. Видно, что скачок (срабатывание АЗ) отстаёт от начала атаки агентом-злоумышленником.

Значения КО повышаются лишь через 100-150 шагов. Это связано с описанным выше алгоритмом их работы и интенсивностью, с которой АЗ опрашивают компоненты. Наличие в снятых показаниях не только значений нагрузки, но и времени замера позволяет более точно определить период начала атаки. Плюсом является и то, что АЗ оповещает о подозрительных действиях до того как нагрузка достигает своего максимального значения. Потенциальный результат такого повышения – это отказ в обслуживании части запросов, что может являться конечной целью атакующего.

Однако есть и минус, который состоит в том, что задержка может быть критичной, т.е. компонент и его данные могут быть скомпрометированы до определения атаки АЗ. Это видно из того, что для атакуемых компонентов значение барьера снижено. Определив атаку (примерно 700 и 800-ый шаги для IIS1 и IIS2 соответственно), АЗ сообщили об этом агенту противодействия (Opposition1) и тот «обнулил» цели агентов-злоумышленников, тем самым завершив их атаку. При этом нагрузка на компонент прекратила повышаться и постепенно стала возвращаться к своим значениям до атаки. Соответствующие изменения отображены на правом графике – значения функций IIS1 Loading и IIS2 Loading уменьшаются. Стоит отметить, что при снижении нагрузки АЗ также отмечали подозрительную активность. Это последствия работы агента противодействия и падения нагрузки. Чтобы исключить ложные срабатывания, АЗ был модифицирован для анализа только увеличения нагрузки. АЗПС справлялся со своей задачей и успешно получал значения КО от АЗ. Результат его работы отображён на левом графике. Это серая линия, которая отображает среднее значение (Av.KO), и чёрная, которая отображает максимальное КО (Max.

KO). Видно, что последовательная атака IIS1 и IIS2, которая может быть интерпретирована как атака, состоящая из нескольких шагов, вызывает повышение как среднего, так и максимального значений КО. Это отмечает АЗПС (SystemDefender).

Рис. 4.19. Пример эксперимента Моделирование проводилось для 1-6 агентов атаки. При этом был определён порог для КО, равный 60, как наиболее эффективный для правильной работы АЗ. АЗПС использовался только как монитор, собирающий общие значения, и вся защита работала в автоматическом режиме без вмешательства человека. Во всех случаях АЗ успешно определяли атакующих, однако те успевали нанести небольшой ущерб. За счёт чего постепенно «барьер», отделявший злоумышленников от конфиденциальных данных, исчезал. Однако стоит заметить, что агенты защиты и противодействия ничего не знают про барьер и никак его не используют. В своей работе они полагаются на нагрузку компонента, и их можно считать агентами, которые отражают атаки, направленные на перегрузку компонента. С таким типом атак они неплохо справились. Это показывает, что АЗ эффективно определяют КО для угрозы нарушения доступности и неэффективно для угрозы нарушения конфиденциальности. Количество случаев, когда была необходима перезагрузка компонента на 100000 шагов модели, приведено в таблице 4.1 (запрос пользователя обрабатывается за 3-4 шага в зависимости от маршрута, по которому он пойдёт, а агент атаки выбирает новую цель примерно каждые 300 шагов и атакует её каждые 5 шагов).

Таблица 4.1.

Результаты моделирования Всего Предупреждений от Злоумышленников Ложных Перезагрузок атак АЗ 4 707 698 - 6 5 886 843 - 9 6 1076 984 - 16 Ложные срабатывания определялись как разница между общим количеством атак и количеством предупреждений от АЗ. И начиная с 4-х атакующих, такой подход стал давать неверные результаты, так как на одну обнаруженную атаку агент противодействия мог устранять более одного злоумышленника. Цели агентов атаки могли пересекаться.

Результаты показывают, что успехом завершалось малое количество атак – не больше 2%. Скорее всего, это происходило, когда планы злоумышленников совпадали, то есть они одновременно атаковали один компонент или компонент и его защитника. Для подтверждения данной гипотезы были проведены дополнительные тесты. Они показали, что для повышения вероятности успешной атаки до 5% необходимо как минимум два злоумышленника, которые будут атаковать одну цель. Атака АЗ не приносит пользы, так как он быстро возвращается в строй. При этом времена проведения атаки должны коррелировать так, чтобы АЗ несколько раз подряд успевал обнаружить первого атакующего и не успевал обнаруживать второго, и быть так подобраны, чтобы компонент не успевал сбрасывать нагрузку, полученную от атак. До того как атака завершится успехом, АЗ несколько раз обнаружит злоумышленников. При этом если агент противодействия будет принимать более серьёзные меры защиты, например, каждый раз увеличивать MinWaitTime на 5%, то успех атаки снизится до 2%. Таким образом, можно сделать вывод, что для успешного нападения требуется кооперация агентов-злоумышленников и планирование атаки. Чтобы атака не была обнаружена, необходимо «обмануть» АЗ. Это сложно, так как злоумышленник не знает ни о его существовании, ни алгоритмов его работы.

Другой возможный и благоприятный для нас вариант действий агента атаки – это отказ от своей цели.

Одним из допущений модели является то, что злоумышленник обнаруживается по нагрузке на компонент. Но он может скрываться за обычным пользователем и не вызывать изменения нагрузки. Поэтому очень важно выбрать правильный набор характеристик для подсчёта КО. АЗ были модифицированы, чтобы определять КО на основании изменения размера барьера (угроза нарушения конфиденциальности), а также на основании феромонта (любая другая угроза) – сообщения, которое оставляли злоумышленники АЗ, выдавая себя.

Результаты этих испытаний были аналогичны предыдущим и показали, что успешная работа МАС во многом зависит от КО, используемым каждым из АЗ.

При моделировании МАС время обработки компонентом пользовательского запроса определялось опытным путём на основании времени обработки реальных ответов. В ходе моделирования действий злоумышленников среди серверов, обслуживающих запросы к системе «Студент», был выявлен сервер, который первым «откажет» в случае атаки. Для подтверждения возможных проблем была проведена DDoS атака на фронтэнд-сервера с использованием программного средства HULK. В атаке участвовали 3000 виртуальных пользователей.

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

(а) (б) Рис. 4.20. Результаты DDoS атаки на сервер приложений (а) и сервер отчётов (б) На рисунке 4.20 приведены два графика, на которых отображены нагрузка на процессор (мелкая пунктирная линия) атакуемых серверов, общее количество запросов (крупная пунктирная линия) и количество запросов, которые они не успели обработать (жирная линия). Как и в случае моделирования первым из строя выходил сервер построения отчётов (рис. 4.20в). Результаты объяснялись тем, что сервер отчётов имеет технические характеристики, которые слабее, чем у сервера приложений, и рассчитан на менее активную работу пользователей.

Совпадение результатов моделирования и реальной атаки подтверждает состоятельность разработанной модели МАС и необходимость защиты КПС на основе динамических эталонов безопасности.

Модель показывает, что МАС способна решать поставленную задачу – обнаруживать отклонения в работе КПС. Можно сделать вывод, что защита на базе МАС действительно даёт ряд преимуществ с учётом того, что каждый из АЗ умеет правильно выделить характеристики для вычисления КО. Распределение агентов по компонентам КПС снижает нагрузку на защищаемую систему.

Архитектура гибкая, так как разные АЗ могут защищать один компонент от разных угроз, и устойчивая к атакам, так как вывод из строя АЗ быстро обнаруживается и устраняется. За счёт возможности ввода новых агентов для охвата новых компонентов КПС достигается масштабируемость решения.

Реализовать атаку, состоящую из нескольких шагов, на КПС действительно сложнее, так как она должна обходить несколько АЗ, которые в свою очередь будут отмечать повышение КО, что приведёт к оповещению системного администратора через АЗПС. Злоумышленник должен либо обмануть АЗ, либо «убрать» его. «Убрать» его затруднительно, поэтому предполагаемые действия злоумышленника – обман агента. Теперь реализуем и проанализируем описанные в предыдущей главе алгоритмы оценки КО для АЗ СУБД от угрозы нарушения целостности.

4.5. Реализация алгоритма оценки КО для SQL запроса 4.5.1. Реализация с использованием статистики В предыдущей главе был приведён пример подхода, который может применяться для анализа отклонения SQL-запросов. В качестве неправомерного действия, на которое должен реагировать АЗ, была выбрана угроза нарушения целостности БД.

В качестве защищаемой БД была использована база системы ПЛУП. И так как данная система использует СУБД SQL Server, то и реализация алгоритма оценки тесно связана с этой СУБД и той версией языка SQL, которую она поддерживает. С учётом этого задача состояла в определении КО SQL запроса к СУБД SQL Server. Рассматривалось подмножество языка запросов SQL – Data Manipulation Language (DML) – язык управления (манипулирования) данными.

Это подмножество состоит из четырёх операторов манипуляции: SELECT (считывание данных), INSERT (добавление данных), UPDATE (обновление данных) и DELETE (удаление данных). Нарушить целостность можно с помощью одного из трёх операторов: INSERT, UPDATE, DELETE. Чтобы реализовать предложенные методы, необходимо собирать статистику по выполнению этих операций. Таким образом, в рамках подготовки был реализован механизм сбора необходимой для агента защиты информации. Для сбора данных использовался триггер – обработчик событий вставки, обновления и удаления данных.

Динамический SQL код позволил реализовать хранимую процедуру для массового создания триггеров на все таблицы защищаемой БД. Дополнительно была разработана процедура для быстрого отключения всех триггеров.

Полученное решение позволяет обработать любое обращение к данным и разобрать запрос на составные части, которые попадут в специальную таблицу «Audit». Для уменьшения связности и роста объёма основной БД, эта таблица размешается в отдельной БД на том же экземпляре SQL Server. Таблица «Audit»

состоит из следующих полей: идентификатор записи (Id); тип операции (Type);

имя таблицы (TableName); идентификатор изменяемой записи (PK (первичный ключ)); имя изменяемого поля (FieldName); старое значение (OldValue); новое значение (NewValue); дата изменения (UpdateDate); имя пользователя (UserName).

Хотя не все поля участвуют в механизме вычисления КО (например, старое и новое значения), в таблице аудита они представлены, так как это может быть полезно для детального разбора инцидента. Объём таблицы на момент проведения экспериментов – 260 тысяч записей (рис. 4.21).

–  –  –

Разработанная функция на языке SQL выглядит следующим образом:

CREATE FUNCTION [dbo].[KO1] (@userName nvarchar(200), @hour int) RETURNS int AS BEGIN declare @maxprobHour float, @probHour float, @allQueruesCount int;

-- Общее количество запросов SELECT @allQueruesCount = count(*) FROM [CM2011_log].[dbo].[Audit] where UserName = @userName

-- Максимальная вероятность SELECT top 1 @maxprobHour = round(cast(count(*) as float) / @allQueruesCount,5) FROM [CM2011_log].[dbo].[Audit] where UserName = @userName group by DATEPART(hh, UpdateDate) order by round(cast(count(*) as float) / @allQueruesCount,5) desc

-- Вероятность часа SELECT @probHour = round(cast(count(*) as float) / @allQueruesCount,5) FROM [CM2011_log].[dbo].[Audit] where UserName = @userName and DATEPART(hh, UpdateDate) = @hour

-- Коэффициент отклонения return (@maxprobHour - @probHour)*100 END Вторая эвристика – это предположение о том, что каждый пользователь по большей части связан с ограниченным набором таблиц, и его обращение к таблицам, не входящим в этот набор, является подозрительным отклонением. В этом случае КО вычисляется как:

, где вероятность наиболее используемой таблицы;

вероятность обращения к таблице из запроса.

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

Последнее предположение для вычисления КО заключается в том, что при любом запросе пользователь использует интерфейс, заготовленный разработчиком, а злоумышленник способен этот интерфейс обойти. В первом случае запрос формируется автоматически, а во втором изменяемые поля вводятся вручную. Предполагается, что отклонение можно обнаружить в наборе полей таблицы в запросе.

, где

– вероятность наиболее «популярного» набора полей;

вероятность текущего набора полей.

Так как количество всех комбинаций полей в таблице может быть высоко, то в данном случае лучше определить вероятности наборов заранее. Для вычисления всех комбинаций столбцов в осуществлённых запросах была реализована хранимая процедура. Данная процедура запускается по расписанию и заполняет вспомогательную таблицу, в которой содержатся вероятности всех наборов для каждой из таблиц. Набор столбцов хранится строкой, в которой упорядоченные названия всех столбцов соединены разделителем. На момент разработки в базе аудита содержалось 260 строк, которые описывали 60 тысяч запросов. База ПЛУПа состояла из 95 таблиц. С помощью разработанной процедуры вспомогательная таблицы была заполнена 262 вариантами возможных сочетаний полей в запросе и их вероятностями (рис. 4.22). Сочетания, которые не попали в неё, имеют нулевую вероятность. По аналогии с двумя предыдущими способами оценки КО третья эвристика была реализована в виде функции.

Рис. 4.22. Пример расчёта вероятности наборов колонок в запросе В итоге получилось три функции для оценки КО. Первые две служат для вычисления КО по одной записи из таблицы аудита. Третья применяется ко всему запросу, то есть к агрегации нескольких записей из таблицы аудита. На этапе тестирования были оценены недавние запросы.

Рис. 4.23. Пример расчёта и, На рис. 4.23 представлен результат работы двух запросов. Первый использует и, а второй –. Видно, что имеются как небольшие значения КО (0;6), так и более высокие (30;39).

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

Для оценки текущих запросов к БД и симуляции работы АЗ в триггер, который разбирает запросы и формирует таблицу аудита, была добавлена функциональность по запуску функций для оценки КО и вывода в Windows Event Viewer информации о подозрительных запросах. В данном случае Event Viewer сыграл роль АЗПС, то есть монитора, на который попадали сообщения от АЗ (рис.

4.24). С помощью оператора xp_logevent в лог выводились ИД тех запросов, у которых КО превышало 50 по одной из эвристик. Если значение попадало в промежуток от 50 до 75, то сообщение было предупреждением, а если выше 75 – ошибкой.

Рис. 4.24. Windows Event Viewer Event Viewer периодически анализировался, и проверялось наличие предупреждений или ошибок от АЗ. Наличие идентификатора запроса в составе данных от АЗ позволяло углубиться в поиск причины отклонения. Часть срабатываний-предупреждений были ложными. Для их уменьшения порог срабатывания был увеличен. Анализ оценки КО агентом защиты позволил определить два вида злоупотреблений, часть из которых действительно привела к нарушению целостности БД.

Во-первых, часть разработчиков вручную исправляли значения записей.

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

Например, при задании диапазона с помощью минимального и максимального значений, очевидно, что минимальное должно быть меньше максимального. Или обязательные поля при создании новых записей. Например, наличие заполненных полей серия и номер для новой строки паспорта. Редактирование записей напрямую таких проверок не содержало. Данные нарушения помог выявить третий способ расчёта КО. При вставке значений через пользовательский интерфейс запрос содержал как минимум все обязательные поля (обязательные на уровне веб-приложения), а при прямом запросе к БД набор полей был произвольным.

Второе, что было обнаружено – это подозрительные запросы от выделенной учётной записи, которая использовалась для репликации (синхронизации содержимого из других БД). Оказалось, что некоторые из разработчиков использовали данную учётную запись для исправления данных, на которые у них не хватало прав. Превышение порога показывало как КО на основе привычного времени работы, так и КО на основе набора таблиц. Учётная запись для репликации работала ночью и синхронизировала значения ряда таблиц, а разработчики от её имени днём обращались к другим таблицам. Ошибка в повышенных правах учётной записи для репликации была устранена.

Полученные результаты доказывают применимость предложенных эвристик для работы АЗ и оценки КО. Подход может быть модифицирован и применён для прочих АЗ, наблюдающих за другими типами компонентов КПС.

4.5.2. Реализация с использованием нейронной сети Для поиска наиболее подходящей архитектуры НС и её реализации будем использовать пакет STATISTICA Neural Networks, который предоставляет обширные нейросетевые методы анализа данных. Он входит в программный продукт STATISTICA, который разрабатывает компания StatSoft. STATISTICA Neural Networks имеет механизмы, упрощающие перебор различных нейросетевых архитектур, функций активаций и ошибок, и возможность генерации исходного кода для одного из языков высокого уровня.

Первое, что необходимо сделать для поиска подходящей архитектуры НС это подготовить набор данных обучения. Для этого была создана вспомогательная таблица «TrainNS», которая заполнялась данными на основании таблицы «Audit».

Каждая запись таблицы «TrainNS» содержала час запроса, его тип, имя пользователя, целевую таблицу и набор столбцов, которые присутствовали в запросе. Всего получилось порядка 60 тыс. записей.

Так как обучение на таком количестве исходных данных занимало достаточно продолжительное время (порядка 30 минут), то для поиска архитектуры НС была использована подвыборка, состоящая из 1400 записей и семи пользователей, по 200 запросов на каждого из пользователей. В обучающей подвыборке была задействована 31 таблица, 145 столбцов и 8 часов для запросов пользователей. Вместе с 3 нейронами, отвечающими за тип операции, получилось 187 входных нейронов. Так как количество возможных пользователей равнялось семи, то и выходных нейронов было семь.

Весь набор исходных данных разбивался на три части. Первая, наиболее объёмная часть (70%), – обучающая. Она использовалась для обучения НС.

Вторая часть (15%) – тестовая. Использовалась для проверки работы сети в процессе обучения. И, наконец, третья (15%) – контрольная, служила для окончательной проверки обученной НС.

Для проверки различных архитектур НС использовался пакет STATISTICA Automated Neural Networks. С его помощью были проверены многослойный персептрон с одним скрытым слоем и cети типа радиальной базисной функции. В качестве функции ошибки использовалась квадратичная функция ошибок и кроссэнтропия. Как на скрытом слое, так и на выходном, пробовались следующие функции активации: тождественная, логистическая, гиперболическая, экспоненциальная и синус-функция. Для обучения использовался стандартный для пакета алгоритм Бройдена-Флетчера-Гольдфарба-Шанно STATISTICA (BFGS).

Для НС типа радиальной базисной функции изначально использовался скрытый слой с 20 нейронами, и их значение увеличивалось с шагом 5 до 120. В результате ни одна из обученных сетей не классифицировала более чем 20% записей из контрольной выборки. Аналогичным образом проверялся и многослойный персептрон, однако результат был намного лучше. Уже для 4 нейронов на скрытом слое успешно классифицировать удавалось до 85% записей.



Pages:   || 2 | 3 |
Похожие работы:

«ВВЕДЕНИЕ 1. Филологическая герменевтика как деятельность Герменевтика это деятельность человека или коллектива при понимании или интерпретации текста или того, что может трактоваться как текст. Герменевтика именно деятельность, а не наука, но по герменевтике возможны и даже необходимы научные разработки. С этой точки зре...»

«ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО РЫБОЛОВСТВУ ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ МУРМАНСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ СБОРНИК...»

«Известия ТулГУ. Технические науки. 2013. Вып. 11 УДК 616.8-073.7:004.9 ПРИМЕНЕНИЕ ТЕХНОЛОГИИ РЕГИСТРАЦИИ ВЫЗВАННЫХ ПОТЕНЦИАЛОВ В РАЗРАБОТКЕ НЕЙРОИНТЕРФЕЙСА А.В. Томашвили В статье идет речь о применении технологии регистрации вызванных потенциалов в разра...»

«ПОЯСНИТЕЛЬНАЯ ЗАПИСКА. Рабочая программа по русскому языку ориентирована на обучающихся 9 класса и составлена на основании следующих нормативных документов:1. Федеральный компонент государственного обр...»

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИИ Федеральное государственное автономное образовательное учреждение высшего образования ЮЖНЫЙ ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ Институт математики, механики и компь...»

«ISSN 2075-6836 УЧРЕЖДЕНИЕ РОССИЙСКОЙ АКАДЕМИИ НАУК ИНСТИТУТ КОСМИЧЕСКИХ ИССЛЕДОВАНИЙ РАН ВТОРАЯ ВСЕРОССИЙСКАЯ НАУЧНО-ТЕХНИЧЕСКАЯ КОНФЕРЕНЦИЯ СОВРЕМЕННЫЕ ПРОБЛЕМЫ ОРИЕНТАЦИИ И НАВИГАЦИИ КОСМИЧЕСКИХ АППАРАТОВ СБОРНИК ТРУДОВ 13–16 СЕНтябРя 2010 г., РОССИя, тАРУСА, ПОД РЕДАКЦИЕЙ Г. А. АВАНЕСОВА МЕХАНИКА, УПРАВЛЕНИЕ И...»

«ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ НАЦИОНАЛЬНЫЙ ГО С Т Р СТАНДАРТ МЭК 6 07 9 3 -1 -3 4 РОССИЙСКОЙ ФЕДЕРАЦИИ ВОЛОКНА ОПТИЧЕСКИЕ Ч а с т ь 1-34 Методы измерений и проведение испытаний. Собственный изгиб волокна (IEC 60793...»

«КАССАНДРА М комплекс радиомониторинга и анализа сигналов Руководство по эксплуатации КАССАНДРА М Руководство по эксплуатации 1 Содержание: Наименование Стр. Введение 1. Описание и работа 2 1.1. Назначение 2 1.2. Технические характеристики 2 1.3. Состав 3 1.4. У...»

«ГОСУДАРСТВЕННАЯ КОРПОРАЦИЯ ПО АТОМНОЙ ЭНЕРГИИ "РОСАТОМ" САМОРЕГУЛИРУЕМАЯ ОРГАНИЗАЦИЯ НЕКОММЕРЧЕСКОЕ ПАРТНЕРСТВО "ОБЪЕДИНЕНИЕ ОРГАНИЗАЦИЙ ВЫПОЛНЯЮЩИХ СТРОИТЕЛЬСТВО, РЕКОНСТРУКЦИЮ И КАПИТАЛЬНЫЙ РЕМОНТ ОБЪЕКТОВ АТОМНОЙ ОТРАСЛИ "СОЮЗАТОМСТРОЙ" Утвержд...»

«Паспорт безопасности Соответствует Правилам ЕЭС №1907/2006 (REACH), Прил.II 1. ИДЕНТИФИКАЦИЯ ВЕЩЕСТВА/ПРЕПАРАТА И КОМПАНИИ/ПРЕДПРИНИМАТЕЛЯ. Распознавание вещества или препарат...»

«Нагимуллин Рамиль Ханифович ИСТОРИЯ ВОЗНИКНОВЕНИЯ КРУПНЫХ ХИМИЧЕСКИХ ПРЕДПРИЯТИЙ НА ВОСТОКЕ РОССИИ (на примере Уфимского химического завода) Специальности: 07.00.10 – История науки и техники 02.00.13 – Нефтехимия АВТОРЕФЕРАТ диссертации на соискание ученой степени кандидата те...»

«Федеральное государственное автономное образовательное учреждение высшего профессионального образования "Московский физико-технический институт (государственный университет)" Мемристор. Изготовление структуры и исследование ее свойств. Лабораторный практикум для 5 курса ФФКЭ МФТИ Долгопрудный 2013 ОГЛАВЛЕНИЕ 1. Введение 2. Физические при...»

«1 ФГБОУ ВПО "Омский государственный технический университет" РАЗДЕЛ II НЕПРЕРЫВНЫЕ ЛИНЕЙНЫЕ СИСТЕМЫ АВТОМАТИЧЕСКОГО УПРАВЛЕНИЯ Лекция 6.2 КРИТЕРИЙ УСТОЙЧИВОСТИ НАЙКВИСТА. ОПРЕДЕЛЕНИЕ УСТОЙЧИВОСТИ ПО ЛОГАРИФМИЧЕСКИМ ЧАСТОТНЫМ ХАРАКТЕРИСТИКАМ (2 ч) ФГБОУ ВПО "Омский государственный технический университет"Учеб...»

«Франтишек ГАДАШ Иржи ВИСКОЧИЛ ЛУК И СТРЕЛА Сокращенный перевод с чешского А. К. КОШЕЛЕВА Государственное издательство ФИЗКУЛЬТУРА и СПОРТ. Москва 1960 ПРЕДИСЛОВИЕ Стрельба из лука является прекрасным средс...»

«Вестник КрасГАУ. 20 15. №7 ПОЧВОВЕДЕНИЕ УДК 631.46+631.51+631.8 А.В. Щур, Д.В. Виноградов, В.П. Валько ЦЕЛЛЮЛОЗОЛИТИЧЕСКАЯ АКТИВНОСТЬ ПОЧВ ПРИ РАЗЛИЧНЫХ УРОВНЯХ АГРОТЕХНИЧЕСКОГО ВОЗДЕЙСТВИЯ В статье рассмотрены вопросы изменения целлюлозолитической активности почв под влиянием...»

«ФИЗИЧЕСКИЕ ОСНОВЫ ПРИБОРОСТРОЕНИЯ ISSN: 2225-4293 2014. Том 3. № 4 К 90-летию Алексея Георгиевича Свешникова 19 ноября 2014 года исполнилось 90 лет со дня рождения известного ученого, заслуженного деятеля науки РСФСР, лауреата Государственной премии СССР, лауреата Ломоносовской премии МГУ за педагогическую деятельность, ака...»

«АЛГОРИТМ ФОРМИРОВАНИЯ ВХОДНОГО ОБРАЗА ПРИ ПРОГНОЗИРОВАНИИ ПОКАЗАТЕЛЕЙ РИСКОВ ДЛЯ СЛОЖНЫХ ТЕХНИЧЕСКИХ СИСТЕМ В.Е. Белоусов, заведующий кафедрой, к.т.н., доцент, Нгуен Вьет Туан, аспирант, Воронежский государственный архитектурностроительный университет, г. Воронеж А.В. Кочегаров, профессор, д.т.н., доцент, Воронежский...»

«Руководство по передовым практикам Энергоэффективность и Возобновляемые источники энергии Финансовая часть Техническая часть Данное руководство подготовлено при финансовой поддержке Европейского Союза. Изложенные здесь взгляды принадлежат авторам данного руководства, но никоим образом не претендуют на отраже...»

«ОТКРЫТОЕ АКЦИОНЕРНОЕ ОБЩЕСТВО "ГАЗПРОМ" Технологическая связь ПРАВИЛА ТЕХНИЧЕСКОЙ ЭКСПЛУАТАЦИИ ТЕХНОЛОГИЧЕСКИХ Стандарт организации СЕТЕЙ ПОДВИЖНОЙ РАДИОСВЯЗИ СТО Газпром 11-014-2011 ИЗДАНИЕ ОФИЦИАЛЬНОЕ Москва 2012.indd 2-3 25.01.2012 8:26:15 ОТКРЫТОЕ АКЦИОНЕРНОЕ ОБЩЕСТВО "ГАЗПРОМ" СТАНДАРТ ОРГАНИЗАЦИИ Технологическая связь ПРАВИЛА ТЕХН...»

«ОД "Чистая Луга" Докладная записка по реализации проекта строительства котельных на альтернативном топливе "Топал-1" в Лужском районе. Инновационный проект или очередной необоснованный рас...»

«Curriculum viatae Степан Ткачев, к.ф.-м.н. Настоящее место работы Институт прикладной математики им.М.В.Келдыша РАН, г.Москва, научный сотрудник Московский физико-технический институт (МФТИ), г.Долгупрудный, доцент кафедры теоретической механики (0.5 ставки) Обл...»

«СПРАВКА о материально-техническом обеспечении образовательной деятельности по заявленным для лицензирования видам и уровням образования Муниципальное бюджетное общеобразовательное учреждение "Бехтеевская средняя общеобразовател...»

«УДК 338.46:[373.5+378](470+571)(082.1) ББК 74.5я43+65.497.4(2Рос)-551я43 А64 Руководитель авторского коллектива и научный редактор О. П. Молчанова А в т о р ы: Введение: О. П. Молчанова, А. М. Шестоперов Раздел 1: А. Я. Лившин, И. В. Логунцова, О. П. Молчанова, В. В. Солодов, А. С. Царенко, А. М. Шестоперов Ра...»

«Министерство образования и науки Российской Федерации Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования "Уфимский государственный авиационный технический университет" ПСИХОЛОГИЯ ЭФФЕКТИВНОГО ОБЩЕНИЯ Семинарские занятия Уфа 2014 ...»

«Маршрут " Моя родина – Россия. От родного Белогорья – к святыням Отчизны" Наш город образован в 1647 г. по указу царя Алексея Михайловича Романова (годы жизни 1629-1676, годы правления 1645-1676) и назывался Царев-Алексеев. Возглавил строительство города князь Василий Петрович Львов, под руководством французского инж...»








 
2017 www.doc.knigi-x.ru - «Бесплатная электронная библиотека - различные документы»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.