Автоматизированная информационная система производства нефтяного оборудования

 

МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ИМ. М.В. ЛОМОНОСОВА

ФАКУЛЬТЕТ ВЫЧИСЛИТЕЛЬНОЙ МАТЕМАТИКИ И КИБЕРНЕТИКИ

КАФЕДРА АВТОМАТИЗАЦИИ СИСТЕМ ВЫЧИСЛИТЕЛЬНЫХ КОМПЛЕКСОВ









Дипломная работа

Автоматическое построение профилей нормального поведения веб-приложений



Студента группы 522 факультета ВМиК

Гамбарова Эльдара Рафаиловича

Научные руководители:

д. ф. - м. н. профессор Смелянский Р.Л., Петухов А.А.






МОСКВА, 2007

Аннотация


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

Содержание


1. Введение

2. Постановка задачи

3. Определения и основные понятия

4 Метод обнаружения уязвимостей веб-приложений

4.1 Применение метода

4.2 Описание метода

4.3 Использование значений операций для более точного обнаружения отклонений в поведении

4.4 Отклонения в поведении с точки зрения метода

4.5 Сравнение наборов HTTP-параметров

5. Выбор методов обнаружения аномалий

5.1 Метод Хотеллинга (тест Хотеллинга)

5.2 Метод EWMA (Exponentially Weighted Moving Average)

5.3 Метод цепей Маркова

5.4 Нейросетевой метод

5.5 Сравнительный анализ методов обнаружения аномалий и обоснование выбора метода

6. Модуль обнаружения уязвимостей

6.1 Требования к модулю

6.2 Структура профиля нормального поведения

6.2.1 Секция мета-информации

6.2.2 Секция HTTP-параметров

6.2.3 Секция информации об операциях над объектами окружения

6.2.4 Пример записи профиля нормального поведения

6.3 Программная архитектура модуля

6.4 Описание подсистем модуля

6.4.1 Консоль управления

6.4.2 Подсистема предварительной обработки трассы

6.4.3 Подсистема построения профиля нормального поведения

6.4.4 Подсистема обнаружения аномалий

7. Результаты

8. Заключение

9. Литература

1. Введение


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

Проблема безопасности данных в информационной системе возникла с появлением самих систем. По мере внедрения компьютерных систем управления в важных для общества областях деятельности проблема приобретает всё большую значимость. Рост доступности пользовательских сервисов информационных систем через Интернет и локальные сети порождает новые проблемы, связанные с обеспечением безопасности (т.е., доступности, целостности и конфиденциальности [15]) данных от вторжений извне.

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

Предоставление удалённого доступа к информации, заказу и оплате услуг и ряду других сервисов в подавляющем большинстве случаев происходит через веб-приложения. Под веб-приложением понимается приложение, работающее в составе веб-сервера. Веб-приложение взаимодействует с пользователями через веб-интерфейс, представляющий собой совокупность интерактивных веб-страниц, доступ к которым осуществляется через веб-браузер пользователя. Доля уязвимостей веб-приложений в общем количестве фиксируемых уязвимостей значительна (около 69% в период с января по июнь 2006-го года) [16], а большое количество доступных удалённо веб-серверов и работающих на них веб-приложений создаёт благодатную почву для злоумышленников [1, 2, 3].

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

Под поведением далее будет пониматься взаимодействие веб-приложения с объектами окружения (ресурсы операционной системы, СУБД, почтовые сервисы) в ответ на HTTP-запросы от клиента.

Слабая защищённость и широкая распространённость веб-приложений делает их привлекательными целями для взломщиков. Существующие системы обеспечения безопасности часто неэффективны при защите приложений данного класса [2]. Можно перечислить следующие основные виды систем, используемых для обеспечения безопасности веб-приложения [3, 12, 14, 17]:

Модули обеспечения безопасности, встроенные в приложение

"Стратегия песочницы" (sandboxing)

Системы обнаружения уязвимостей

Межсетевые экраны уровня приложения

Системы предотвращения атак

Системы обнаружения атак

Как упоминалось выше, разработчики веб-приложений не всегда уделяют достаточно внимания обеспечению безопасности, и модули обеспечения безопасности в веб-приложениях встречаются редко [2].

Суть "стратегии песочницы" (sandboxing) заключается в создании контролируемой среды исполнения веб-приложения, изолированной от системы, в котором она работает. Это позволяет минимизировать потери в случае, если уязвимость приложения будет использована злоумышленником, но не позволяет обнаружить и локализовать сами уязвимости [11].

Системы обнаружения уязвимостей анализируют веб-приложения, используя метод белого или чёрного ящика [12, 13, 14, 19]. Система, использующая метод белого ящика, анализирует исходные коды и/или файлы конфигурации веб-приложения. Система выявляет участки кода, потенциально содержащие уязвимость или небезопасные параметры конфигурации [12]. Система, использующая метод чёрного ящика, осуществляет поиск уязвимостей "извне", посылая приложению HTTP-запросы и анализируя ответы. При этом встают задачи выявления структуры веб-приложения, определения типа сервера и построения тестового набора HTTP-запросов и последующего анализа HTTP-ответов [14]. Однако анализа исходного кода приложения может быть недостаточно для выявления всех уязвимостей, так как код может не содержать уязвимых с точки зрения языка конструкций и при этом быть уязвимым в целом из-за ошибок при проектировании. Кроме того, для той технологии, при помощи которой создано данное веб-приложение, может не оказаться систем поиска уязвимостей, использующих метод белого ящика. Анализ безопасности методом чёрного ящика также не может выявить все возможные уязвимости, так как нет гарантии, что множество тестовых запросов содержит все необходимые для этого варианты.

Межсетевые экраны уровня приложения обеспечивают безопасность веб-приложений, анализируя HTTP-запросы от клиента и HTTP-ответы приложения [18]. При этом производится поиск аномалий с точки зрения протокола (несовпадение контрольных сумм, неверная структура заголовка и т.д.), совпадения с известными сигнатурами атак или отклонения текущей модели трафика от нормальной. Однако при этом внимание уделяется запросам и ответам, но не поведению веб-приложения, чего не всегда достаточно для обнаружения уязвимости самого приложения [19].

Системы предотвращения атак не распространены широко [3]. Для их корректной настройки и работы требуется глубокое понимание особенностей функционирования как веб-приложения, так и самой системы предотвращения атак. Неверное конфигурирование может привести к большому количеству ложных срабатываний системы и, как следствие, недоступности сервиса для пользователей, что крайне нежелательно для многих сервисов [3, 19].

Системы обнаружения атак (СОА) используют методы, которые принято относить к двум основным категориям: методы обнаружения злоупотреблений (сигнатурные методы) и методы обнаружения аномалий [6].

Методы обнаружения злоупотреблений используют сигнатуры известных атак. Основным их минусом является неспособность обнаруживать новые или неизвестные виды атак. Этот минус существенно снижает применимость СОА, основанных на сигнатурных методах [3]. Веб-приложения часто имеют специфичную для данного сервиса функциональность, что делает сигнатуры атак, созданные для одного приложения, практически неприменимыми для другого [3].

