Санкт-Петербургский государственный политехнический университет
Факультет технической кибернетики
Кафедра “Информационная безопасность компьютерных систем”
Работа допущена к защите. |
Зав. кафедрой |
д. т.н., проф. _______________ |
"____"______________ 2008 г. |
ВЫПУСКНАЯ РАБОТА БАКАЛАВРА
Тема: | «Разработка архитектуры ядра системы предотвращения вторжений» |
Направление: | 230100 «Информатика и вычислительная техника» |
Руководитель | доцент, к. т.н | |
Выполнила студентка | гр. 4088/2 |
Санкт-Петербург – 2008
Санкт-Петербургский государственный политехнический университет
Факультет технической кибернетики
Кафедра «Информационная безопасность компьютерных систем»
УТВЕРЖДАЮ. |
Зав. кафедрой |
проф., д. т.н. _______________ |
"____"______________ 2008 г. |
ЗАДАНИЕ
на выпускную работу бакалавра
студентке______________________________________________группы 4088/2
1. Тема работы______________________________________________________
___________________________________________________________________
2. Срок сдачи студентом законченной работы___________________________
3. Исходные данные к работе__________________________________________
_________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
4. Содержание расчетно-пояснительной записки (перечень подлежащих разработке вопросов)________________________________________________
_____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
5. Дата выдачи задания_______________________________________________
Руководитель____________________________(________________________)
(подпись руководителя) (Фамилия и инициалы)
Задание принял к исполнению «_____» _________________________ 200__ г.
________________________(__________________________________)
(подпись студента) (Фамилия и инициалы)
Содержание
Содержание. 4
1 Введение. 5
2 Универсальная архитектура системы предотвращения вторжений.. 8
2.1 Универсальный формат хранения данных. 8
2.2 Универсальный интерфейс доступа к данным.. 12
2.3 Управление и обмен данными между компонентами. 12
2.4 Описание ядра универсальной архитектуры СПВ.. 13
2.5 Выводы.. 15
3 Реализация ядра универсальной архитектуры СПВ.. 16
3.1 Структура базы данных хранилища. 16
3.1.1 Описание разделов и таблиц БД.. 17
3.1.2 Соответствие стандарту IDMEF. 19
3.2 Интерфейс доступа к хранилищу данных. 20
3.3 Процессор запуска и управления компонентами. 37
3.4 Подключаемые компоненты.. 38
3.5 Выводы.. 38
4 Пример реализации подключаемого модуля. 40
4.1 Описание реализации. 40
4.2 Выводы.. 42
5 Заключение. 43
Приложение 1. Основные классы модели IDMEF.. 44
Приложение 2 Описание таблиц базы данных хранилища. 53
Приложение 3. Описание функций для сохранения событий в хранилище. Прикладной программный интерфейс хранилища данных универсальнй архитектуры СПВ.. 85
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ.. 102
2 Введение
Системы обнаружения вторжений (СОВ) предназначены для обнаружения вторжений в вычислительные системы со стороны внешних нарушителей или со стороны авторизованных пользователей, некорректно использующих систему.
Многие СОВ при обнаружении атаки на защищаемые станции сети сохраняют запись о событии в журнал и/или генерируют оповещения об атаке администратору безопасности. Такой подход не всегда удобен, так как не позволяет вовремя принять меры для предотвращения вторжения. Однако система также может иметь в своем составе активный модуль реакции, реализующий автоматизированное предотвращение развития вторжения. Данный модуль может, к примеру, автоматически запускать некоторый процесс, блокировать рабочую станцию, нарушающую политику безопасности, закрывать соединение TCP или модифицировать конфигурацию МЭ с целью предотвращения дальнейших атак. Это превращает систему обнаружения вторжений в т. н. систему предотвращения вторжений (СПВ). В системах предотвращения вторжений функции обнаружения объединены с функциями активной защиты от атакующих действий нарушителя.
Необходимым условием создания СПВ является то, что формат результатов работы компонента, производящего обнаружение, должен приводиться к формату входных данных компонента, выполняющего предотвращение дальнейшего развития вторжения. Если указанные компоненты создаются в рамках одной системы, то реализация этого условия не составляет проблемы. Но если требуется по результатам работы СОВ сконфигурировать другое средство активной защиты, то обычно сопряжение выполняется вручную администратором безопасности. Результаты работы СОВ выводятся в некоторый журнал, выполняется экспертный анализ, после чего корректируются настройки средств активной защиты. В большинстве случаев отсутствуют возможности синхронизации изменений настроек произвольного средства предотвращения вторжений с результатами работы системы обнаружения вторжений.
Существуют и другие проблемы, решение которых требует универсализации формата данных и интерфейса доступа к нему. Для обнаружения распределенных атак на информационную систему необходим анализ взаимосвязи между событиями, зафиксированными различными датчиками, расположенными в разных местах. Учет событий, генерируемых датчиками различных типов (например, датчиками, расположенными в сегменте сети и на хосте) позволяет проанализировать различные аспекты одних и тех же действий, более полно восстановить их контекст и повысить точность обнаружения атак.
Иногда для выявления взаимосвязи между событиями удобно применить анализ к результатам работы другого алгоритма анализа с целью выявления дополнительных закономерностей более высокого уровня в действиях нарушителя. Однако различные алгоритмы анализа обычно реализуются в виде отдельных компонентов системы обнаружения вторжений или даже в отдельных системах. При совместном использовании различных систем возникает проблема совместимости форматов, описанная выше относительно совмещения системы обнаружения вторжения и произвольного компонента предотвращения вторжений. Данная проблема также может быть решена вручную администратором безопасности, но наиболее эффективен все же автоматизированный подход.
Современные СОВ и СПВ, как правило, имеют многокомпонентную архитектуру. Компонент – некоторый модуль, имеющий хорошо определенную область ответственности и четко обозначенные множества входных и выходных данных, и в совокупности с другими такими компонентами составляющий систему. Каждый компонент системы определяет часть ее функциональных возможностей. В качестве примера можно привести компонент сбора данных СОВ, модуль анализа, модуль реакции – межсетевой экран и т. д. Форматы данных взаимодействующих компонентов внутри одной системы совместимы между собой.
Возникает идея создания некоторой универсальной архитектуры, в рамках которой различные подключаемые через определенный универсальный интерфейс компоненты смогут составлять индивидуальные решения задачи предотвращения вторжений.
При этом возможна не только разработка компонентов «с нуля», но и повторное использование уже существующих систем путем создания некоторого «шлюза» выходных данных системы в данные, принимаемые универсальным интерфейсом.
Очевидно, что помимо изменяемого множества компонентов, определяющих функциональность системы на базе целевой архитектуры, существует некоторая базовая неизменяемая часть системы, реализующая интерфейс подключения компонентов и набор некоторых необходимых функций – ядро этой архитектуры.
СПВ на базе целевой архитектуры должна обладать следующими свойствами:
1. Расширяемость – относительная простота увеличения набора функциональных возможностей системы. Реализуется за счет построения системы из отдельных компонентов.
2. Универсальность формата хранения и представления данных. Модуль хранения включается в ядро архитектуры, которое предоставляет универсальный интерфейс доступа компонентов к этому модулю.
3. Гибкость настройки и управления – возможность настройки и управления как целой системой, так и отдельными компонентами системы и их взаимодействием. Функции настройки и управления должны реализовываться ядром архитектуры.
4. Переносимость и масштабируемость - возможность адаптации системы к различным требованиям к аппаратно-программной платформе и к различным требованиям к производительности. Дополнительные требования, которые можно выполнить путем реализации ядра архитектуры на различных платформах, с условием неизменности интерфейса.
5. Самоконтроль и контроль собственной безопасности. Дополнительные требования, также выполняемые за счет централизованной архитектуры на базе ядра системы.
В рамках данной работы необходимо решить следующие задачи:
1) Разработать универсальную архитектуру системы предотвращения вторжений и выделить ядро этой архитектуры
2) Реализовать ядро архитектуры
3) Реализовать демонстрационный пример компонента системы обнаружения вторжений на базе этого ядра.
3 Универсальная архитектура системы предотвращения вторжений
Исходя из приведенных выше требований к свойствам СПВ на базе универсальной архитектуры, можно выделить следующие функции, реализуемые ядром этой архитектуры.
1. Хранение результатов работы подключаемых компонентов в некотором универсальном формате, независящем от внутреннего представления данных используемыми в системе компонентами. Использование универсального формата подразумевает отделение данных в системе от знаний, на которых базируется работа отдельных компонентов.
2. Получение данных из хранилища компонентами с использованием универсального интерфейса, не зависящего от реализации хранилища.
3. Предоставление универсального интерфейса подключения различных компонентов.
4. Управление компонентами.
5. Предоставление возможности обмена данными между компонентами.
6. Обеспечение самоконтроля.
3.1 Универсальный формат хранения данных
Одной из наиболее важных проблем, которые необходимо решить при построении любой СОВ или СПВ, является проблема представления и хранения данных.
В задачи, традиционно выполняемые СОВ, входит не только решение вопроса о наличии или отсутствии нарушения безопасности, но и обоснование причин принятия этого решения.
Необходимо также обеспечить независимость представления данных от интерпретации этих данных конкретным компонентом системы и от формата выходных данных этого компонента.
Следовательно, модуль хранения и доступа к данным должен отвечать следующим требованиям:
- предоставлять достаточно ресурсов для хранения результатов работы различных компонентов;
- хранить информацию о времени генерации данных и о модуле, сгенерировавшем данные;
- хранить информацию о взаимосвязи различных данных, возможно, полученных от различных компонентов;
- хранить все данные в универсальном формате, который бы позволил использование данных одного модуля другими модулями системы;
- предоставлять компонентам доступ к данным с использованием некоторого абстрактного интерфейса, скрывающего детали организации модуля хранения и упрощающего получение данных из хранилища;
- разрешать сохранение результатов работы компонентов также с использованием этого интерфейса, упрощающего вывод данных и гарантирующего корректное использование универсального формата.
Необходимость универсального формата хранения данных обусловлена требованием обмена данными между компонентами СПВ. При получении одних и тех же данных несколькими компонентами одновременно нужно исключить возможность повторного сохранения и использования данных. Для этого должна существовать возможность экспорта данных в некоторый универсальный формат.
Стандартом, призванным обеспечить возможность совместного использования коммерческих, свободно распространяемых и исследовательских систем обнаружения вторжений в разнородной среде, является стандарт Intrusion Detection Message Exchange Format (IDMEF), предложенный рабочей группой Intrusion Detection Working Group в составе Internet Engineering Task Force [rfc4765]. IDMEF определяет формат сообщений модулей. Модель данных IDMEF является объектно-ориентированной моделью, описывающей основные сущности в области обнаружения вторжений в виде классов, находящиеся в определенных отношениях наследования и включения. IDWG также предлагает протокол обмена сообщениями в формате IDMEF – Intrusion Detection Exchange Protocol (IDXP) [rfc 4767].
Стандарт IDMEF требует, чтобы между сообщениями отсутствовали семантические различия, независимо от их содержания.
Сообщения об атаках могут быть принадлежать к различным семантическим уровням интерпретации. IDMEF применим как для одиночных(простых) событий, например, для сообщения об ошибке сохранения информации о процедуре аутентификации пользователя в системный журнал, так и для составных, включающих в себя несколько простых. Такой подход позволяет отразить таксономию событий, произошедших в информационной системе.
При этом стандарт позволяет выделить простые события из содержимого составных событий. Иерархия классов модели IDMEF приведена на рис.1.
Рисунок 1 Иерархия классов модели IDMEF
В настоящее время в стандарте определено два подкласса класса сообщений IDMEF: сообщения об атаках (alerts) и сообщения о состоянии компонентов (heartbeats). Следует учитывать, что модель не определяет, как следует классифицировать или идентифицировать сообщения об атаках. Например, один модуль анализа может классифицировать сканирование портов как одиночную (простую) атаку на множество целевых объектов, а другой – как множество атак на один целевой объект. При этом стандарт определяет формат создаваемого модулем сообщения о сканировании портов, независимо от того, как оно было классифицировано.
Каждый объект сообщений IDMEF содержит атрибуты и вложенные объекты других классов, которые в свою очередь также могут состоять из атрибутов и вложенных объектов. Модель определяет обязательные и необязательные атрибуты и объекты для каждого элемента.
В приложении 1 приведены основные классы модели IDMEF и их описание.
IDMEF сообщения нецелесообразно использовать для хранения данных в силу соображений эффективности (каждое сообщение представляет собой документ XML). Однако возможность быстрого преобразования данных хранилища в формат IDMEF позволит осуществлять взаимодействие между различными компонентами одной системы и отдельных систем.
Важную роль при создании хранилища играет выделение множества параметров, описывающих результаты работы практически любого компонента системы. Очевидно, что указанное множество параметров должно включать в себя множество атрибутов классов, описываемых стандартом IDMEF.
Кроме того, необходимо разделить данные, обрабатываемые и продуцируемые некоторым модулем и знания, на которых базируется обработка данных (параметры алгоритма обработки данных). Организация и способ применения указанных знаний должна быть известна только использующему их модулю. К примеру, атрибуты одного и того же множества событий могут оцениваться на наличие сигнатур атак, на предмет удовлетворения некоторым статистическим зависимостям и т. п. При этом хранилище базы данных сигнатур атак или построенных статистических профилей должно быть разделено с хранилищем данных СПВ.
Хранилище должно содержать данные, которые можно разделить на следующие группы:
1. Данные об известных узлах сети (хостах, межсетевых экранах, узлах, на которых установлены компоненты и т. д.), их именовании и адресации.
2. Данные о наблюдаемых отдельными компонентами хостах и сетевых сервисах
3. Самоописывающие данные (о взаимосвязи и функционировании компонентов)
4. Основные атрибуты сообщений компонентов (время добавления, информация об источнике и приемнике потока данных, относящегося к событию, связь с предыдущими сообщениями, оценка вероятности успеха и оценка влияния действий, формирующих событие, на их цель).
5. Атрибуты классификации сообщений компонентов (класс сообщения позволяет уточнить, что именно произошло: ввести в сообщение текстовое описание, дополнительные идентификаторы, привести ссылки на относящиеся к событию описания атак и/или уязвимостей).
6. Атрибуты сообщений, фиксируемые на хосте (информация о пользователях, процессах, функциях, библиотеках, файлах).
7. Атрибуты сообщений, фиксируемые в сети (получаемые из заголовков и поля данных сетевых пакетов).
8. Дополнительные атрибуты сообщений (индивидуально формируемые компонентами атрибуты сообщений, для которых зарезервированы поля данных).
3.2 Универсальный интерфейс доступа к данным
Наиболее подходящее с точки зрения эффективности решение для организации хранилища – использование базы данных. Однако данное решение имеет и свои отрицательные стороны. Организация доступа к данным со стороны компонентов требует выполнения запросов на языке SQL, стандартизованного, но имеющего практически для каждой СУБД свой диалект. Кроме того, непосредственное добавление и модификация данных модулями может привести к отклонениям от используемого формата сообщений, в результате которых данные одного компонента не смогут быть использованы другими компонентами системы.
Решением является создание универсального программного интерфейса доступа к данным хранилища на языке программирования широкого применения. Интерфейс реализуется некоторой библиотекой, экспортирующей все необходимые структуры, функции и константы.
Такой подход позволяет:
1. Избежать отклонений от формата в связи с отсутствием возможности неконтролируемой модификации таблиц базы данных различными компонентами СПВ.
2. Использовать хранилище данных на базе различных СУБД. Для этого необходимо реализовать хранилище на базе этой СУБД и библиотеку доступа к нему с использованием неизменного интерфейса. Это позволяет с минимальными затратами реализовать переносимость компонентов СПВ между различными платформами хранения данных.
3.3 Управление и обмен данными между компонентами
При реализации любой многокомпонентной СПВ, как правило, необходимы механизмы обмена данными между различными компонентами и синхронизации этих компонентов.
Рассмотрим типовые режимы запуска и работы компонентов:
1. Запуск компонента на выполнение единственный раз и, возможно, последующее выполнение в фоновом режиме. Примером компонентов с указанным режимом работы являются сетевые и хостовые датчики событий, модули предотвращения вторжений.
2. Запуск на выполнение один раз в указанный промежуток времени. Периодически бывает необходимо запускать средства сбора текущих параметров и аудита безопасности, средства пост-обработки данных и другие модули пост-обработки.
3. Запуск при фиксации некоторого события другим компонентом. Примерами модулей с указанным режимом запуска могут быть модули уведомления, модули анализа в режиме реального времени и др. Данный режим позволяет организовать комплексную обработку события различными модулями. Очевидной проблемой данного режима запуска является необходимость знания компонентов друг о друге и их синхронизации.
При реализации вместо синхронизации допустимо использовать запуск зависимых компонентов один раз в указанный промежуток времени и поиск в базе данных вновь появившихся событий определенного типа. При таком подходе важным параметром настройки системы является период запуска зависимых модулей, который должен быть не слишком малым и не слишком большим, так как необходимо обеспечить обработку, близкую к режиму реального времени.
Из вышесказанного понятно, что система должна предоставлять интерфейс для подключения модулей различных типов и реализовывать возможность запуска каждого модуля в указанном им режиме и с указанными параметрами запуска: один раз, раз в указанный период времени или при срабатывании другого модуля определенного типа. Тип компонента определяется областью его ответственности, методом, алгоритмом и соответствующей реализацией. Например, различные версии одного и того же программного продукта можно рассматривать как компоненты одного типа. Компоненты, декларирующие свою принадлежность к одному типу, должны продуцировать однотипные результаты (результаты, которые могут быть интерпретированы одинаковым образом). Тип компонента, режим его запуска и, при необходимости, тип компонентов, от результатов которых зависит его запуск, должны указываться при создании компонента. Информация о существующих компонентах и их взаимосвязях хранится в области самоописывающих данных хранилища СОВ.
3.4 Описание ядра универсальной архитектуры СПВ
Таким образом, ядро описанной архитектуры системы составляют (рис. 2):
· хранилище данных;
· реализация интерфейса доступа к хранилищу (библиотека);
· процессор запуска и организации взаимодействия компонентов, предоставляющий интерфейс их подключения.
Функциональные возможности системы определяются используемыми подключаемыми компонентами. Подключение компонентов позволяет обеспечить расширяемость функциональных возможностей системы предотвращения вторжений. Взаимодействие различных типов компонентов между собой дает возможность комплексной обработки событий, происходящих в информационной системе.
Рисунок 2 Универсальная архитектура СПВ
Описанная архитектура позволяет объединить различные средства мониторинга и обеспечения безопасности в единую систему, организовать взаимодействие (в том числе, в режиме реального времени) компонентов, имеющих различные области ответственности.
3.5 Выводы
В данной главе была представлена универсальная архитектура предотвращения вторжений. Предложен и обоснован выбор универсального формата хранения данных, указано на необходимость отделения интерфейса доступа к данным от реализации. Описаны необходимые механизмы управления компонентами, реализующими функциональность СПВ.
Таким образом, выделено ядро этой архитектуры, реализующее базовые механизмы, необходимые для создания практически любой СПВ.
4 Реализация ядра универсальной архитектуры СПВ
СПВ, построенная в соответствии с универсальной архитектурой, состоит из:
1) Хранилища данных. Реализация хранилища данных – база данных выбранной в соответствии с некоторыми критериями СУБД.
2) Интерфейса доступа к хранилищу данных. Интерфейс реализуется библиотекой, экспортирующей функции доступа к данным хранилища на выбранном универсальном языке программирования.
3) Процессора запуска и управления компонентами. Представляет собой исполнимый модуль, загружающий и выполняющий компоненты в соответствии с параметрами, декларируемыми ими (посредством интерфейса подключения). Интерфейс подключения и управления компонентами представляет собой набор параметров, декларируемых каждым компонентом, и реализуемых им функций.
4) Подключаемых компонентов, реализующих функциональные возможности СПВ. Подключаемые компоненты реализуются как динамически подгружаемые библиотеки для процессора запуска и управления компонентами. Импортируемые этими библиотеками параметры и функции реализуют интерфейс подключения.
Такая архитектура в точности отвечает стандарту IDMEF в части взаимодействия компонентов распределенной СОВ. Процессор запуска представляет собой менеджер (в терминологии IDMEF), локально взаимодействующий с компонентами (анализаторами в терминологии IDMEF), а распределенное взаимодействие может осуществляться только между менеджерами.
Рассмотрим более подробно составляющие части системы, их функции и взаимодействие между ними.
4.1 Структура базы данных хранилища
Учитывая приведенные в главе 2.1 требования база данных хранилища должна включать следующие четыре группы данных:
1. Данные датчиков и анализаторов. Хранятся в одинаковом формате, с указанием связей между записями (на основании каких записей какие новые записи были сделаны). Формат хранения данных (по структуре, полноте и детализации данных) совместим со стандартом IDMEF. Предусмотрено хранение данных, которые могут быть получены сетевыми и/или хостовыми датчиками.
2. Данные о защищаемых подсетях, серверах, сервисах, протоколах, топологии сети, и другая информация, которая может потребоваться анализаторам.
3. Данные о межсетевых экранах: расположение, защищаемые хосты, политики и правила блокировки.
4. Самоописывающие данные: установленные датчики и анализаторы, их расположение, время последнего включения/выключения и т. п.
Далее рассмотрим более подробно разделы БД.
4.1.1 Описание разделов и таблиц БД
1. Самоописывающие данные (self-made description). Раздел содержит данные о типах возможных компонентов (датчиков, анализаторов и межсетевых экранов) в данной конфигурации СПВ, об установленных компонентах, их производителе, версии, типе ОС, об их расположении, времени последнего запуска и останова, о взаимном использовании одними модулями информации, предоставляемой модулями другого типа (например, данные каких датчиков и анализаторов могут использоваться другими анализаторами, на основании каких данных межсетевой экран будет производить блокировку и т. п.). Указанные данные вносятся в базу данных процессором запуска и организации взаимодействия модулей при регистрации модулей.
2. Описание сетевых устройств и их адресации (network node description). Раздел содержит данные о существующих в конфигурации СПВ сетевых устройствах и их адресации. Это данные о хостах, на которых установлены компоненты СПВ – датчиках, анализаторах, межсетевых экранах; данные о защищаемых и наблюдаемых хостах. Устройства допускают множественную адресацию в различных сетях, в том числе виртуальных. При регистрации компонента дополнительно необходимо указать расположение станции, на которой он функционирует. При этом процессор запуска и взаимодействия модулей должен зафиксировать расположение модуля в таблицах хранилища.
3. Описание наблюдаемых хостов и сервисов. Раздел содержит данные о хостах и сервисах, выделенных отдельными компонентами СПВ для их защиты и/или наблюдения их поведения.
4. Основные данные о событии, зафиксированным или спродуцированным компонентом СПВ. В соответствии со стандартом IDMEF таким событиям может быть сообщение (message), непосредственно связанное с контролем и/или обеспечением безопасности некоторым компонентом СПВ (alert, или предупреждение), или сообщение о текущем состоянии работающего модуля (heartbeat, или сообщение о состоянии модуля). Раздел также содержит информацию о связи событий, и основные данные о хосте-источнике и хосте-цели действий, с которыми связано предупреждение.
5. Детализация предупреждения на основании данных, доступных хостовому модулю (host module data).
6. Детализация предупреждения на основании данных, доступных сетевому модулю (network module data).
7. Зарезервированные поля для хранения специфичных для каждого компонента данных, детализирующих сообщение (specific module fields).
8. Классификация предупреждения согласно соответствию сигнатуре, либо другому признаку, любые данные о предупреждении, позволяющие уточнить, что произошло (alert classification).
9. Данные о конфигурации межсетевых экранов (firewall policy).
В связи с требованием соответствия стандарту IDMEF центральным элементом схемы базы данных является таблица событий, сгенерированных подключаемыми компонентами. Данные этой таблицы конкретизируются информацией из других таблицах. Описание полей таблиц хранилища приведено в Приложении 2.
4.1.2 Соответствие стандарту IDMEF
Поясним требование соответствия модуля хранилища стандарту IDMEF. Так как многие элементы модели IDMEF являются необязательными, то система, использующая только обязательные элементы модели IDMEF, будет формально удовлетворять данному требованию. Однако использование только обязательных элементов модели может существенно ограничить возможность сохранения и повторного использования данных, и, как следствие, работа некоторых подключаемых компонентов станет невозможной.
Поэтому модуль хранения должен не только удовлетворять стандарту IDMEF, но и давать возможность сохранения дополнительных данных для использования компонентами различных типов.
Как видно из таблицы 1, существует практически однозначное соответствие между элементами модели данных IDMEF и таблиц созданной базы данных хранилища. Соответствие полей таблиц БД и элементов классов IDMEF приведено в таблице Приложения 1. Кроме того, схема БД хранилища расширяет модель за счет таблиц для сохранения сетевых данных, дополнительных таблиц для данных о типах компонентов и зависимостях между ними, а также несколько конкретизирует данные об источнике и цели атаки.
Таблица 1. Соответствие элементов модели IDMEF и таблиц БД хранилища
Класс IDMEF | Таблица БД |
IDMEF-Message | Message |
Alert | Alert |
Heartbeat | Heartbeat |
Analyzer | Analyzer, Sensor, Firewall |
CreateTime | Содержатся в БД в качестве полей таблиц Message, Alert и Heartbeat |
DetectTime | |
AnalyzerTime | |
Source | Source |
Target | Target |
Node | Node |
User | User |
Process | Process |
Service | Service |
File | File |
Linkage | Linkage |
Inode | Inode |
Checksum | Столбец checksum таблицы File и таблица ChecksumAlgorithm |
Classification | Classification |
Assessment | Assessment |
AdditionalData | AdditionalData |
4.2 Интерфейс доступа к хранилищу данных
Выше было указано что, для доступа к хранилищу необходимо создать универсальный интерфейс. Организация добавления и изменения данных должна быть построена таким образом, чтобы, с одной стороны, дать компоненту возможность сохранения необходимых данных, с другой стороны, исключить запись в базу данных информации, не соответствующей формату.
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 |