Методы обнаружения аномалий используют определённый заранее профиль нормального поведения системы и анализируют текущее поведение системы на предмет отклонения от профиля. Методы данной группы хорошо справляются с обнаружением новых или неизвестных атак. Эта особенность делает их предпочтительными для реализации в СОА и других средствах обеспечения безопасности для веб-приложений [1, 7].

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

Логичное решение о включении подсистемы обнаружения аномалий в сам веб-сервер хорошо тем, что позволяет анализировать запрос на разных стадиях его обработки. Минусом является существенное снижение производительности веб-сервера, что неприемлемо для серверов с высокой нагрузкой. Кроме того, не каждый веб-сервер позволяет включать дополнительные модули [2].

Обнаружение аномалий может быть использовано при обработке параметров, поступающих в веб-приложение. Например, некоторая характеристика (статистическое распределение символов, длина строки и т.п.) в значениях параметров, извлекаемых из журналов аудита веб-сервера, обрабатывается математической моделью и обнаруженное отклонение проверяется относительно некоторого порогового значения [2]. Решения такого рода предназначены для выявления аномалий в поступающих данных, так как логично предположить, что злоумышленник будет отсылать веб-приложению нестандартные данные. Но при этом анализируются поступающие параметры, но не поведение самого веб-приложения.

Другим подходом является выявление аномалий в обращениях веб-приложений к объектам окружения (операционная система, СУБД и т.п.). Например, для веб-приложения строятся профили, содержащие типичную синтаксическую структуру запросов к БД, и последующие запросы проверяются на соответствие профилям [3]. Решения такого рода хороши тем, что в определённом смысле они анализируют поведение самого приложения. Но такие методы фокусируются на взаимодействии приложения с конкретными видами объектов окружения (например, СУБД) и не учитывают взаимодействие с другими объектами, а уязвимость в веб-приложении, обычно обращающемуся к одному ресурсу, может привести к несанкционированному доступу именно к другим ресурсам. Например, если некоторый модуль веб-приложения в процессе работы производит только системные вызовы операционной системы для работы с файлами, но при этом содержит уязвимость, позволяющую злоумышленнику запускать произвольный код, то результатом может стать модификация таблицы базы данных, содержащей пароли пользователей, с целью получения доступа - то есть обращение к другому ресурсу и порча информации. Комплексное решение, анализирующее обращения веб-приложения к разным объектам окружения является достаточно сложной технической задачей, так как встаёт вопрос о получении необходимой для анализа информации об обращениях, что, например, может потребовать модификацию программных компонент объектов [3].

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

Метод был реализован в виде модуля к СОА "Мониторинг-РВС". Как было отмечено, анализ обращений к различным объектам окружения является сложной технической задачей, а для успешной реализации СОА должна предоставлять необходимый инструментарий. Развитая инфраструктура СОА "Мониторинг-РВС" позволяет решать поставленную задачу [9].

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

Для этого необходимо рассмотреть существующие методы автоматического построения профилей нормального поведения, определить критерии сравнения методов и выбрать оптимальный для дальнейшей реализации. Модуль осуществляет обнаружение уязвимостей путём выявления обращений к тем ресурсам, которые не указаны в профиле нормального поведения, в ответ на HTTP-запросы. Однако аномалии в поведении могут быть связаны и с характером обращения к разрешённому профилем ресурсу, например, уязвимость может позволить злоумышленнику выбрать не одну строку из БД, а все. В основе метода автоматического построения профиля нормального поведения лежит некоторая математическая модель, и именно она определяет набор хранимых в профиле данных и анализ на предмет отклонения текущего поведения от описанного в профиле. Таким образом, выбирается оптимальный для данной задачи математический аппарат обнаружения аномалий и формат профилей изменяется таким образом, чтобы он позволял хранить данные, необходимые для анализа. Далее в модуль добавляется функция "обучения", которая позволит автоматически строить профиль нормального поведения и заносить в него данные по окончанию учебного периода.

Результатом работы является модуль обнаружения уязвимостей веб-приложений для СОА "Мониторинг-РВС" на основе контроля поведения с возможностью ручного и автоматического определения профиля нормального поведения.

приложение профиль нормальное поведение

2. Постановка задачи


Провести обзор методов автоматического построения профиля нормального поведения веб-приложения.

Сформулировать требования к методу, провести сравнительный анализ и выбрать один метод.

Реализовать выбранный метод в рамках разрабатываемого модуля.

Провести испытания на действующих веб-приложениях.

3. Определения и основные понятия


В данном разделе определяются основные понятия и термины, используемые в данной работе.

Ключевыми понятиями являются веб-приложение и поведение веб-приложения.

Под веб-приложением понимается приложение, с которым пользователь взаимодействует при помощи браузера. Само приложение при этом работает в составе веб-сервера и осуществляет взаимодействие с пользователем путём получения HTTP-запросов от браузера пользователя (ввод) и генерации веб-страниц (вывод) [17].

Объект окружения - это любая внешняя по отношению к веб-приложению сущность, предоставляющая набор операций, которые могут быть осуществлены веб-приложением над данным объектом окружения. В качестве примеров объектов окружения могут быть приведены ресурсы операционной системы, почтовый сервис, СУБД.

Операция - любое действие, которое может быть осуществлено над объектом окружения веб-приложением. Например, для объекта окружения "СУБД" операциями являются операторы языка SQL, для объекта окружения "почтовый сервис" - функции отправки сообщений.

Значение операции - это отображение результатов операции во множество вещественных чисел. Семантика отображения определяется для каждой конкретной операции. Например, для операций "SELECT" или "INSERT" объекта окружения "СУБД" значением данных операций может являться количество затронутых строк в базе данных; для операций "чтение из файла" или "запись в файл" объекта окружения "ресурсы операционной системы" значением операции может являться количество прочитанных или записанных байт соответственно. Очевидно, не для каждой операции значение операции может быть иметь смысл. Например, для операции "выбор базы данных" объекта окружения "СУБД". В этом случае в качестве значения операции может быть выбрана некоторая константа.

Логическая схема веб-сервера представлена на рисунке 3.1.


Рисунок 3.1 Логическая схема веб-сервера


В схеме, изображённой на рисунке 3.1:

Веб-сервер - приложение, выполняющее функции веб-сервера, например, Apache HTTP Server или Microsoft Internet Information Services (IIS).

Технология поддержки веб-приложения - набор программных компонент, формирующих среду для выполнения веб-приложений, созданных при помощи данной технологии. В качестве примера можно привести такие распространённые технологии, как PHP и ASP.net.

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

В общем случае, взаимодействие пользователя с веб-приложением происходит по следующей схеме [17, 22]:

В браузере пользователя происходит некоторое событие, порождающее HTTP-запрос к веб-приложению - таковым может являться переход по ссылке, нажатие на кнопку отправки данных формы на сервер, срабатывание скрипта на стороне клиента и т.п.

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

В сформированной запущенными компонентами рабочей среде производится запуск веб-приложения.

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

Веб-приложение генерирует вывод, который передаётся компонентами технологии поддержки веб-приложения веб-серверу. Веб-сервер отправляет вывод клиенту в виде HTTP-ответа.

Основываясь на данной схеме и терминах, введённых выше, можно определить поведение веб-приложения как взаимодействие веб-приложения с объектами окружения в ответ на HTTP-запросы от браузера пользователя.

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


4 Метод обнаружения уязвимостей веб-приложений


В данном разделе описывается предлагаемый метод обнаружения уязвимостей веб-приложений на основе контроля поведения веб-приложения.


4.1 Применение метода


Как было отмечено во Введении, существующие средства обнаружения уязвимостей используют методы белого и чёрного ящика. В первом случае производится анализ исходных коды и/или файлов конфигурации веб-приложения. Выявляются участки кода, потенциально содержащие уязвимость или небезопасные параметры конфигурации [12]. Во втором случае осуществляется поиск уязвимостей "извне" - веб-приложению отсылаются HTTP-запросы и анализируются ответы. При этом встают задачи выявления структуры веб-приложения, определения типа сервера и построения тестового набора HTTP-запросов и последующего анализа HTTP-ответов [14]. Но данные средства не осуществляют контроль поведения веб-приложения в смысле, определённом в Разделе 3, в то время как необнаруженные уязвимости могут проявиться именно в обращении к объектам окружения. Предлагаемый метод обнаружения уязвимостей предполагает сравнение поступающего HTTP-трафика со внутренней работой веб-приложения. Метод предназначен для обнаружения уязвимостей, приводящих к недопустимым с точки зрения профиля нормального поведения операциям веб-приложения над объектами окружения и/или изменению значений допустимых операций.

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


4.2 Описание метода


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

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

Режим обучения предназначен для автоматического построения профилей нормального поведения веб-приложений. В режиме обучения веб-приложение используется легитимным пользователем строго по назначению. На этапе обучения трасса анализируется, и в результате анализа формируется профиль нормального поведения веб-приложения. В нём фиксируются наборы HTTP-параметров и соответствующие наборы операций. Таким образом, профиль несёт в себе информацию об ожидаемых (или допустимых) операциях в ответ на каждый набор HTTP-параметров. Подробнее алгоритм построения профиля нормального поведения описывается в Подразделе 6.4.3.

Очевидно, для построения максимально подробного и адекватного профиля нормального поведения, функционирование веб-приложения в режиме обучения должно охватывать возможно большее количество вариантов использования. При этом также встаёт традиционная для включающих в себя этап обучения методов обнаружения аномалий проблема "чистоты" учебного периода - необходимо оградить веб-приложение от возможного использования злоумышленниками, так как иначе в профиле нормального поведения в качестве допустимых будут зафиксированы действия, потенциально таковыми не являющиеся [4, 6].

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

4.3 Использование значений операций для более точного обнаружения отклонений в поведении


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

Можно привести следующий пример. Уязвимость в файле modules. php распространённого веб-приложения CMS PHP-Nuke v 7.5 позволяет провести атаку типа класса SQL injection [3]. При атаках этого класса злоумышленник заставляет веб-приложение выдать СУБД изменённый или модифицированный запрос. Атаки класса SQL injection являются как распространёнными, так и особенно опасными в связи с тем, что могут потенциально приводить к потере всех данных в базе данных. Не менее опасными представляются кража или подмена данных в базе данных. Уязвимости, позволяющие проведение атак класса SQL injection, обычно связаны с недостаточной проверкой и очисткой вводимых пользователем данных при динамическом формировании SQL-запроса с использованием этих данных.

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

-й POST-параметр: name=Your_Account

-й POST-параметр: op=userinfo

3-й POST-параметр: username= OR username LIKE %; - -

Результирующий SQL-запрос:uname FROM nuke_session WHERE uname= OR username LIKE %; - -'

Таким образом, с точки зрения описанного метода в ходе атаки веб-приложение совершит допустимую операцию "SELECT" над объектом окружения "сервер MySQL". Аномалия будет заключаться в изменении значения операции. При обычном функционировании значение данной операции будет равно 1, в то время как в результате проведения атаки значение операции будет равно количеству строк в таблице nuke_session.

Можно привести также следующий пример уязвимости, приводящий к атаке класса SQL injection [3]. В ходе выполнения скрипта выполняется запрос, показывающий пользователю список его кредитных карт. В результате атаки злоумышленник может получить список кредитных карт интересующего его пользователя. Атака реализуется следующим образом:

-й POST-параметр: user=Bob

-й POST-параметр: card_type= OR user=Alice

Результирующий SQL-запрос:card_id FROM creditcards WHERE user=Bob AND type= OR user=Alice

Таким образом, с точки зрения описанного метода в ходе атаки веб-приложение совершит допустимую операцию "SELECT" над объектом окружения "сервер MySQL". Аномалия будет заключаться в изменении значения операции. При обычном функционировании значение данной операции будет равно количеству кредитных карт пользователя Bob, информация о которых содержится в таблице creditcards, в то время как в результате проведения атаки значение операции будет равно совокупному количеству кредитных карт пользователей Bob и Alice.

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


4.4 Отклонения в поведении с точки зрения метода


Таким образом, с точки зрения описываемого метода, возможны два класса аномалий:

Аномалии, связанные с обнаружением недопустимых операций.

Аномалии, связанные со значениями операций.

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

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

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


4.5 Сравнение наборов HTTP-параметров


Необходимо дополнительно рассмотреть вопрос о сравнении наборов HTTP-параметров.

Параметры могут быть переданы в веб-приложение методами GET и POST [22, 23], определёнными в стандарте протокола HTTP. При использовании метода GET параметры передаются в URL-адресе вида://<адрес приложения>? параметр1=значение1&параметр2=значение2

Так как длина URL ограничена, метод GET применим для передачи данных небольшого объёма. Cогласно стандарту HTTP [23], запросы типа GET считаются идемпотентными <#"center">5. Выбор методов обнаружения аномалий


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

Рассмотренные методы были выбраны из следующих соображений:

каждый метод является представителем класса методов;

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

В данном разделе и далее термины "модель обнаружения аномалий" и "метод обнаружения аномалий" будут считаться равнозначными и взаимозаменяемыми. Также равнозначными будут считаться понятия "этап обучения" и "этап построения профилей нормального поведения".


5.1 Метод Хотеллинга (тест Хотеллинга)


Метод Хотеллинга представляет собой многомерный статистический метод обнаружения аномалий [4]. Пусть Xi = (Xi1, Xi2, …, Xip) - значения p параметров процесса или системы в определённый момент времени i. Предполагается, что при нормальном функционировании процесса анализируемое множество векторов X обладает нормальным распределением с вектором математических ожиданий ? и ковариационной матрицей ?. Для образца данных размера n вектор математических ожиданий X и ковариационная матрица S обычно рассчитываются следующим образом:



Значение теста Хотеллинга T2 для наблюдения Xi рассчитывается следующим образом:



Большое значение T2 означает большое отклонение значений наблюдения Xi от математических ожиданий анализируемой совокупности наблюдений.

Обычно неизвестно, каким распределением обладает множество значений каждой такой переменной, а значит, выдвигать предположение о том, что оно является нормальным, нельзя. Однако, если p случайных величин независимы и p достаточно большое (примерно больше 30), то T2 имеет распределение близкое к нормальному в соответствии с Центральной Предельной Теоремой вне зависимости от того, какими распределениями обладают множества значений каждой из p рассматриваемых случайных переменных. Используя набор значений T2, можно получить значения дисперсии и математического ожидания путём приближения математического ожидания и дисперсии . Предельные значения для обнаружения потери контроля над процессом обычно ставятся равными 3? и определяют диапазон . по выходу значения T2 за который подаётся сигнал об аномалии.

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

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

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

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

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

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


5.2 Метод EWMA (Exponentially Weighted Moving Average)


В основе метода EWMA лежит экспоненциальное сглаживание первого порядка [20, 21]:


(5.2.1)


где

0<??1 - константа сглаживания.

В роли начального значения может быть взято математическое ожидание по предварительным данным, т.е.


z0 = (5.2.2)


Если раскрыть zi-1, получается:



Рекурсивно, для zi-j, j=2, 3, …, t получается:



Вес элемента уменьшается геометрически, с ростом порядкового номера. Сумма весов стремится к 1, так как:



Если, к примеру, ?=0.2, то вес, назначенный текущему элементу, равен 0.2, а веса, назначенные предыдущим элементам, равны 0.04, 0.128, 0.1024 и так далее.


Рисунок 5.2.1 Изменение веса образца в ходе работы EWMA


Контрольные пределы для EWMA рассчитываются следующим образом (ВКП - верхний контрольный предел, НКП - нижний контрольный предел):


(5.2.3)

(5.2.4) где


Где ?2 - дисперсия, а ?x - математическое ожидание случайной величины xi.

В этих формулах L является шириной контрольного диапазона.

На практике часто используемыми значениями константы сглаживания являются ?=0.05, ?=0.10 и ?=0.25. При меньших значениях ? на значение статистики zi влияет большее количество значений xi, при больших - меньшее, что позволяет параметризовать формулу расчёта zi (5.2.1) для учёта краткосрочных или долгосрочных тенденций.

В общем случае формирование профиля нормального поведения производится следующим образом.

Получается набор учебных данных. Далее высчитывается математическое ожидание для анализируемой случайной величины, оно принимается в качестве начального значения статистики z0 (согласно формуле (5.2.2)). Затем по формуле (5.2.1) для каждого i-го значения случайной величины из тестового набора рассчитывается значение статистики zi. После этого высчитывается дисперсия для xi и контрольные пределы по формулам (5.2.3) и (5.2.4). Полученные данные сохраняются в профиле нормального поведения.

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

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

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

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

В режиме обнаружения аномалий поступающие значения операций используются для расчёта значения статистики по формуле (5.2.1), статистика считается для каждой допустимой операции каждого набора HTTP-параметров. При выходе значения статистики за контрольные пределы, указанные в профиле нормального поведения - фиксируется аномалия и предполагается уязвимость в веб-приложении, которому поступил запрос.


5.3 Метод цепей Маркова


Определение [26]: Маркова цепь - марковский процесс с дискретным временем, заданный в измеримом пространстве.

Стохастический процесс в дискретные моменты времени показывает, как меняется значение случайной переменной в данные моменты времени. Пусть Xt - некоторая случайная переменная, представляющая состояние системы в момент времени t, где t=0, 1, …Стационарная цепь Маркова - это стохастический процесс с дискретным временем, для которого предполагается следующее:

распределение вероятности нахождения системы в некотором состоянии в момент времени t+1 зависит от состояния в момент времени t и не зависит от состояний, в которых находилась система в моменты времени, предшествующих моменту t;

переход из состояния в момент времени t в состояние момента времени t+1 является мгновенным.

Обозначим через pij вероятность того, что система находится в состоянии j в момент времени t+1 и в состоянии i в момент времени t [8]. Если множество возможных состояний системы конечно (1, 2, …, s), то стационарная цепь Маркова может быть определена матрицей вероятностей переходов



и вектором начального распределения вероятностей: Q = (q1 q2 … qs), где qi - вероятность нахождения системы в состоянии i в момент времени 0 и .

Вероятность появления последовательности состояний X1, X2, …, XT в моменты времени 1, 2, …, T в контексте цепной модели Маркова рассчитывается следующим образом:



Матрица вероятностей переходов и вектор начального распределения вероятностей могут быть построены путём анализа состояний системы в предыдущие моменты времени. Если имеется набор наблюдений за состояниями системы X0, X1, …, XN-1 в моменты времени 0, 1, …, N-1, то компоненты матрицы вероятностей переходов и вектора начального распределения вероятностей рассчитываются следующим образом:


(5.3.1)


где

Nij - количество наблюдаемых пар состояний Xt и Xt+1, равных i и j соответственно.

Nj. - количество наблюдаемых пар состояний Xt и Xt+1, где первое равно i любым из 1, 2, …, s.

Nj - количество состояний Xt, равных i

N - общее количество наблюдений.

Для анализа открывается окно наблюдения размера N - берутся N последних событий до настоящего момента времени t Et- (N-1) =t-N+1, …, Et.

Каждому событию сопоставляется тип из конечного множества типов событий. Далее анализируется получившаяся последовательность состояний - типов событий Xt-N, …, Xt (Xi - тип события Ei).

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


(5.3.2)


Последовательность аномальных действий будет иметь меньшую вероятность (меньшую поддержку модели).

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

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

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

В режиме обнаружения аномалий для каждого набора HTTP-параметров открывается окно наблюдения, охватывающее последовательность значений операций, поступающих для данного набора HTTP-параметров. На основе извлечённых из профиля нормального поведения матрицы вероятностей переходов и вектора начального распределения вероятностей по формуле (5.3.2) пересчитывается общая вероятность последовательности значений операций, зафиксированной в текущий момент времени в окне наблюдения. При падении вероятности ниже контрольного предела - фиксируется аномалия и предполагается уязвимость в веб-приложении, которому поступил запрос.


5.4 Нейросетевой метод


Нейросетевой метод обнаружения аномалий рассматривается на примере экспериментальной системы обнаружения аномалий NNID (Neural Network Intrusion Detection) [25].

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

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

Количество входов нейросети делается равным сумме количества всех возможных GET и POST параметров и количества всех операций над всеми объектами окружения. Количество выходов устанавливается равным количеству веб-приложений. В режиме обнаружения аномалий на входы нейросети, соответствующие GET и POST параметрам подаются: 1, если данный параметр присутствовал в HTTP-запросе, и 0, если не присутствовал. На входы, соответствующие операциям над объектами окружения, подаются соответствующие значения операций. Значение на выходах варьируется от 0 до 1 с шагом 0.1. Считается, что значение на некотором выходе большее 0.5 однозначно идентифицирует веб-приложение, которому может принадлежать такая комбинация HTTP-параметров и значений операций. Если более чем на одном выходе обнаружено значение большее 0.5, или ни на одном выходе нет значения большего 0.5 - фиксируется аномалия и предполагается уязвимость в веб-приложении, которому поступил запрос.

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


5.5 Сравнительный анализ методов обнаружения аномалий и обоснование выбора метода


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

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

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

Из рассмотренных методов данному критерию удовлетворяют:

метод EWMA - корректная работа метода при распределениях, не являющихся близкими к нормальному, подтверждается в [21];

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

нейросетевой метод - в основе метода лежит нейросеть, для корректной работы которой априори не требуется нормальное распределение.

Как было подчёркнуто в описании метода Хотеллинга [4], для корректной работы метода при многомерном распределении параметров, не являющимся близким к нормальному, требуется достаточно большое количество анализируемых параметров (то есть, достаточно большая размерность вектора значений) - примерно 30 и более. Но о количестве анализируемых параметров заранее ничего сказать нельзя и, следовательно, нельзя гарантировать корректную работу метода при произвольном виде многомерного распределения значений. Следовательно, относительно метода Хотеллинга в общем случае нельзя сказать, что он удовлетворяет обозначенному критерию.

. Корректная работа метода при произвольном количестве параметров.

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

Остальные методы данному критерию удовлетворяют:

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

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

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

. Локальность переобучения.

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

в сфере контроля модуля обнаружения аномалий появляется новое веб-приложение, для которого профили нормального поведения ещё не сформированы;

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

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

Из рассмотренных методов данному критерию удовлетворяют:

метод Хотеллинга - достаточно провести этап обучения для нового или изменённого веб-приложения, с заменой уже существующих для разных наборов HTTP-параметров профилей нормального поведения значений операций;

метод EWMA - достаточно провести этап обучения для нового или изменённого веб-приложения, с заменой уже существующих для разных наборов HTTP-параметров профилей нормального поведения значений операций;

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

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

. Анализ значений, а не последовательности их появления.

Недостатком статистических методов считается нечувствительность к аномалиям в последовательности событий. Существует ряд методов, которые предназначены для обнаружения аномалий именно в последовательности событий, например - метод упреждающего генерирования шаблонов (Predictive Pattern Generation) [6] и описанный выше метод цепей Маркова. По сути, такие методы предполагают переход системы из состояния в состояние в зависимости от поступающих значений и на этапе обучения определяют вероятности переходов. Отправной точкой служит предположение о том, что множество состояний системы конечно, иначе возникают проблемы с определением момента завершения этапа обучения, так как система будет продолжать переходить в новые состояния. Реализация методов этого класса основывается на анализе последовательности значений из конечного множества значений. Примером может служить последовательность системных вызовов операционной системы. Однако в рассматриваемой задаче анализируемые последовательности содержат значения операций, и о конечности множества их значений априори ничего сказать нельзя. Поэтому анализ самих значений, а не последовательности их появлений, представляется более перспективным в контексте данной задачи.

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

Из рассмотренных методов следующие методы анализируют значения случайных величин, а не последовательность появления этих значений:

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

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

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

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

6. Модуль обнаружения уязвимостей


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

Модуль реализован в виде набора классов на языке C++, предназначенных для использования в рамках СОА "Мониторинг-РВС".


6.1 Требования к модулю


В данном подразделе формулируются требования к разрабатываемому модулю обнаружения уязвимостей.

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

модуль должен содержать независимые подсистемы для построения профилей нормального поведения веб-приложений и для обнаружения уязвимостей на основе построенных профилей;

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

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


6.2 Структура профиля нормального поведения


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

Каждая запись профиля нормального поведения состоит из секций мета-информации, секции HTTP-параметров, которая подразделяется на подсекции GET и POST параметров, и секции информации об операциях над объектами окружения.

Запись профиля нормального поведения открывается ключевым словом WAProfile_Begin и заканчивается ключевым словом WAProfile_End.


6.2.1 Секция мета-информации

Секция мета-информации содержит набор основных и вспомогательных данных профиля нормального поведения.

Основными полями являются:

WAProfile_URL - данное поле содержит базовый URL-адрес веб-приложения.

Вспомогательными полями являются:

WAProfile_UserAgent - данное поле может содержать значение User-Agent HTTP-запроса. Поле является необязательным. Если значение поля задано, то в режиме обнаружения аномалий будет проводиться дополнительная проверка. Значение "*" в данном поле отключает проверку, семантически соответствуя любому значению.


6.2.2 Секция HTTP-параметров

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

Секция HTTP-параметров состоит из подсекций GET и POST параметров. Подсекции идентичны и имеют следующую структуру:

Подсекция открывается ключевым словом WAProfile_RequestSectionBegin.

Первым полем подсекции является поле WRA_RequestMethod, имеющее два возможных значения - GET и POST. Значение данного поля определяет, какие параметры описываются данной подсекцией.

Список GET или POST параметров, в зависимости от подсекции.

Подсекция закрывается ключевым словом WAProfile_RequestSectionEnd.

Каждый HTTP-параметр описывается парой полей:

WAProfile_ParameterName - данное поле содержит имя параметра;

WAProfile_ParameterValue - данное поле содержит значение параметра либо его тип (см. Подраздел 6.4.2).

В разработанном модуле в качестве типов используются символьные классы регулярных выражений стандарта POSIX [24]:

[: alnum:] - буквенно-цифровые символы;

[: alpha:] - буквенные символы;

[: blank:] - пробелы и знаки табуляции;

[: cntrl:] - управляющие символы;

[: digit:] - цифры;

[: graph:] - символы, которые и печатны, и одновременно видимы;

[: lower:] - буквы нижнего регистра;

[: print:] - печатные символы (символы, не являющиеся управляющими);

[: punct:] - знаки пунктуации;

[: space:] - пробельные символы;

[: upper:] - буквы верхнего регистра;

[: xdigit:] - шестнадцатеричные цифры.

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

Тем не менее, для GET-параметров возможны исключения - вместо совпадения значения для некоторых параметров целесообразнее проверять совпадение типов. К примеру, значение GET-параметра showforum системы управления форумом Invision Power Board варьируется, но логика работы системы при наличии этого параметра в URL остаётся неизменной. Аналогично, для POST-параметров возможны исключения - вместо совпадения типов для некоторых параметров целесообразнее проверять совпадение значений. К примеру, значение POST-параметра act системы управления форумом Invision Power Board является указанием к действию системе - и влияет на логику работы системы при обработке остальных POST-данных. Формат описания исключений для разработанного модуля приводится в Подразделе 6.4.2.


6.2.3 Секция информации об операциях над объектами окружения

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

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

Подсекция открывается ключевым словом WAProfile_ObjectRequestStart.

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

Подсекция закрывается ключевым словом WAProfile_ObjectRequestEnd.

Операция описывается следующими полями:

WAProfile_ObjectId - данное поле содержит строку-идентификатор объекта окружения, которому принадлежит описываемая операция;

WAProfile_ObjectName - данное поле содержит текстовую строку-описание объекта окружения, которому принадлежит описываемая операция;

WAProfile_ObjectOp - данное поле содержит строку-идентификатор операции

WAProfile_ObjectOpMean - данное поле содержит вещественное значение, представляющее математическое ожидание статистики, рассчитываемой по формуле (5.2.1);

WAProfile_ObjectOpLambda - данное поле содержит вещественное значение константы сглаживания ?, используемого при расчёте статистики по формуле (5.2.1);

WAProfile_ObjectOpUCL - данное поле содержит вещественное значение верхнего контрольного предела, рассчитываемое по формуле (5.2.3);

WAProfile_ObjectOpLCL - данное поле содержит вещественное значение нижнего контрольного предела, рассчитываемое по формуле (5.2.4).


6.2.4 Пример записи профиля нормального поведения

Ниже приводится пример одной записи профиля нормального поведения. Запись определяет две допустимые операции ("SELECT" и "INSERT") к одному объекту окружения (сервер MySQL версии 4.1.8) для набора параметров, состоящего из одного GET-параметра q и четырёх POST параметров title, changed, body, format.

WAProfile_Begin_RequestURL: #"center">6.3 Программная архитектура модуля


В данном подразделе описывается программная архитектура разработанного модуля обнаружения уязвимостей.

Модуль состоит из следующих основных подсистем:

консоль управления;

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

подсистема построения профиля нормального поведения;

подсистема обнаружения аномалий.

Подробное описание каждой подсистемы модуля проводится в соответствующих подразделах Раздела 6.4 Ниже приводится краткое описание задач, решаемых каждой подсистемой.

Задачами консоли управления является:

общее управление модулем;

загрузка параметров конфигурации;

настройка и запуск подсистем.

Задачами подсистемы предварительной обработки трассы являются:

получение записей трассы от поставщиков событий СОА "Мониторинг-РВС";

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

Задачами подсистемы построения профиля нормального поведения являются:

анализ поступающих от подсистемы предварительной обработки трассы записей трассы и построение дерева запросов;

формирование и сохранение профилей нормального поведения на основе дерева запросов.

Задачами подсистемы обнаружения аномалий являются:

загрузка профилей нормального поведения и формирование дерева профилей;

анализ поступающих от подсистемы предварительной обработки трассы записей трассы и выявление аномалий;

подача сообщений о выявленных аномалиях на консоль управления.

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

На рисунке 6.3.1 показана схема работы модуля в режиме построения профиля нормального поведения. Данные от поставщиков событий (на схеме обозначены аббревиатурой "ПС"), перехватывающих HTTP-запросы к веб-приложению и обращения веб-приложения к объектам окружения, попадают в подсистему предварительной обработки трассы, где анализируются и преобразовываются к внутреннему представлению записи трассы. Далее преобразованная запись трассы передаётся в подсистему построения профилей нормального поведения, где происходит анализ и добавление содержащихся в записях трассы данных в строящееся дерево запросов. По команде отключения режима построения профилей нормального поведения с консоли управления, подсистема построения профилей нормального поведения формирует на основе построенного дерева запросов профили нормального поведения и сохраняет их в базу данных профилей нормального поведения (на схеме помечена аббревиатурой "БД").


Рисунок 6.3.1 Схема функционирования модуля в режиме построения профиля нормального поведения


На рисунке 6.3.2 показана схема работы модуля в режиме обнаружения аномалий. Данные от поставщиков событий (на схеме обозначены аббревиатурой "ПС"), перехватывающих HTTP-запросы к веб-приложению и обращения веб-приложения к объектам окружения, попадают в подсистему предварительной обработки трассы, где анализируются и преобразовываются к внутреннему представлению записи трассы. Далее преобразованная запись трассы передаётся в подсистему обнаружения аномалий, где происходит анализ и выявление аномалий относительно профилей нормального поведения. Профили нормального поведения загружаются подсистемой обнаружения из базы данных профилей нормального поведения (на схеме помечена аббревиатурой "БД") в начальный момент времени и формируют дерево профилей нормального поведения.


Рисунок 6.3.2 Схема функционирования модуля в режиме обнаружения аномалий


6.4 Описание подсистем модуля


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

6.4.1 Консоль управления

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

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


6.4.2 Подсистема предварительной обработки трассы

Задачей подсистемы предварительной обработки трассы (далее - "предобработчик трассы") является анализ и преобразование записей трассы к внутреннему представлению для дальнейшего анализа подсистемами построения профиля нормального поведения и обнаружения аномалий.

Основными задачами предобработчика трассы являются:

анализ значений POST-параметров и их замена на типы;

суммирование значений для одинаковых операций в записи трассы.

Как было сказано в Подразделе 4.5, при сравнении GET-параметров сопоставляются значения параметров, а при сравнении POST-параметров - их типы. Определение типов POST-параметров является непосредственной задачей предобработчика трассы.

В качестве типов используются символьные классы регулярных выражений стандарта POSIX [24]. Для определения типа используется соответствующее регулярное выражение.

Как было отмечено в Подразделе 6.2.2, в ряде случаев нужно обрабатывать отдельные GET-параметры как POST-параметры, и наоборот. То есть - заменять значение отдельных GET-параметров на их типы и не заменять значение отдельных POST-параметров на их типы. Список таких исключений задаётся в отдельном файле, представляющем собой совокупность записей, описывающих исключения.

Запись имеет следующую структуру:

запись открывается ключевым словом WAProfile_ExclusionBegin;

набор полей, описывающих исключение;

запись закрывается ключевым словом WAProfile_ExclusionEnd.

Запись состоит из следующих полей:

WAProfile_ExclusionURL - поле содержит URL-адрес веб-приложения, которому передаётся параметр;

WAProfile_ExclusionMethod - поле содержит метод, которым передаётся параметр. Возможные значения:

WAProfile_ExclusionParam - имя передаваемого параметра;

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

use_value - параметр сохраняет значение, при сравнении наборов HTTP-параметров происходит сравнение значений данных параметров;

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

use_custom_regexp - значение параметра проверяется специальным регулярным выражением в формате PCRE [24], которое указывается в отдельном поле.

WAProfile_ExclusionRegexp - поле содержит регулярное выражение в формате PCRE [24]. Поле является необязательным. Регулярное выражение, заданное в поле, используется для проверки значения параметра, если в качестве значения поля WAProfile_ExclusionType задано use_custom_regexp.

Примеры записей:_ExclusionBegin_ExclusionURL: #"center">6.4.3 Подсистема построения профиля нормального поведения

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

Подсистема активизируется при запуске модуля в режиме построения профиля нормального поведения.

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

На основании поступающих записей трассы строится дерево запросов, в котором семантически вершины глубины 1 соответствуют веб-приложениям, вершины глубины 2 - наборам HTTP-параметров, а вершины глубины 3 - наборам операций. Как было отмечено выше, веб-приложения различаются по URL-адресу.

На рисунке 6.4.1 показано добавление данных записи трассы в дерево запросов.


Рисунок 6.4.1 Добавление данных записи трассы в дерево запросов


Дерево строится по следующему алгоритму:

Если на входе есть очередная запись трассы - переход на шаг 2, иначе останов.

Из записи извлекается URL-адрес, которому адресован запрос.

Проверяется, есть ли уже в дереве вершина глубины 1 с таким же URL-адресом. Если такой вершины нет (рисунок 6.4.2), то:

заводится вершина глубины 1 с данным URL;

созданной вершине глубины 1 добавляется дочерняя вершина глубины 2 с набором HTTP-параметров, извлечённым из записи трассы;

созданной вершине глубины 2 с набором HTTP-параметров добавляется дочерняя вершина с набором операций, извлечённым из записи трассы;

переход на шаг 1.

Иначе:

проверяется, есть ли среди дочерних вершин глубины 2 данной вершины глубины 1 вершина с набором HTTP-параметров, совпадающим с набором HTTP-параметров, извлечённым из записи трассы. Если такая вершина глубины 2 есть (рисунок 6.4.4), то:

найденной вершине глубины 2 добавляется дочерняя вершина глубины 3 с набором операций, извлечённым из записи трассы;

переход на шаг 1 алгоритма.

Иначе (рисунок 6.4.3):

создаётся вершина глубины 2 с набором HTTP-параметров, извлечённым из записи трассы;

созданной вершине глубины 2 добавляется дочерняя вершина глубины 3 с набором операций, извлечённым из записи трассы;

переход на шаг 1 алгоритма.

Построение дерева завершается в тот момент, когда обработана последняя запись трассы.

Рисунок 6.4.2 иллюстрирует ситуацию добавления данных записи трассы в дерево запросов в случае, когда нет соответствующей вершины глубины 1. Рисунок 6.4.3 иллюстрирует ситуацию добавления данных записи трассы в дерево запросов в случае, когда есть соответствующая вершина глубины 1, но нет соответствующей вершины глубины 2. Рисунок 6.4.4 иллюстрирует ситуацию добавления данных записи трассы в дерево запросов в случае, когда есть соответствующая вершина глубины 1 и есть соответствующая вершина глубины 2.


Рисунок 6.4.2 Добавление данных записи трассы в дерево запросов в случае, когда нет вершины глубины 1 с аналогичным URL


Рисунок 6.4.3 Добавление данных записи трассы в дерево запросов в случае, когда есть вершины глубины 1 с аналогичным URL, но нет вершины глубины 2 с совпадающим набором HTTP-параметров


Рисунок 6.4.4 Добавление данных записи трассы в дерево запросов в случае, когда есть вершина глубины 1 с аналогичным URL и есть вершина глубины 2 с совпадающим набором HTTP-параметров


Далее запускается алгоритм построения профилей нормального поведения на основе сформированного дерева. Алгоритм устроен следующим образом:

Выбирается очередная вершина глубины 1 (то есть, очередное веб-приложение). Если вершина есть - переход на шаг 2, иначе - останов.

Выбирается очередная дочерняя вершина глубины 2 (первая, если произошёл переход с шага 1). Если вершина есть - переход на шаг 3, иначе - переход на шаг 1.

Выбирается очередная дочерняя вершина глубины 3. Если вершины нет - переход на шаг 4, иначе:

.1 выбирается очередная операция из набора операций, содержащегося в данной вершине. Если операции нет - переход на шаг 3. Значение каждой операции считается очередным значением для расчёта статистики по формуле (5.2.1). Для каждой операции каждого объекта окружения ведётся своя статистика.

Обход текущей ветки ("веб-приложение - набор параметров - множество операций") завершён. Для текущего веб-приложения (текущая вершина глубины 1) и текущего набора HTTP-параметров (вершина глубины 2) определено множество допустимых операций (объединение наборов операций из всех дочерних вершин глубины 3), для каждой из которых просчитана статистика по формуле (5.2.1) метода EWMA, и определены контрольные пределы. Полученные данные оформляются в виде записи профиля нормального приложения для текущего веб-приложения и сохраняются в базу профилей нормального поведения. Переход на шаг 2.

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


6.4.4 Подсистема обнаружения аномалий

Задачей подсистемы обнаружения аномалий является анализ трассы, полученной в режиме обнаружения аномалий, на предмет аномалий в поведении веб-приложений. Под аномалиями понимаются как аномалии с точки зрения метода обнаружения уязвимостей (Подраздел 4.4), так и дополнительные виды аномалий - о них будет рассказано ниже.

Подсистема активизируется при запуске модуля в режиме обнаружения уязвимостей. После запуска подсистема производит загрузку профилей нормального поведения веб-приложений из базы данных профилей. При этом во внутреннем представлении формируется дерево профилей нормального поведения (далее "дерево профилей"), практически аналогичное дереву запросов. Разница состоит в том, что каждая вершина глубины 2 (то есть, каждый набор HTTP-параметров) имеет только одну дочернюю вершину глубины 3 (то есть, только один набор операций) - и эта вершина содержит множество всех допустимых операций для данного набора HTTP-параметров. Для каждой операции в дереве профилей сохраняются дополнительные параметры, используемые методом EWMA. После загрузки профилей нормального поведения подсистема переходит в режим обнаружения аномалий.

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

Обнаружение аномалий осуществляется по следующему алгоритму:

Получение очередной записи трассы.

В дереве профилей ищется вершина глубины 1 с совпадающим URL. Если такая вершина есть - переход на шаг 3, иначе на консоль управления подаются:

предупреждение об обнаруженной аномалии;

сообщение: "Для веб-приложения, которому адресован данный запрос, отсутствуют профили нормального поведения; возможно обращение по несуществующему адресу";

данные, содержащиеся в записи трассы.

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

предупреждение об обнаруженной аномалии;

сообщение "Для набора HTTP-параметров, извлечённого из данной записи трассы, отсутствует профиль нормального поведения";

данные, содержащиеся в записи трассы.

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

предупреждение об аномалии;

сообщение "Обнаружен выход статистики значений операции за контрольные пределы для недопустимого набора HTTP-параметров" с уточнением операции, объекта окружения и значения операции;

данные, содержащиеся в записи трассы.

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

предупреждение об аномалии;

сообщение "Для набора HTTP-параметров, извлечённого из данной записи трассы, обнаружена недопустимая операция" с уточнением операции и объекта окружения;

данные, содержащиеся в записи трассы.

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

предупреждение об аномалии;

сообщение "Обнаружен выход статистики значений операции за контрольные пределы" с уточнением операции, объекта окружения и значения операции;

данные, содержащиеся в записи трассы.


7. Результаты


В результате данной работы:

сформулированы основные понятия;

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

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

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

на основе метода разработан и реализован модуль обнаружения уязвимостей для СОА "Мониторинг-РВС" с функцией автоматического построения профилей нормального поведения;

проведены испытания на широко распространённых веб-приложениях.

8. Заключение


В данной работе приведено описание метода обнаружения уязвимостей на основе контроля поведения и разработанного на его основе модуля обнаружения уязвимостей с функцией автоматического построения профилей нормального поведения. В основе метода обнаружения уязвимостей лежит обнаружение аномалий в поведении веб-приложения. Задача обнаружения аномалий в целом и обнаружения аномалий применительно к веб-приложениям в частности в последние годы становится всё более актуальной [1, 3, 6, 8]. Автоматическое построение профилей нормального поведения позволяет уйти от необходимости ручной настройки средства обеспечения безопасности под конкретное веб-приложение, что является трудоёмкой и затратной по времени задачей даже для опытного специалиста.

В ходе работы была выявлена техническая сложность задачи, проявляющаяся на этапе реализации программного средства. Для получения достаточной информации для возможно полного анализа поведения веб-приложения требуется создание поставщиков событий для каждого объекта окружения. Кроме того, программный интерфейс многих объектов окружения не позволяет получить нужные данные, что может потребовать модификацию программных библиотек объекта (как, например, это было сделано авторами в [3]) - это нарушает целостность и стабильность системы и весьма проблематично для программ с закрытым исходным кодом. Также требуется создание координирующей системы, сопоставляющей события от разных объектов окружения с HTTP-запросами и формирующей готовые для анализа записи трассы.

Таким образом, важными направлениями дальнейшей работы в данной области представляются:

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

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

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

9. Литература


[1] Kruegel C., Giovanny V. Anomaly Detection of Web-based Attacks // In Proceedings of the 10th ACM Conference on Computer and Communication Security (CCS 03). 2003. P.251-261.

[2] Vigna G., Robertson W., Kher V., Kemmerer. R. A. A Stateful Intrusion Detection System for World-Wide Web Servers // In Proceedings of the Annual Computer Security Applications Conference (ACSAC 2003). 2003. P.34-43

[3] Valeur F., Mutz D., Vigna G. A Learning-Based Approach to the Detection of SQL Attacks // Intrusion and Malware Detection and Vulnerability Assessment. 2005.

[4] Ye N., Emran S. M., Chen Q., Vilbert S. Multivariate Statistical Analysis of Audit Trails for Host-Based Intrusion Detection // IEEE Transactions on Computers. 2002. № 7.

[5] Denning D. An Intrusion Detection Model // IEEE Transactions on Software Engineering. 1987. № 2. P.222.

[6] Park Y. A Statistical Process Control Approach for Network Intrusion Detection // In partial fulfillment of the requirements for the degree doctor of philosophy in the school of industrial and systems engineering. 2005.

[7] Kohout L. J., Yasinsac A., McDuffie E. Activity Profiles for Intrusion Detection. Деп. в Dept. of Computer Science, Florida SU. 2003.

[8] Ye N. A Markov Chain Model of Temporal Behavior for Anomaly Detection // Proceedings of the 2000 IEEE Workshop on Information Assurance and Security United States Military Academy. West Point, NY. 2000.

[9] Технический проект системы обнаружения компьютерных атак для распределённых вычислительных сетей, разрабатываемой в рамках опытно-конструкторской работы "Создание системы обнаружения компьютерных атак для распределённых вычислительных сетей". ВМиК МГУ. 2003.

[10] Ристик И. Защита Web приложений с помощью Apache и mod_security [HTML] (#"justify">[11] Maunder A., Van Rooyen R., Suleman H. Designing a universal Web application server // Proceedings of SAICSIT 2005.2005. P.111 - 113.

[12] Huang Y. - W., Lee D. T. Web Application Security - Past, Present, and Future // Institute of Information Science, Academia Sinica.

[13] Shah S. An Introduction to HTTP fingerprinting [HTML] (#"justify">[14] Auronen L. Tool-Based Approach to Assessing Web Application Security // Helsinki University of Technology. 2002.

[15] Russell, Deborah, Gangemi Computer Security Basics. California: OReilly&Associates, Inc. 1991.

[16] Symantec Internet Security Threat Report. Trends for January 06-June 06. Vol. X. 2006.

[17] Научно-технический отчет. Разработка методов оценки защищенности скриптовых языков, обеспечивающих функционирование активных элементов Web-серверов. ВМиК, МГУ. 2004.

[18] Auger R. Web Application Firewall Evaluation Criteria // WASC. 2006.

[19] Huang Y. - W., Yu F., Hang C., Tsai C. - H., Lee D. T., Kuo S. - Y. Securing Web Application Code by Static Analysis and Runtime Protection. 2004.

[20] Ye N., Borror C., Zhang Y. EWMA Techniques for Computer Intrusion Detection Through Anomalous Changes in Event Intensity // Quality Reliability Int. 2002. №18. P.443-451.

[21] Borror C., Montgomery D., Runger G. Robustness of the EWMA control charts to non-normality // Journal of Quality Technology. 1998. № 30. P.352-361.

[22] Конверс Т., Парк Д., Морган К. PHP 5 и MySQL. Библия пользователя. П.: Диалектика-Вильямс, 2006.

[23] RFC-2616: Hypertext Transfer Protocol - HTTP/1.1 [HTML] (#"justify">[24] Фридл Д. Регулярные выражения. П.: Питер, 2003.2-е издание.

[25] Ryan J., Ling M. - J., Miikkulainen R. Intrusion Detection with Neural Networks // Advances in Neural Information Processing Systems. 1998. № 10.

[26] Гнеденко Б.В. Курс теории вероятностей. УРСС, 2001.

[27] Drupal Community Plumbing [HTML] (#"justify">[28] Invision Systems, Inc. [HTML] (http://www.invisionsystems.com/).


МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ИМ. М.В. ЛОМОНОСОВА ФАКУЛЬТЕТ ВЫЧИСЛИТЕЛЬНОЙ МАТЕМАТИКИ И КИБЕРНЕТИКИ КАФЕДРА АВТОМАТИЗАЦИИ СИСТЕМ ВЫЧИСЛИТЕЛЬНЫХ К

Больше работ по теме:

КОНТАКТНЫЙ EMAIL: [email protected]

Скачать реферат © 2017 | Пользовательское соглашение

Скачать      Реферат

ПРОФЕССИОНАЛЬНАЯ ПОМОЩЬ СТУДЕНТАМ