У вас вопросы?
У нас ответы:) SamZan.net

ПРОЕКТУВАННЯ ПІДСИСТЕМИ (ПРОГРАМНОГО МОДУЛЮ)

Работа добавлена на сайт samzan.net:

Поможем написать учебную работу

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

Предоплата всего

от 25%

Подписываем

договор

Выберите тип работы:

Скидка 25% при заказе до 26.12.2024

ЗМІСТ

ПЕРЕЛІК УМОВНИХ СКОРОЧЕНЬ……………………………………...

9

ВСТУП………………………………………………………………………….

10

  1.   АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ ТА ПОСТАНОВКА ЗАДАЧІ

ДОСЛІДЖЕННЯ ……………………………………………………………….

12

  1.   Роль та задачі систем виявлення вторгнень …...………..………….

12

  1.   Сучасні тенденції у галузі розподілених систем виявлення комп’ютерних атак ……………………………………………………………

23

  1.   Порівняльний аналіз систем виявлення вторгнень …..…...............

26

  1.   Аналіз функціональних можливостей системи виявлення

вторгнень Prelude ………………………………………………………………

36

  1.   Постановка задачі дослідження…………..…..………....…………...

39

Висновки……………………………..………………..……………...........

40

  1.   ПРОЕКТУВАННЯ ПІДСИСТЕМИ (ПРОГРАМНОГО МОДУЛЮ) ….

42

  1.   Формування та аналіз вимог до підсистеми (програмного

модулю), що розробляється ……………………………………….…………..

42

2.1.1 Вимоги до програмного забезпечення підсистеми ……..……….

42

  1.   Вимоги до технічного забезпечення підсистеми …...………....

42

  1.   Аналіз задач і функцій, які повинна вирішувати підсистема та проектування структури підсистеми ……………………………………..…...

43

  1.   Обґрунтування вибору програмного середовища та мови

програмування для розробки підсистеми ……………………………..……...

47

  1.   Проектування бази даних підсистеми …..…..……………...…....…

50

  1.  Обґрунтування вибору моделі «сутність-зв'язок» ………...….…

50

  1.  Обґрунтування вибору системи керування базами даних .......…

53

  1.  Концептуальне проектування бази даних …...……………..……

55

  1.  Фізичне проектування бази даних підсистеми ……………….....

56

Висновки……………………………………………………………..…….

57

  1.   ПРОГРАМНА РЕАЛІЗАЦІЯ ПІДСИСТЕМИ (ПРОГРАМНОГО

МОДУЛЮ) ……………………………………………………………………

58

  1.   Проектування та розробка узгодженого інтерфейсу взаємодії

користувача з підсистемою …………………………………………..………..

5

58

  1.   Розробка компоненти ведення БД підсистеми …………………......

59

  1.  Розробка компоненти аналізу даних моніторингу об’єктів мережі

62

  1.  Розробка компоненти візуалізації даних аналізу …………………...

64

  1.   Інструкція користувачу по роботі з підсистемою (програмним модулем) ………………………………………………………………………..

69

Висновки ……………………………………..……………………………

72

ОЦІНКА ЕФЕКТИВНОСТІ ФУНКЦІОНУВАННЯ СИСТЕМИ ТА ЗАПРОПОНОВАНИХ РІШЕНЬ ………………………………………………

673

Обґрунтування підходу до оцінки ефективності функціонування системи та вибір показників ефективності для оцінки отриманих

результатів ……………………………………………………………………...

73

Оцінка ефективності функціонування системи та

запропонованих рішень ......................................................................................

 

77

Висновки …………………………………………………………………..

79

ЗАКЛЮЧЕННЯ ………………………………………………………...............

80

СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ……………………………………

82

Додаток А ………………………………………………………………............

85

Додаток Б ……………………………………………………………….............

92

Додаток В ……………………………………………………………….............

95


ПЕРЕЛІК УМОНИХ СКОРОЧЕНЬ

IDS  intrusion detection systems;

IDMEF  intrusion detection message exchange format;

БД – база даних;

ГШ – генеральний штаб;

ЗС – збройні сили;

ІАД – інтелектуальний аналіз даних;

ІАС – інформаційно–аналітична система;

ІМ – інформаційна мережа;

ІС – інформаційна система;

ІТ – інформаційні технології;

ЛОМ – локальна обчислювальна мережа;

МО – міністерство оборони;

ОВУ – орган військового управління;

ОПР – особа, що приймає рішення;

ОС – операційна система;

ПЗ – програмне забезпечення;

ПК – персональний комп’ютер;

РІС – розподілена інформаційна система;

СВВ – система виявлення вторгнень;

СД – сховище даних;

СКБД – система керування базами даних.


ВСТУП

Створення високоефективних і багатофункціональних інформаційних систем (ІС ) дозволяє на сьогоднішній день реалізувати їх в самих різних сферах життя сучасного суспільства. ІС дозволяють автоматизувати та підвищити ефективність обробки інформації шляхом застосування відповідного програмного і апаратного забезпечення. Проте використання ІС одночасно загострює і проблеми захисту ресурсів цих систем від загроз інформаційної безпеки. Однією з таких найбільш критичних загроз є можливість реалізації порушником інформаційних атак, спрямованих, наприклад, на порушення працездатності ІС або отримання несанкціонованого доступу до інформації, що зберігається в ІС, що є актуальним питанням, особливо коли автоматизація процесів управління військами визнається одним з пріоритетних напрямків розвитку ЗС України. Для протидії інформаційним атакам в даний час все частіше застосовуються спеціальні системи захисту – системи виявлення вторгнень.

В даний час інтенсивна поява і розростання інформаційного простору призводить до необхідності не тільки несанкціоновано поділити цей простір, а й контролювати і управляти процесами, які протікають в ньому. Для цього використовується, так звана, інформаційна зброя, яка представляє собою засоби знищення, перекручення або розкрадання інформації; обмеження санкціонованого допуску користувачів. Обороноздатність від такої атакуючої інформаційної зброї як комп'ютерні віруси, логічні бомби, засоби придушення інформаційного обміну в телекомунікаційних мережах, фальсифікації інформації в каналах державного та військового управління, безпосередньо залежить від правильності і надійності систем мережевого захисту інформації, у тому числі засобів виявлення і запобігання мережевих атак.

Використання інформаційних мереж має ряд очевидних переваг, першочерговою з яких для ЗС України є підвищення оперативності прийняття та доведення рішень у процесі управління військами (силами). Але поруч з перевагами використання інформаційних мереж, існують і суттєві недоліки, основним з яких є підвищені вимоги до забезпечення безпеки функціонування та відмовостійкості таких мереж. Звісно, в сучасних операційних системах та іншому програмному забезпеченні використовуються технології, що забезпечують безпеку системи та попереджують про її можливий вихід із ладу. Але, як свідчить світовий досвід, цього не достатньо для забезпечення оперативного реагування на компютерні атаки. Перегляд докладного звіту подій в системі виявлення вторгнень вручну через консоль це трудомісткий рутинний процес, що уповільнює аналіз даних та реагування на події в системі виявлення вторгнень. У зв’язку з цим розробка графічних інтерфейсів розподілених систем виявлення комп’ютерних атак із використанням методів візуалізації даних, набуває все більшого та перспективного розмаху у інформаційних технологіях.

Усе вище наведене дозволяє зробити висновок щодо необхідності підвищення ефективності роботи адміністратора безпеки інформаційної мережі за рахунок автоматизації процесів обробки та аналізу даних, що поступають з підсистеми моніторингу даних шляхом побудови та впровадження підсистеми взаємодії адміністратора безпеки з системою виявлення вторгнень Prelude.


  1.  АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ ТА ПОСТАНОВКА ЗАДАЧІ     ДОСЛІДЖЕННЯ

  1.   Роль та задачі систем виявлення вторгнень

Системи виявлення комп'ютерних вторгнень (IDS – Intrusion Detection Systems) один з найважливіших елементів систем інформаційної безпеки інформаційної мережі органу військового управління (ОВУ), враховуючи, як зростає в останні роки число проблем, пов'язаних з комп'ютерною безпекою. Хоча технологія IDS не забезпечує повний захист інформації, проте вона грає досить помітну роль в цій галузі. Так як число і частота атак весь час збільшуються, стає дуже важливим ідентифікувати атаки на ранньому етапі їх розвитку і своєчасно зреагувати на них. У критичних випадках втручання в атаку має бути реалізовано набагато швидше, ніж зможе зреагувати людина.

IDS являють собою спеціалізовані програмно-апаратні комплекси, призначені для виявлення інформаційних атак в ІС. Типова архітектура систем виявлення вторгнень включає в себе наступні компоненти:

модулі-датчики (або модулі-сенсори), призначені для збору необхідної інформації про функціонування ІС;

модуль виявлення вторгнень, що виконує обробку даних, зібраних датчиками, з метою виявлення інформаційних вторгнень порушника;

модуль реагування на виявлені вторгнення;

модуль зберігання даних, в якому зберігається вся конфігураційна інформація, а також результати роботи системи виявлення вторгнень. Таким модулем, як правило, є стандартна СКБД;

модуль управління компонентами системи виявлення вторгнень.

Всі перераховані вище модулі системи виявлення вторгнень можуть бути реалізовані як у вигляді одного, так і декількох програмно-апаратних компонентів

Як і багато інших механізмів захисту, технологія виявлення вторгнень повинна вирішувати кілька головних завдань:

зниження навантаження на персонал (або звільнення від нього), що відповідає за безпеку, від поточних рутинних операцій з контролю за користувачами, системами та мережами, які є компонентами інформаційної системи (ІС);

«розуміння» найчастіше незрозумілих джерел інформації про атаки (мережевого трафіку, журналів реєстрації, системних викликів і т.д.);

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

контроль всіх дій суб'єктів ІС (користувачів, програм, процесів і т.д.), в т.ч. і тими що володіють адміністративними привілеями;

розпізнавання відомих і по можливості невідомих атак попередження про них персоналу, що відповідає за забезпечення інформаційної безпеки;

аналіз інформаційних потоків. Нерідкі ситуації, коли співробітники відділів захисту інформації та відділів телекомунікацій не володіють достовірною інформацією про протоколи які використовуються в сегментах мережі [1, 2].

Механізми виявлення атак, що застосовуються в сучасних системах виявлення атак, засновані на декількох загальних методах. Слід зазначити, що ці методи не є взаємовиключними. У багатьох системах використовується комбінація декількох з них.

Технології, по яких будуються системи виявлення атак IDS (Intrusion Detection Systems), прийнято умовно ділити на дві:

виявлення аномальної поведінки (anomaly detection);

виявлення зловживань (misuse detection).

Технологія виявлення атак шляхом ідентифікації аномальної поведінки користувача заснована на наступній гіпотезі. Аномальна поведінка користувача (тобто атака або яка-небудь ворожа дія) часто виявляється як відхилення від нормальної поведінки. Прикладами аномальної поведінки можуть служити велике число з’єднань за короткий проміжок часу, високе завантаження центрального процесора і т.п. Схематично виявлення атак на основі аномальної поведінки зображено на рис.1.1.

Рис. 1.1. Схема виявлення атак на основі аномальної поведінки

Якби можна було однозначно описати профіль нормальної поведінки користувача, то будь-яке відхилення від такого слідувало б ідентифікувати як аномальне. Проте аномальна поведінка не завжди є атакою. Наприклад, одночасну посилку великого числа запитів від адміністратора мережі система виявлення атак може ідентифікувати як атаку типу «відмова в обслуговуванні».

При використовуванні системи з такою технологією можливі два крайні випадки:

виявлення аномальної поведінки, яка не є атакою, і віднесення її до класу атак;

пропуск атаки, яка не підпадає під визначення» аномальної поведінки. Цей випадок більш небезпечний, ніж помилкове віднесення аномальної поведінки до класу атак.

При налаштуванні і експлуатації систем даної категорії адміністратори стикаються з наступними проблемами:

побудова профілю користувача складно формалізується і є трудомісткою задачею, що вимагає від адміністратора великої попередньої роботи;

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

Поки технологія виявлення аномалій не набула широкого поширення і не використовується ні в одній комерційно поширюваній системі. Зв’язано це з тим, що дана технологія красиво виглядає в теорії, але її дуже важко реалізувати на практиці.

Суть іншого підходу до виявлення атак – виявлення зловживань – полягає в описі атаки у вигляді сигнатури (signature) і пошуку даної сигнатури в контрольованому просторі (мережевому трафіку або журналі реєстрації). Як сигнатура атаки може виступати шаблон дій або рядок символів, що характеризують аномальну діяльність. Сигнатурний метод виявлення атак зображено на рис.1.2.

Рис.1.2. Схема виявлення атак на основі сигнатур

Ці сигнатури зберігаються в базі даних, аналогічній тій, яка використовується в антивірусних системах. Слід зазначити, що антивірусні резидентні монітори є окремим випадком системи виявлення атак, але оскільки ці напрями спочатку розвивалися паралельно, то прийнято розділяти їх. Тому дана технологія виявлення атак дуже схожа на технологію виявлення вірусів; при цьому система може знайти всі відомі атаки, але мало пристосована для виявлення нових, ще невідомих.

Підхід, реалізований в таких системах, дуже простий, і саме на ньому засновані практично всі пропоновані сьогодні на ринку системи виявлення атак. Проте і при їх експлуатації адміністратори стикаються з проблемами. Перша складність полягає в створенні механізму опису сигнатур, тобто мови опису атак. Друга проблема, пов’язана з першою, полягає в тому, як описати атаку, щоб зафіксувати всі можливі її модифікації.

Слід зазначити, що перша проблема вже частково розв’язана в деяких продуктах. Наприклад, це система опису мережевих атак Advanced Packets Exchange, реалізована компанією Internet Security Systems Inc. і пропонована сумісно з розробленою нею системою аналізу захищеності Internet Scanner.

У практичній діяльності звичайно застосовується інша класифікація, що враховує принципи реалізації таких систем: виявлення атак на рівні мережі (network-based); виявлення атак на рівні хоста (host-based).

Системи, що входять в перший клас, аналізують мережевий трафік, використовуючи, як правило, сигнатури атак і аналіз «на льоту», тоді як системи другого класу перевіряють реєстраційні журнали ОС або додатку.

Метод аналізу «на льоту» полягає в моніторингу мережевого трафіку в реальному або близькому до реального часу і використовуванні відповідних алгоритмів виявлення. Часто використовується механізм пошуку в трафіку певних рядків, які можуть характеризувати несанкціоновану діяльність. До таких рядків можна віднести \WINNT\SYSTEM32\CONFIG (описує шлях до файлів SAM, Security і т.д.) або /etc/passwd (описує шлях до списку паролів ОС UNIX).

Аналіз журналів реєстрації – один з найперших реалізованих методів виявлення атак. Він полягає в аналізі журналів реєстрації (log, audit trail), створюваних операційною системою, прикладним програмним забезпеченням, маршрутизаторами і т.д. Записи журналу реєстрації аналізуються і інтерпретуються системою виявлення атак.

До переваг даного методу відноситься простота його реалізації. Проте за цією простотою ховається ряд недоліків:

для достовірного виявлення тієї або іншої підозрілої діяльності необхідна реєстрація в журналах великого об’єму даних, що негативно позначається на швидкості роботи контрольованої системи;

при аналізі журналів реєстрації дуже важко обійтися без допомоги фахівців, що істотно звужує круг розповсюдження цього методу;

до нашого часу немає уніфікованого формату збереження журналів;

аналіз записів в журналах реєстрації здійснюється не в режимі реального часу, тому даний метод не може бути застосований для раннього виявлення атак в процесі їх розвитку.

Як правило, аналіз журналів реєстрації є доповненням до інших методів виявлення атак, зокрема до виявлення атак «на льоту». Використовування даного підходу дозволяє проводити аналіз вже після того, як була зафіксовано вторгнення, щоб виробити ефективні заходи запобігання аналогічним атакам в майбутньому.

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

Ефективність системи виявлення атак багато в чому залежить від вживаних методів аналізу одержаної інформації. У перших системах подібного роду, розроблених на початку 80-х років, використовувалися статистичні методи виявлення атак. В наш час до статистичного аналізу додався ряд нових методик, починаючи з експертних систем, нечіткої логіки і закінчуючи використовуванням нейронних мереж.

Статистичний метод. Основні переваги статистичного підходу – це використовування вже розробленого і такого, що добре зарекомендував себе, апарату математичної статистики і адаптація до поведінки субєкта.

Спочатку для всіх субєктів аналізованої системи визначаються профілі. Будь-яке відхилення використовуваного профілю від еталонного вважається несанкціонованою діяльністю. Статистичні методи універсальні, оскільки для проведення аналізу не вимагається знання про можливі атаки і використовуваних ними вразливостей. Проте при використовуванні цих методик виникає і декілька проблем:

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

дуже важко задати граничні (порогові) значення відстежуваних системою виявлення атак характеристик, щоб адекватно ідентифікувати аномальну діяльність;

статистичні системи можуть бути з часом «навчені» порушниками так, щоб атакуючі дії розглядалися як нормальні.

Слід також враховувати, що статистичні методи непридатні в тих випадках, коли відсутній шаблон типової поведінки користувача або останній схильний до несанкціонованих дій.

Експертні системи. Експертна система складається з набору правил, які охоплюють знання людини-експерта. Використовування експертних систем є поширеним методом виявлення атак, при якому інформація про атаки формулюється у вигляді правил. Вони можуть бути записані, наприклад, у вигляді послідовності дій або сигнатури. При виконанні будь-якого з цих правил ухвалюється рішення про наявність несанкціонованої діяльності. Важливим досягненням такого підходу є практично повна відсутність помилкових тривог.

База даних експертної системи повинна містити сценарії більшості відомих на сьогоднішній день атак. Для того, щоб залишатися постійно актуальними, експертні системи вимагають постійного оновлення бази даних. Хоча експертні системи пропонують хорошу можливість переглядання даних в журналах реєстрації, необхідні оновлення можуть або ігноруватися, або виконуватися адміністратором вручну. Як мінімум це приведе до експертної системи з ослабленими можливостями. У гіршому разі відсутність належного супроводу понизить ступінь захищеності всієї мережі, вводячи її користувачів в оману щодо дійсного рівня захищеності.

Основним недоліком слід визнати неможливість віддзеркалення невідомих атак. При цьому навіть невелика зміна вже відомої атаки може стати серйозною перешкодою для функціонування системи виявлення атак.

Нейронні мережі. Більшість сучасних методів виявлення атак використовує деяку форму аналізу контрольованого простору на основі правил або статистичного підходу. Як контрольований простір можуть виступати журнали реєстрації або мережевий трафік. Аналіз спирається на набір наперед заданих певних правил, які створюються адміністратором або самою системою виявлення вторгнень.

Використання нейронних мереж – один із способів подолання вказаних проблем експертних систем. На відміну від експертних систем, які можуть дати користувачу певну відповідь на питання, чи відповідають дані характеристики закладеним в базу даних правилам, нейромережа проводить аналіз інформації і надає можливість оцінити, чи узгоджуються дані з характеристиками, які вона навчена розпізнавати. Тоді як ступінь відповідності нейромережевого уявлення може досягати 100%, достовірність вибору повністю залежить від якості системи в аналізі прикладів поставленої задачі.

Спочатку нейромережу «навчають» правильній ідентифікації на заздалегідь створеній вибірці прикладів наочної області. Реакція нейромережі аналізується, і система настроюється так, щоб досягти задовільних результатів. На додаток до початкового періоду навчання нейромережа «набирається досвіду» з часом, у міру того як проводить аналіз даних, пов’язаних з наочною областю.

Важливою перевагою нейронних мереж при виявленні зловживань є їх здатність «вивчати» характеристики умисних атак і ідентифікувати елементи, які не схожі на ті, що спостерігалися в мережі раніше.

Кожний з описаних варіантів володіє рядом переваг і недоліків, тому зараз важко зустріти систему, що реалізовує тільки один з цих методів. Як правило, вони використовуються в сукупності.

Атака не тільки повинна бути виявлена, необхідно ще правильно і своєчасно зреагувати на неї. Для цього необхідні системи, які здатні в режимі реального часу сповіщати оператора про перебіг подій в мережевому трафіку та спрацювання правил сигнатур щодо виявлених атак.

У існуючих системах застосовується широкий спектр методів реагування, які можна розділити на три категорії :

повідомлення;

зберігання;

активне реагування.

Застосування тієї або іншої реакції залежить від багатьох чинників.

Повідомлення. Найпростішим і широко поширеним методом повідомлення є відправка адміністратору безпеки повідомлень про атаку на консоль системи виявлення атак. Така консоль може бути встановлена не у кожного співробітника, що відповідає в організації за безпеку; крім того, цих співробітників можуть цікавити не всі події безпеки, тому необхідне застосування інших механізмів повідомлення. Такими механізмами можуть бути відправка повідомлень по електронній пошті, на пейджер, факсом або по телефону. Останні два варіанти присутні в системі виявлення атак RealSecureамериканської компанії Internet Security Systems Inc.

До категорії «збереження» відносяться два варіанти реагування:

реєстрація події в базі даних;

відтворення атаки в реальному масштабі часу.

Перший варіант широко поширений і в інших системах захисту. Для реалізації другого буває необхідно «пропустити» атакуючого в мережу компанії і зафіксувати всі його дії. Це дозволяє адміністратору безпеки потім відтворити в реальному масштабі часу (або із заданою швидкістю) всі дії, здійснені атакуючим, проаналізувати «успішні» атаки і запобігати їм надалі, а також використовувати зібрані дані в процесі аналізу.

Активне реагування. До цієї категорії відносяться наступні варіанти реагування:

блокування роботи атакуючого;

завершення сесії з атакуючим вузлом;

управління мережевим устаткуванням і засобами захисту [3].

Після виявлення в ІС вторгнення система виявлення вторгнень має можливість зробити певні відповідні дії, спрямовані на її блокування. За реалізацію цих дій відповідає модуль реагування системи виявлення атак. Базовим методом реагування системи виявлення атак є оповіщення адміністратора ІС про виявлену атаку. Система виявлення вторгнень може повідомити адміністратора наступними способами:

виведенням відповідного повідомлення на консоль управління адміністратора системою виявлення вторгнень;

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

шляхом формування SNMP - trap повідомлення та подальшим його посиланням в систему управління (наприклад, HP OpenView, IBM Tivoli).

Для забезпечення високої якості аналізу даних моніторингу об’єктів мережі адміністратором безпеки (далі користувачем) та візуалізації даних аналізу потрібен відповідний графічний інтерфейс, у складі якого має функціонувати підсистема управління компонентами системи виявлення вторгнень. Зазначений графічний інтерфейс має надавати користувачеві можливість зміни політики безпеки для різних компонентів системи виявлення атак (наприклад, модулів стеження) та отримання інформації від цих компонентів (наприклад, відомості про зареєстровану атаку).

Розробка і впровадження засобів організаційно-технічного та програмного забезпечення діяльності персоналу є одним з важливих питань функціонування інформаційних систем структурних підрозділів ЗС України. На персонал покладається відповідальність за усунення невизначеності та прийняття рішень щодо оцінки негативного впливу на поточний стан інформаційної системи.

Для ефективної діяльності такого персоналу потрібна безперервна робота системи виявлення вторгнень. У зв’язку з цим накопичується дуже великий файл з інформацією про діяльність системи. З досвіду можна сказати, що об’єм інформації, який потрібно обробити адміністратору, значно перевищує оптимальний об’єм, який він в змозі обробити. З цього випливає, що час реакції оператора системи на певну проблему в мережі не дає змогу оперативно реагувати на події, що відбуваються в мережі. Тобто потрібно автоматизувати рутинні операції обробки великої кількості подій щодо реагування на невідомі досі події.

Методи аналізу інформації, що використовуються в сучасних системах виявлення вторгнень є достатньо ефективними якщо відомі точні характеристики подій [4, 5]. У ході дослідження було виявлено, що СВВ, наприклад, NetSTAT, OSSEC, Bro, Snort, Prelude збирають значну кількість інформації, але жодна не покриває всі рівні спостереження, та інформація, що аналізується кожною системою неповна з точки зору можливості виявлення атак всіх класів. Система OSSEC працює виключно з журналами реєстрації додатків і операційної системи. Системи Bro, Snort аналізують тільки мережеві дані. Системи NetSTAT і Prelude аналізують як дані з локальних системних джерел, так і мережеві дані. Тобто всі вони передбачають застосування методів, що пов’язані зі збором інформації про стан вузлів інформаційно-аналітичної системи. Але вручну переглядати всі нестандартні ситуації, що виникають, є досить об’ємною задачею, тому всю отриману для аналізу інформації потрібно систематизувати.

Переважна більшість сучасних систем виявлення комп’ютерних атак зустрічаються з однією і тією ж проблемою: характеристики проблем, що виникають, потребують швидкої і оптимально-правильної реакції системи, яка була б спроможна залишатись ефективною, навіть при невідомих точних характеристиках несправності. Отже, для ефективної роботи СВВ в розподіленій інформаційній системі потрібно покращити візуалізацію проаналізованих даних для автоматизації роботи персоналу, який приймає рішення.

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

1.2. Сучасні тенденції у галузі розподілених систем виявлення комп’ютерних атак

Дослідження у галузі розподілених систем виявлення комп’ютерних вторгнень все ще йдуть. Технології виявлення вторгнень розвиваються в напрямку – здешевлення інфраструктури. Буде спостерігатися розвиток трьох областей: розгортання, технологічність і якість виявлення атак. Є кілька дослідних лабораторій, які за останні кілька років провели успішну роботу в галузі виявлення вторгнень. Це UC Davis, Haystack Labs і LANL. Ці роботи привели до успішного створення великого числа систем, серед яких можна назвати ASIM, Stalker, NADIR та інші

Як і прогнозували аналітики кілька років тому [5, 6] розвиток СВВ йде по шляху комбінування:

технологій виявлення аномальної активності і виявлення зловмисної поведінки: Перші – здатні виявляти нові типи атак, сигнатури для яких ще не розроблені, не потребують оновлення сигнатур і правил виявлення атак, генерують інформацію, яка може бути використана в системах виявлення зловмисної поведінки, але при цьому вимагають тривалого і якісного навчання, – генерують багато помилок другого роду (виявлення аномальної поведінки, яка не є атакою, і віднесення її до класу атак), дуже повільні в роботі і вимагають великої кількості обчислювальних ресурсів. Другі – компенсують недоліки перших тим, що не створюють у процесі пошуку величезної кількості помилкових повідомлень і детектори зловживань можуть швидко і надійно діагностувати використання конкретного інструментального засобу або технології атаки, але при цьому працюють на базі лише відомих конкретних сигнатур;

способів моніторингу: є видимою тенденція злиття network-based (NIDS), host-based (HIDS) і application-based (AIDS) способів моніторингу, що спричиняє за собою розподілене розташування сенсорів стеження: «В області розгортання ми бачитимемо розширення  числа місць виявлення вторгнень: на мережному рівні (на міжмережних екранах, на комутаторах, на маршрутизаторах), на рівні операційної системи (на серверах, на робочих станціях) і на прикладному рівні (у СУБД або на сервері SAP, наприклад).» [6]. Завдяки централізації інформації про атаку від різних складових IDS (центральний аналізуючий сервер, агенти мережі, мережні сенсори) така система максимально підсилює захищеність  корпоративної підмережі. На жаль, деякі переваги network-based IDS непридатні до сучасних комутованих мереж в тому випадку, якщо комутатори мережі не надають універсального моніторингу портів – це обмежує діапазон моніторингу сенсора network-based IDS лише одним хостом. Крім того, network-based IDS самі можуть стати предметом атаки DOS, заснованої, наприклад, на сегментації пакетів. Ще один недолік – network-based IDS не можуть аналізувати зашифровану інформацію. Зате hostbased системи можуть компенсувати вищеназвані недоліки, оскільки справляються з проблемою шифрування, на них не впливає наявність комутаторів, проте при цьому вони обмежені ресурсами ОС і використовують частину обчислювальної потужності хостів, за якими вони спостерігають, що впливає на продуктивність спостережуваної системи;

принципів сигналізуючих і експертних систем виявлення вторгнень.

Найбільш поширеним підходом є використання засобів штучного інтелекту (тобто різних адаптивних методів) в комбінації з класичними статичними методами. Найчастіше використовуються нейронні мережі, які добре проявили себе в системах розпізнавання. Рідше – молодші методи теорії імунних систем, можливо в комбінації з нечіткою логікою (НЛ), генетичними алгоритмами, методами нечіткого багатокритеріального ухвалення рішень і чисельними методами оптимізації. Вживання адаптивних методів обумовлене необхідністю налаштування на свій індивідуальний специфічний набір параметрів для кожної системи, що захищається. Поєднання нейронних мереж і інформаційних систем НЛ з одного боку забезпечують можливість навчання, а з іншого – процес вирішення завдань нечыткої логіки системами досить прозорий для пояснення отримуваних виводів [7];

програмного і апаратного рівнів забезпечення захисту інформації. Мережні сенсори, про які вище йшла мова, найчастіше реалізуються апаратно-програмними пристроями відомих фірм – виробників (Cisco). У мережних комутаторах Cisco як сенсор використовується технологія – SPAN - Switch Port Analyzer і RSPAN - Remote Switch Port Analyzer. Вона дозволяє «зеркалювати» трафік з одного порту, на іншій, або наприклад з VLAN вказаного, на порт, де знаходиться аналізатор трафіку, або якесь програмне забезпечення. Ця технологія дозволяє здолати обмеження комутованих мереж для network-based IDS, про які згадувалося вище.

Тому можна виділити наступні найбільш актуальні тенденції розвитку систем виявлення вторгнень.

На рівні виявлення вторгнень. Це, по-перше, розширення спектру підтримуваних прикладних протоколів, особливо з урахуванням розвитку індустрії IP- телефонії, технології VoIP і зростання популярності сервісу Video -On- demand, практично повсюдного використання систем миттєвого обміну повідомленнями. По-друге, додавання підтримки мобільних пристроїв і механізмів аналізу взаємодії з мобільними пристроями. По-третє, більш глибока проробка алгоритмів функціонування вже підтримуваних прикладних протоколів, включаючи механізми  контролю стану  сеансу;  як  наслідок,  підвищення  гнучкості  визначення  факту  вторгнення. І,  по-четверте,  використання  систем  запобігання  вторгнень для запобігання витоку конфіденційної інформації з організації по різних каналах.

На функціональному рівні. Це, по-перше, додавання функцій профілювання трафіку і введення механізмів якості обслуговування на рівні систем запобігання вторгнень. По-друге, розширення можливостей централізованого управління системами запобігання вторгнень. По-третє, розвиток засобів перетворення елементарних подій безпеки в «макро» – події, зручні для оператора.

На рівні інфраструктури IPS. Тут можливі два моменти . По-перше, розширення інтеграції хостових і мережевих систем запобігання вторгнень для поліпшення точності виявлення вторгнень. І, по-друге, розширення можливостей для інтеграції продуктів різних виробників, уніфікація форматів передачі даних і керуючих впливів.

1.3. Порівняльний аналіз систем виявлення вторгнень

До числа популярних систем виявлення вторгнень відносяться наступні:

OSSEC,розробник Daniel B. Sid,OSSEC.net;

STAT, розроблено в університеті University of California at Santa Barbara;

Prelude, розробники Yoann Vandoorselaere та Laurent Oudot;

Snort, розробник Martin Roesch;

Bro, розроблено в університеті University of California, Lawrence Berkeley National Laboratory.

Для порівняльного аналізу даних СВВ було обрано такі критерії:

класи атак;

рівень спостереження за системою;

метод виявлення атак;

адаптивність до невідомих атак;

масштабованість;

відкритість;

реакція на атаку;

захист.

Система Bro використовує регулярні вирази над трасами, які формуються мережевими протоколами. Набір регулярних виразів створюється експертами. Крім того, до складу системи входить транслятор сигнатур з формату системи Snort в сценарії Bro (хоча в даний час цей транслятор підтримує не всі конструкції мови Snort).

Система OSSEC є монолітною - в сенсори і аналізатори «зашиті» знання розробників системи виявлення вторгнень про те, які послідовності повідомлень в журналах можуть бути ознаками атаки. Така архітектура системи є важко розширюваною з точки зору бази знань про атаки.

Система Preludeвикористовує різні аналізуючі компоненти для мережевих даних і журналів реєстрації. Для аналізу мережевих даних можна використовувати систему Snort. Також використовується набір спеціалізованих модулів для виявлення специфічних вторгнень, таких як сканування портів, некоректні ARP-пакети і т.п. Спеціальні модулі проводять дефрагментацію IP, збірку TCP-потоку, декодування HTTP-запитів.

Система Snort використовує базу сигнатур відомих атак. У ній також використовується набір спеціалізованих модулів для виявлення специфічних атак, таких як сканування портів або відправка великого числа фрагментованих пакетів. Спеціальні модулі проводять дефрагментацію IP, декодування HTTP-запитів. Сторонні розробники часто реалізують інші методи виявлення атак у вигляді модулів (препроцесорів) Snort. Але в основну версію системи вони не входять.

Система NetSTAT використовує мову опису сценаріїв атак STATL, особливістю якого є можливість опису сценарію атаки у вигляді послідовності дій над ресурсом, що атакується. Таким чином, ця система використовує метод виявлення, близький до методу аналізу переходів станів.

Клас виявляються атак визначає, які класи атак здатна виявляти розглянута система. Це один з ключових критеріїв, так як сьогодні жодна система не здатна виявляти атаки всіх класів. Тому для більш повного покриття всього спектру атак необхідно комбінувати різні СВВ [8]. Системи, розглянуті в даній роботі, призначені для виявлення атак різних класів. Тому для поліпшення читабельності і скорочення обсягу тексту вводяться поняття об'єднання, перетину і вкладення класів атак. Для позначення об'єднання і перетину класів атак будемо використовувати символи "" і "∩" відповідно. Клас атаки - це четвірка <L,R,A,D>, де L - розташування атакуючого об'єкта, R - ресурс, що атакується, A - цільовий вплив на ресурс, D - ознака розподіленого характеру атаки. L: розташування атакуючого об'єкта. Воно може бути або внутрішнім по відношенню до системи, яку захищають, (li), або зовнішнім (le).R: ресурс, який атакується. Ресурси поділяються по розташуванню і за типом. За розташуванням: вузлові (rl), мережеві (rn). По типу: користувальницькі ресурси (ru), системні ресурси (rs), ресурси СКБД (Rd), обчислювальні ресурси (rc), ресурси захисту (rp). A: цільовий вплив на ресурс: збір інформації (as), отримання прав користувача ресурсу (au), отримання прав адміністратора ресурсу (ar), порушення цілісності ресурсу (ai), порушення працездатності ресурсу (ad). D: ознака розподіленого характеру атаки: розподілені (dd), нерозподілені (dn).

Частина систем, що аналізується орієнтована на виявлення вузлових атак, і використовує для аналізу такі джерела як журнали реєстрації додатків, ОС, журнали систем аудиту (OSSEC). Інші системи виявляють тільки зовнішні (мережеві) атаки і використовують для аналізу інформацію, що отримується з каналів передачі даних у мережі (Bro, Snort). Решта систем є гібридними і виявляють як локальні, так і зовнішні атаки (STAT, Prelude).

Система Bro є мережевою системою виявлення вторгнень. Вона являє собою набір модулів декомпозиції даних різних мережевих протоколів (від мережевого до прикладного рівня) і набір сигнатур над подіями відповідних протоколів. Сигнатури Bro фактично являють собою регулярні вирази в алфавітах протоколів.

Дана система виявляє вторгнення наступних класів (L, R, A, D):

L = {li le} (внутрішні та зовнішні атаки);

R = {rn} ∩ {ru rs} (атаки на мережеві користувальницькі ресурси і системні ресурси);

A = {as au ar ad} (збір інформації про систему, спроби отримання прав користувача, спроби отримання прав адміністратора і порушення працездатності ресурсу);

D = {dn dd} (нерозподілені та розподілені).

Система OSSEC, єдина з розглянутих в даній роботі, є спочатку орієнтованою на виявлення атак рівня системи (вузлових). Вона найбільш «молода» з розглянутих систем; її остання версія призначена, зокрема, для аналізу журналів реєстрації UNIX, типових додатків (ftpd, apache, mail, etc), а також журналів міжмережевих екранів і мережевих СВВ. OSSEC включає в себе набір аналізаторів для різних джерел даних, контроль цілісності файлової системи, сигнатури відомих троянських закладок (rootkits).

Виявляються атаки наступних класів:

L = {li} (атакуючі об'єкти знаходяться всередині системи);

R = {rl} ∩ {ru rs} (вузлові користувальницькі та системні ресурси);

A = {au ar ai} (спроби отримання прав користувача, спроби отримання прав адміністратора, порушення цілісності ресурсу);

D = {dn dd} (нерозподілені та розподілені).

Система STAT є експериментальною університетською розробкою, і найбільш «старою» з розглянутих систем - перші публікації про STAT датуються 1992 роком. Система включає в себе набір компонентів виявлення атак різних рівнів - мережевий (NetSTAT), вузловий (USTAT, WinSTAT), додатків (WebSTAT), тобто є класичною гібридною системою. СВВ виявляє вторгнення наступних класів: (L, R, A, D). Де:

L = {li le} (внутрішні та зовнішні атаки);

R = {rl rn} ∩ {ru rs} (атаки на вузлові або мережеві користувальницькі ресурси і системні ресурси);

A = {as au ar ad} (збір інформації про систему, спроби отримання прав користувача, спроби отримання прав адміністратора і порушення.

Система Prelude, є гібридною, тобто здатна виявити атаки як на рівні системи, так і на рівні мережі. Дана система спочатку розроблялася в якості самостійної СВВ, але в даний час є високорівневою надбудовою над відкритими СВВ і системами контролю цілісності (AIDE, Osiris тощо). Вузлова частина Prelude має досить широкий набір описів атак і, як джерело інформації, використовує різні журнали реєстрації:

журнали реєстрації брандмауера IPFW;

журнали реєстрації NetFilter ОС Linux;

журнали реєстрації маршрутизаторів Cisco and Zyxel;

журнали реєстрації GRSecurity;

журнали реєстрації типових сервісів OC UNIX та інші.

СВВ виявляє атаки наступних класів: (L, R, A, D). Де:

L = {li le} (внутрішні та зовнішні атаки);

R = {rl rn} ∩ {ru rs rp} (атаки на локальні чи мережеві користувальницькі ресурси, системні ресурси і ресурси захисту);

A = {as au ar ad} (збір інформації про систему, спроби отримання прав користувача, спроби отримання прав адміністратора і порушення працездатності ресурсу);

D = {dn} (нерозподілені).

Система Snort це найбільш популярна на сьогоднішній день некомерційна СВВ. Вона активно і динамічно розвивається, оновлення бази відомих атак відбуваються з частотою, яка порівнюється з комерційними аналогами (зазвичай поновлення Snort випереджають комерційні). Snort є чисто мережевою СВВ і, крім основної бази описів атак, має набір модулів для виявлення специфічних атак або реалізують альтернативні методи виявлення.

Система здатна виявити атаки наступних класів (L, R, A, D):

L = "внутрішні" "зовнішні";

R = {rl rn} ∩ {ru rs rp} (атаки на локальні чи мережеві користувальницькі ресурси, системні ресурси і ресурси захисту);

A = {as au ar ad} (збір інформації про систему, спроби отримання прав користувача, спроби отримання прав адміністратора і порушення працездатності ресурсу);

D = {dn dd} (нерозподілені та розподілені).

Жодна з розглянутих систем не покриває всю безліч класів атак. Слід також зазначити, що ці системи використовують не адаптивні методи виявлення вторгнень.

Рівень спостереження за системою визначає, на якому рівні система, що захищається збирає дані для виявлення атаки. Розрізняються системні і мережеві джерела. Усі розглянуті вище системи працюють з даними додатків та операційної системи на вузловому рівні , а також з мережевими даними, тобто інформація, що аналізується виходить з вторинних джерел, таких як журнали реєстрації додатків, ОС, або з мережевого каналу передачі даних. Система OSSEC працює виключно з журналами реєстрації додатків і операційної системи. Системи Bro, Snort аналізують тільки мережеві дані. Системи NetSTAT і Prelude аналізують як дані з локальних системних джерел, так і мережеві дані.

Адаптивність до невідомих атакам визначає, чи дозволяє використовуваний метод виявляти раніше невідомі атаки. На даний момент ця можливість в розглянутих СВВ відсутня. Можливе використання експериментального модуля статистичного аналізу системи Snort, але його ефективність не вивчена. За рахунок контролю цілісності ресурсів вузла в OSSEC присутня умовна адаптивність. Проте, слід визнати, що контроль цілісності вирішує не завдання виявлення атак, а лише завдання виявлення їх наслідків.

Масштабованість являє собою організацію управління системою та розподіленість архітектури системи виявлення вторгнень. Дані СВВ, за винятком Bro є добре масштабованими.

Відкритість визначає, наскільки система є відкритою для інтеграції в неї компонентів сторонніх розробників і для сполучення її з іншими системами захисту інформації. Три  з  розглянутих систем, за винятком Bro і OSSEC, мають відкритий інтерфейс для додавання нових аналізують модулів, а також використовують стандартний для систем виявлення атак формат обміну повідомленнями (IDMEF). NetSTAT має відкритий інтерфейс для додавання нових агентів і фільтрів. Prelude має відкритий інтерфейс для додавання нових модулів аналізу та реагування, а так само ведення журналів реєстрації. Обмін повідомленнями між компонентами системи відбувається за стандартом IDMEF (Intrusion Detection Message Exchange Format), оптимізованому для високошвидкісної обробки. Snort має відкритий інтерфейс для додавання нових модулів аналізу; є модуль, який реалізує протокол SNMPv2.

Вбудовану можливість реагування на атаку мають всі розглянуті системи. В системі NetSTAT це реалізовано лише в тестовому варіанті. Система Prelude має набір агентів у відповідь реакції, які можуть блокувати атакуючого за допомогою брандмауера. Ведуться роботи по агентам, здатним або повністю ізолювати атакуючого, або зменшити пропускну здатність його каналу. Система Snort має вбудовану обмежену можливість реагування на атаку шляхом відправки TCP - пакетів, що розривають з'єднання (з встановленим прапором RST), а також ICMP- пакетів, які повідомляють атакуючому вузлу про недоступність вузла, мережі або сервісу. Аналогічна функціональність з реагування доступна в системі Bro. Система OSSEC дозволяє використовувати довільні команди для реагування – для цього необхідно статично задати відповідність між подією, командою і параметрами її виклику.

Захищеність. Всі системи, які пересилають які-небудь дані, використовують для цього захищені канали. STAT і Prelude використовують бібліотеку OpenSSL для шифрування каналу між компонентами. Snort реалізує протокол SNMPv2, в якому присутні функції шифрування паролів при передачі даних. СВВ Prelude має додаткові механізми, що забезпечують безпеку її компонентів. У системі використовується спеціалізована бібліотека, яка робить безпечними такі бібліотечні функції алгоритмічної мови С як printf, strcpy, які не перевіряють розмір переданих ним даних. Додаткові модулі аналізу мережевих даних роблять систему стійкою до некоректних мережевих пакетів на різних рівнях стека і виходу її компонентів з ладу. Такі атаки, як відправка пакетів з неправильними контрольними сумами, обнуленими прапорами TCP, ресинхронізація сесій, випадкова відправка і «обрізання» сегментів системою ігноруються. З розглянутих систем питання безпеки найбільш опрацьований у системі Prelude.

Таким чином, якась «ідеальна» СВВ володіє такими властивостями:

покриває всі класи атак (система повна);

дозволяє аналізувати поведінку РІС, яку захищає на всіх рівнях: мережевому, вузловому і рівні окремих додатків;

адаптивна до невідомих атакам ( використовує адаптивний метод виявлення атак);

масштабується для РІС різних класів: від невеликих локальних мереж класу «домашній офіс» до великих багатосегментних і комутованих корпоративних мереж, забезпечуючи можливість централізованого управління всіма компонентами СВВ;

є відкритою;

має вбудовані механізми реагування на атаки;

є захищеною від атак на компоненти СВВ, у тому числі від перехоплення управління або атаки «відмова в обслуговуванні».

В таблиці 1.1. наведено характеристики провідних систем виявлення вторгнень. На підставі проведеного порівняльного аналізу можна зробити висновок, що жодна з розглянутих вище відкритих СВВ, не відповідає повною мірою критеріям «ідеальної» СВВ.

Основним недоліком є відсутність адаптивності до невідомих атакам і неможливість аналізувати поведінку об'єктів РІС на всіх рівнях одночасно. З розглянутих систем жодна не покриває всі рівні спостереження, та інформація,що аналізується кожною системою неповна з точки зору можливості виявлення атак усіх класів.

Таблиця 1.1

Порівняльна характеристика провідних систем виявлення вторгнень

Bro

OSSEC

STAT

Prelude

Snort

1

2

3

4

5

Клас виявлення атак

({li le},

{rl} ∩ {ru rs rc},

{as au ar ad},

{dn})

мережеві атаки

({li },{rl} ∩ {ru rs},

{au ar ai}, {dn})

вузлових атак

({li le},

{rl rn) ∩  (ru rs},

{as au  ar ad},

{dn})

локальні і зовнішні атаки

({li le},

{rl rn) ∩ {ru rs

rp},

{as au ar ad},

{dn dd})

локальні і зовнішні атаки

({li le},

{rl rn) ∩ {ru rs rp},

{as au ar ad},

{dn})

мережеві атаки

Рівень спостереження за системою

Системний

Системний

Системний, мережевий

Системний, мережевий

Мережевий

Метод виявлення атак

Сигнатурний

Сигнатурний

Сигнатурний

Сигнатурний

Сигнатурний

Адаптивність

-

+/-

-

-

-

Реакція

-

-

+

+

+

Захист

-

-

SSL

SSL, Libsafe

-

Масштабованість

-

+

+

+

-

 Продовження таблиці 1.1

1

2

3

4

5

Відкритість

Відкритий API

Відкритий API

Відкритий API

Відкритий API,

IDMEF

Відкритий APISNMPv2

На даний момент найбільш сприятлива система виявлення вторгнень – це Prelude, яка дозволяє забезпечити аналіз як даних з локальних системних джерел, так і мережевих даних, має додаткові механізми, що забезпечують безпеку її компонентів. З усіх розглянутих в даній роботі систем, система Prelude має найменше недоліків як в архітектурі, так і в реалізації. Вона потребує постійного оновлення бази знань про атаки описами нових атак, які виробляються експертами, тобто в даній системі відсутня адаптивність до невідомих атак.

Водночас, зважуючи на переваги зазначеної системи над іншими, слід відмітити, що ця IDS в останні роки практично не розвивається. Система проста в налаштуванні і обслуговуванні, проте в ній досить багато доводиться налаштовувати «руками», без зручного графічного інтерфейсу, що в свою чергу призводить до того що система не може бути використана оператором з низькою кваліфікацією і вимагає спеціальних знань та навчання. А також на сьогоднішній день атака триває не більше декількох секунд і може завдати дуже чутливу шкоду ІМ, тому адміністратор безпеки вимушений оперативно приймати рішення стосовно дій СВВ, що не дає змогу зробити виведення інформації в командний рядок, оскільки аналіз отриманих даних займає дуже багато часу. «Ручний» аналіз не дозволить своєчасно виявити і запобігти багатьом атакам.

Тому доцільно удосконалити роботу системи Prelude за рахунок розробки підсистеми графічної  взаємодії користувача з системою та впровадженням в процес діяльності адміністратора безпеки методів інтелектуального аналізу даних, які збирає Prelude.

  1.   Аналіз функціональних можливостей системи виявлення вторгнень Prelude та обгрунтування вибору системи виявлення вторгнень

Система Prelude є системою з відкритими вихідними текстами. початок  розробки – 1998 рік. Вона спочатку замислювалася як гібридна СВВ, яка могла б допомогти адміністратору мережі відстежувати активність як на рівні мережі, так і на рівні окремих вузлів. Система розподілена і складається з наступних компонентів [8]:

мережеві сенсори – різні сенсори, що аналізують дані на рівні мережі на основі сигнатурного аналізу. Сенсори генерують повідомлення про виявлення атак і відправляють їх модулям управління. Система Prelude використовує в якості мережевого сенсора систему Snort;

вузлові сенсори – різні сенсори рівня системи, що аналізують журнали реєстрації ОС, додатків. Сенсори генерують повідомлення про виявлення аномалій і відправляють їх модулям управління. Існуючий набір сенсорів дозволяє аналізувати дані журналів реєстрації таких систем і додатків, як міжмережевий екран IPFW, що входить до складу ОС FreeBSD, NetFilter ОС Linux 2.4.x, маршрутизатори Cisco і Zyxel, GRSecurity, і типові сервіси операційної системи UNIX;

модулі управління – процеси , які отримують і обробляють повідомлення сенсорів. Розрізняють наступні види модулів управління:

модулі журналізації – відповідають за реєстрацію повідомлень в журналах реєстрації або базах даних. В даний час реалізовані модулі для MySQL, PostgreSQL;

модулі реагування – аналізують повідомлення і генерують можливу відповідну реакцію СВВ на атаку. Можливі такі види реакції як блокування порушника на міжмережевому екрані (NetFilter, IPFilter). Надалі можливі такі типи реакції як ізоляція порушника і звуження пропускної здатності каналу порушника;

агенти реагування – реалізують згенеровану менеджером реакцію на атаку інформаційної мережі [9].

Налаштування Prelude здійснюється через інтерфейс командного рядка.

Взаємодія компонентів системи вказана на рисунку 1.3.

Рис.1.3. Архітектура системи виявлення вторгнень Prelude

Пропонується, досить гнучка система конфігурації і широкі можливості налаштувань. При першому знайомстві з програмою, система налаштування дається не відразу, але при подальшому знайомстві з налаштуваннями і документацією по ним, як виявилося не є дуже складною і відкриваються широкі можливості моніторингу. Оскільки ця IDS в останні роки практично не розвивається, то на даний момент «web-візуалізація» для конфігурації від розробників відсутня, але є варіанти розроблені сторонніми програмістами.

IDS Prelude дозволяє:

реагувати в режимі реального часу на внутрішні і зовнішні загрози;

збирати, аналізувати і готувати звіти про стан РІС;

проаналізувати дані, які стосуються безпеки подій;

сприяти дотриманню нормативних вимог;

уникнути пошкодження даних і ресурсів компанії;

забезпечити сумісність внутрішніх та зовнішніх політик безпеки;

отримувати інформацію про потенційні загрози і підозрілі події в ІМ;

негайно встановити причинно-наслідкові зв'язки між інформацією і подіями та їх наслідками;

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

На рисунку 1.4 представлена логічна схема з'єднання компонентів системи виявлення вторгнень Prelude.

У системи Prelude є кілька особливостей, які відрізняють її від інших сучасних відкритих СВВ. Система скрізь, де можливо, побудована на використанні відкритих стандартів. Так, для обміну повідомленнями використовується формат IDMEF ( Intrusion Detection Message Exchange Format), оптимізований для високошвидкісної обробки. Це дозволяє надалі інтегрувати компоненти в системи сторонніх виробників і навпаки.

При розробці системи особлива увага була приділена питанням безпеки.

Канали передачі даних шифруються по протоколу SSL, крім того, використовується спеціалізована бібліотека, яка запобігає класичні помилки виходу за межі масивів та переповнення буферів.

Додаткові модулі аналізу мережевих даних роблять систему стійкою до некоректних мережевих пакетів на різних рівнях стека і виходу її компонентів з ладу. Такі атаки як відправка пакетів з неправильними контрольними сумами, обнуленими прапорами TCP, ресинхронізація сесій, випадкова відправка і «обрізання» сегментів системою ігноруються і не призводять до відмови компонентів системи виявлення вторгнень.

Механізми виявлення вторгнень, реалізовані в системі Prelude:

відстеження процесів, які запускаються шляхом аналізу журналів ОС;

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

відстеження мережевого трафіку.

Відстеження операцій з файловою системою і реєстром в системі Prelude не реалізовано.

Отже, в якості системи виявлення вторгнень, було обрано систему Prelude, яка є найбільш сприятливою для роботи через свої широкі можливості. З усіх розглянутих в даній роботі систем, система Prelude дозволяє забезпечити аналіз як даних з локальних системних джерел, так і мережевих даних, має додаткові механізми, що забезпечують безпеку її компонентів, а також має найменше недоліків як в архітектурі, так і в реалізації. Дана система побудована на використанні відкритих стандартів, що дає змогу надалі інтегрувати компоненти сторонніх виробників і навпаки.

Рис.1.4 Логічна структура СВВ Prelude.

  1.   Постановка задачі дослідження

Таким чином, постановка задачі дослідження полягає у наступному:

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

необхідно: розробити спеціальне програмне забезпечення у вигляді інтерфейсного модулю взаємодії користувача з системою виявлення вторгнень Prelude та впровадженням в процес діяльності адміністратора безпеки методів інтелектуального аналізу даних, які збирає СВВ.

Висновки

Отже, системи виявлення комп'ютерних вторгнень є одним з найважливіших елементів систем інформаційної безпеки інформаційної мережі органу військового управління, враховуючи, як зростає в останні роки число проблем, пов'язаних з комп'ютерною безпекою. IDS являють собою спеціалізовані програмно-апаратні комплекси, призначені для виявлення інформаційних атак в ІС. Аналіз показав, що до основних задач системи виявлення вторгнення можна віднести задачі, що вирішують питання своєчасної та достовірної ідентифікації виникнення помилок, нестандартних чи конфліктних ситуацій. Проведено аналіз наступних програмних продуктів виявлення комп’ютерних вторгнень: OSSEC, розробником якої є Daniel B. Sid, STAT, розробленої в університеті University of California at Santa Barbara, Prelude, розробниками якої є Yoann Vandoorselaere та Laurent Oudot, Snort, розробної Martin Roesch, Bro, розробленої в університеті University of California, Lawrence Berkeley National Laboratory. Жодна з розглянутих вище відкритих СВВ, не відповідає повною мірою критеріям «ідеальної» СВВ. Основним недоліком є відсутність адаптивності до невідомих атакам і неможливість аналізувати поведінку об'єктів РІС на всіх рівнях одночасно. На даний момент найбільш сприятлива система виявлення вторгнень – це Prelude.

Тому, підвищення ефективності діяльності адміністратора безпеки інформаційних мереж є можливим, шляхом розробки підсистеми графічної  взаємодії користувача з СВВ Prelude.

Застосування даного підходу надасть змогу ефективно аналізувати дані про вторгнення до інформаційної мережі в більш прийнятний термін, з метою своєчасного прийняття необхідних заходів для їх усунення або зменшення можливої шкоди.


  1.  ПРОЕКТУВАННЯ ПІДСИСТЕМИ (ПРОГРАМНОГО МОДУЛЮ)

  1.  Формування та аналіз вимог до підсистеми (програмного модулю), що  розробляється

  1.  Вимоги до програмного забезпечення підсистеми

Вимоги до програмного забезпечення серверної частини.

Для функціонування підсистеми необхідно наступне програмне забезпечення:

Операційна система CentOS 6 x86_64, Fedora, Debian, Ubuntu, FreeBSD, Mac OSX, NetBSD, OpenBSD, Solaris;

Веб-сервер - Apache версії не нижче 1.3.26;

СУБД - MySQL версії не нижче 4.0.18.

Вимоги до клієнтського програмного забезпечення.

Web-інтерфейс СВВ Prelude повинен бути доступний для повнофункціонального перегляду за допомогою наступних щих браузерів:

Microsoft IE;

Firefox;

Opera;

Safari;

Google Chrome;

та інші webkit браузери.

  1.  Вимоги до технічного забезпечення підсистеми

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

Процесор - Intel Pentium III 1 ГГц;

Оперативна пам'ять - 512 Мб оперативної пам'яті;

Жорсткий диск - 20 Гб місця на HDD.

Серверне, комп'ютерне та мережне обладнання повинно бути оснащене джерелами безперебійного живлення, здатними підтримати працездатність комплексної системи для безпечного завершення роботи.

  1.  Аналіз задач і функцій, які повинна вирішувати підсистема та

проектування структури підсистеми

Адміністратори безпеки використовують IDS, як інструмент управління безпекою ІМ, тому доцільно для полегшення роботи та пришвидшення реагування на події в СВВ використовувати методи візуалізації даних для покращення аналізу інформації. Візуальне представлення даних є набагато інформативнішим за інші методи отримання та сприйняття інформації, більш зручним і легшим для сприйняття та розуміння ніж наприклад представлення даних у таблицях, схемах, математичних матрицях, або просто в числах.

Людина має винятковий візуальний інтелект, який може розпізнавати об'єкти і моделі легше, ніж згадуючи їх, без підказки, з пам'яті [10, 11]. Завдяки цьому можливо зменшити навантаження на адміністратора безпека, за рахунок непотрібності пам’ятати неважливі деталі.

Інтерфейс, який дозволяє адміністраторові швидко інтерпретувати підозрілі мережеві події, в контексті великого набору таких подій, сприятиме виявленню істинного рівня загрози.

З точки зору мережевого адміністратора безпеки, є величезна кількість даних, отриманих навіть невеликими мережами і підмережами. Майже неможливим є перевірка всіх звітів, журналів, встановлення конфігураційних файлів, підтримка цілісності ситуаційної обізнаності в реальному часі. На додаток до звичайних журналів і звітів, системи IDS мають тенденцію генерувати величезну кількість помилкових спрацьовувань, і всі вони заслуговують на увагу адміністратора безпеки.

Рис.2.1. Звіт сигналізації СВВPrelude

На рис.2.1 представлено знімок екрана з доповіді сигналізації системи виявлення вторгнень Prelude. Хоча це докладний звіт, що забезпечує достатньо інформації для того, щоб дослідити і вирішити проблему. Але це трудомісткий рутинний процес, щоб переглянути його вручну. Виходячи з цього можна зробити висновок, що ця інформація повинна бути показана по-іншому, за допомогою засобів візуалізації [11, 12].

Візуалізація зазвичай не пов'язана з мережевою безпекою, але це хороший спосіб зрозуміти та проаналізувати велику кількість мережевих даних. Різні методи візуалізації можуть бути використані для формування зображення в цілому, управління безпекою, розуміння поточної ситуації швидко і легко.

Під час визначення структури підсистеми взаємодії адміністратора безпеки з системою необхідно провести аналіз вимог та задач, які вона має вирішувати, розробити архітектуру підсистеми, обґрунтовано обрати алгоритми їх реалізації, а також визначити комплекс програмно-технічних засобів. Структура вважатиметься оптимальною, якщо загальна ефективність системи, що проектується є максимальною [10,14].

Процес проектування оптимальної структури підсистеми взаємодії адміністратора безпеки з системою ІМ включає послідовне рішення задач синтезу основних елементів та частин системи.

На першому етапі визначається організаційна структура системи, виходячи з цілей та стратегій функціонування ІМ. На другому етапі, обирається метод візуалізації в залежності від функцій, які вони повинні виконувати та комплекс програмних та технічних засобів для реалізації підсистеми [13].

Графічний інтерфейс адміністратора безпеки об’єднує в собі всі елементи та компоненти системи виявлення вторгнень, які впливають на взаємодію адміністратора безпеки з системою та виконує функції: навігації між блоками системи, відображення інформації про поточний стан системи, зворотний зв’язок з адміністратором безпеки, підтримку прийняття рішень при реагуванні на події в системі.

Основними методами візуалізації, які можуть бути використані в графічному інтерфейсі системи виявлення атак Prelude є: гістограми, лінійні графіки, графіки посилання, діаграми розсіювання та використання кольорів у вигляді графіків [15]. Дані методи дозволяють забезпечити якийсь обов'язковий набір «умінь», яким обов'язково повинна володіти підсистема взаємодії адміністратора безпеки з системою виявлення вторгнень Prelude, згідно з тенденціями сьогоднішнього дня:

завдання шаблонів фільтрації трафіку;

централізоване управління модулями стеження;

фільтрація мережевого трафіку по протоколу, портам і IP- адресами відправника і одержувача;

аварійне завершення з'єднання з атакуючим вузлом;

управління міжмережевим екранами і маршрутизаторами;

завдання сценаріїв з обробки атак;

запис атаки для подальшого відтворення та аналізу;

потужна система генерація звітів;

вміти створювати звіти: розподілення трафіку по користувачам, протоколах, типу даних, часу доби, днях тижня, датах та місяцями;

входи і виходи з системи.

Запропонована архітектура системи виявлення атак Prelude представлена на рис.2.2, де модуль візуалізації результатів функціонування має вигляд вказаний на рис. 2.3 [5].

Рис.2.2. Загальна архітектура системи виявлення атак Prelude з

розроблюваною підсистемою

Процес візуалізації результатів функціонування інформаційної мережі включає наступні етапи:

визначення проблеми;

доступ до наявних даних;

обробка інформації;

візуальна трансформація інформації;

перетворення виду;

інтерпретування і прийняття рішення.

Рис.2.3. Структурна схема модуля візуалізації результатів функціонування

Вхідна інформація поступає від датчиків моніторингу стану ІМ, потім проходить первинну обробку у блоці збору даних та їх первинного аналізу. Далі реєструються події в системі виявлення вторгнень, які за допомогою обраних методів візуалізації відображаються в блоці взаємодії адміністратора безпеки з системою та зберігаються в відповідній базі даних.

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

  1.   Обґрунтування вибору програмного середовища та мови

програмування для розробки підсистеми

Python – інтерпретована об'єктно-орієнтована мова програмування високого рівня з динамічною семантикою. Розроблена в 1990 році Гвідо ван Россумом. Структури даних високого рівня разом із динамічною семантикою та динамічним зв'язуванням роблять її привабливою для швидкої розробки програм, а також як засіб поєднання існуючих компонентів. Python підтримує модулі та пакети модулів, що сприяє модульності та повторному використанню коду. Інтерпретатор Python та стандартні бібліотеки доступні як у скомпільованій так і у вихідній формі на всіх основних платформах. В мові програмування Python підтримується декілька парадигм програмування, зокрема: об'єктно-орієнтована, процедурна, функціональна та аспектно-орієнтована.

Серед основних її переваг можна назвати такі:

чистий синтаксис (для виділення блоків слід використовувати відступи);

переносимість програм (що властиве більшості інтерпретованих мов);

стандартний дистрибутив має велику кількість корисних модулів (включно з модулем для розробки графічного інтерфейсу);

можливість використання Python в діалоговому режимі (дуже корисне для експериментування та розв'язання простих задач);

стандартний дистрибутив має просте, але разом із тим досить потужне середовище розробки, яке зветься IDLE і яке написане на мові Python;

зручний для розв'язання математичних проблем (має засоби роботи з комплексними числами, може оперувати з цілими числами довільної величини, у діалоговому режимі може використовуватися як потужний калькулятор).

Python має ефективні структури даних високого рівня та простий, але ефективний підхід до об'єктно-орієнтованого програмування. Елегантний синтаксис Python, динамічна обробка типів, а також те, що це інтерпретована мова, роблять її ідеальною для написання скриптів та швидкої розробки прикладних програм у багатьох галузях на більшості платформ.

Інтерпретатор мови Python і багата стандартна бібліотека (як вихідні тексти, так і бінарні дистрибутиви для всіх основних операційних систем) можуть бути отримані з сайту Pythonwww.python.org, і можуть вільно розповсюджуватися. Цей самий сайт має дистрибутиви та посилання на численні модулі, програми, утиліти та додаткову документацію.

Інтерпретатор мови Python може бути розширений функціями та типами даних, розробленими на C чи C++ (або на іншій мові, яку можна викликати із C). Python також зручна як мова розширення для прикладних програм, що потребують подальшого налагодження. Python портований та працює майже на всіх відомих платформах – від ПК до мейнфреймів. Існують порти під Microsoft Windows, всі варіанти UNIX (включаючи FreeBSD та GNU/Linux), Plan 9, Mac OS та Mac OS X, iPhoneOS 2.0 і вище, Palm OS, OS/2, Amiga, AS/400 та навіть OS/390, Symbian та Android.Python – стабільна та поширена мова. Він використовується в багатьох проектах та в різних якостях: як основна мова програмування або для створення розширень та інтеграції застосувань. На Python реалізована велика кількість проектів, також він активно використовується для створення прототипів майбутніх програм.

Потужність і гнучкість мови програмування Python це його найбільша перевага від інших мов [16].

Отже, Python має простий і ясний синтаксис, його бібліотеки містять лаконічну документацію, а процес тестування та кодування - досить комфортний. Перенесення коду з однієї платформи на іншу – майже безболісний.

Для розробри підсистеми взаємодії адміністратора безпеки з системою виявлення вторгнень Prelude було обрано програмне середовище Virtual Studio з безкоштовним розширенням Python Tools for Virtual Studio (PTVS) як Integrated Development Environments (IDE) для Python.

Visual Studio  допомагає писати код швидше, підтримуючи безліч засобів і можливостей, які підвищують продуктивність праці: технологію IntelliSense, автозавершення операторів, автоматичне виділення кольором синтаксичних конструкцій, пошук методів, перевірку синтаксису і типів, оптимізацію (рефакторінг) коду, управління фрагментами коду і багато іншого.

Пакет PTVS додає в IDE VS можливість повноцінної підтримки мови програмування Python, редагування коду з підсвічуванням, навігацією по коду, налагодженням, профілюванням і т.п. Virtual Studio у поєднанні PythonTools становить повноцінне безкоштовне середовище розробки на мові Python. Вибором PTVS для розробки підсистеми також послужила його відносна простота в установці та налаштуванні.

PTVS підтримуємо практично всі реалізації Python в тій чи іншій мірі - CPython, IronPython, Jython, PyPy, Stackless - але пріоритетним є підтримка стандартного, і використовуваного більшістю розробників інтерпретатора CPython.

  1.  Проектування бази даних підсистеми

  1.  Обґрунтування вибору моделі «сутність-зв'язок»

Основою бази даних є модель даних – фіксована система понять і правил для представлення даних структури, стану і динаміки проблемної області в базі даних.  Подання інформації про предметну область пов'язане з моделюванням даних. Нині існують різні моделі даних зі своїми перевагами й недоліками, і кожна з них має сферу застосування.

Дослідження в галузі моделювання даних розпочались у 80-ті рр. минулого сторіччя, коли Е. Кодд уперше ввів поняття моделі даних [17]. Моделі даних за можливостями побудови опису предметної області в термінах, близьких до термінів предметної області, можна поділити на дві групи. До першої належать універсальні моделі даних: ієрархічна, мережева, реляційна, об'єктно-орієнтована, що дозволяють розв'язувати широке коло задач, але елементи даних цих моделей мають порівняно малу інформативність. До другої групи належать моделі, що забезпечують подання інформації на рівні, близькому до уявлень спеціалістів предметної області, яких не цікавлять способи подання даних та їх взаємозв'язків. Моделі другої групи використовують для побудови концептуальних моделей, які потім можна транслювати в моделі першої групи. До даної групи можна віднести, наприклад, модель "сутність-зв'язок" [18], семантичну об'єктну модель. Однією з найпопулярніших концептуальних мод модель "cутність-зв'язок",  або ER-модель (англ. – Entity Relationship model). На використанні різновидів даної моделі базуються більшість сучасних підходів до проектування моделей даних (головним чином – реляційних або об'єктно-орієнтованих). Модель "сутність-зв'язок" є простою візуальною моделлю даних (графічною нотацією). Можна провести аналогію між елементами реляційної моделі даних і елементами моделі «сутність–зв’язок». Реляційні відносини відповідають наборам сутностей, а кортежі – сутностям. Тому, також як і в моделі «сутність–зв’язок» стовпці в таблиці, що представляє реляційне відношення, називають атрибутами.

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

Іменоване безліч пар «ім’я атрибута – ім’я домену» називається схемою відношення. Потужність цієї множини – називають ступенем чи «арністю» відносини. Набір іменованих схем відносин представляє із себе схему бази даних.

Атрибут, значення якого однозначно ідентифікує кортежі, називається ключовим (або просто ключем). У нашому випадку ключем є атрибут «Табельний номер», оскільки його значення унікально для кожного працівника підприємства. Якщо кортежі ідентифікуються тільки зчепленням значень декількох атрибутів, то говорять, що відношення має складовий ключ. Ставлення може містити кілька ключів. Завжди один із ключів оголошується первинним, його значення не можуть обновлятися. Всі інші ключі відносини називаються можливими ключами.

Модель "сутність-зв'язок" – це модель даних, що використовується при проектуванні різноманітних моделей (інформаційних систем, баз даних, архітектур комп'ютерних додатків та інших систем) і є високорівневою концептуальною моделлю. Вона ґрунтується на деякій важливій семантичній інформації про реальний світ і є графічною нотацією, за допомогою якої можна описувати об'єкти логічних моделей даних і відношення між об'єктами. У даному контексті модель "сутність-зв'язок" є мета моделлю даних, тобто засобом специфікації логічних моделей даних, що будуються на основі вихідної концептуальної моделі даних. Модель "сутність-зв'язок" використовують при концептуальному моделюванні для отримання концептуальної моделі, яку потім транслюють у логічні моделі, зазвичай реляційні або об'єктно-орієнтовані [19]. Модель "сутність-зв'язок" запропонував П. Чен із метою впорядкування задачі проектування моделей, її проект був опублікований у 1976 р.[20]. Дана модель задовольняє дві важливі умови:

потужність її засобів дозволяє досить адекватно описувати структуру різноманітних предметних областей;

розрив між можливостями моделі та CASE-засобів (Computer Aided Sof ftware Engineering1), що її підтримують, не надто великий.

На сьогодні не існує єдиного загальноприйнятого стандарту для моделі "сутність-зв'язок", але є набір загальних конструкцій, що лежать в основі більшості її варіантів. Така ситуація виникла через те, що різні автори пропонують свої елементи моделі й відповідну термінологію.

Базовими елементами моделі "сутність-зв'язок" є сутності, атрибути і зв'язки. У цьому підрозділі розглядаються й уточнюються дані елементи. З об'єктами моделі "сутність-зв'язок" пов'язані поняття: тип – набір однорідних предметів, явищ, що виступають як єдине ціле; екземпляр – конкретний елемент набору, який (набір) визначає деякий тип; множина – конкретний набір екземплярів типу в деякий момент часу.

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

Виходячи з наведеного зробити висновок, що найбільш сприятлива модель подання даних в розроблюваній базі даних є модель «сутність – зв'язок», яка є простою, доступною для розуміння розробника і користувача та збільшує швидкість розробки поставленої задачі оперативного аналізу.

  1.  Обґрунтування вибору системи керування базами даних

Без використання баз даних не обходиться створення практично жодного динамічного web-додатку. Всі сучасні системи управління контентом (CMS) працюють з використанням баз даних. При комп'ютерній обробці інформації впорядковані-якимось чином дані прийнято зберігати в базах даних. База даних являє собою набір інформації, організованої тим чи іншим способом. У базі даних можуть зберігатися тексти статей, посилання на графічні файли, аудіо, відео і т.д. Для роботи з базами даних передбачено спеціальне програмне забезпечення - СКБД, яке використовуються для зберігання і обробки великих обсягів інформації: додавання інформації, її редагування, перегляд, копіювання, видалення, пошук, сортування і т.д. [21]. MySQL - це система керування реляційними базами даних. До відмінних рис фізичної організації збереження і обробки даних, наявними в СКБД MySQL, можна віднести наступні:

програмний код написаний на мові С + +;

СКБД MySQL є кросплатформеним додатком з інтерфейсами С, C + +, Eiffel, Java, Perl, PHP, Python, Ruby і Tel.

можливість роботи в багатопроцесорних системах;

забезпечення транзакційних і нетранзакційних механізмів зберігання;

використання дуже швидких дискових таблиць (MylSAM) із стисненням індексів на основі бінарних дерев (В-дерев);

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

швидкодію системи розподілу пам'яті, заснованої на потоках;

можливість зберігання в пам'яті хеш-таблиць як тимчасових;

функції SQL реалізовані з використанням високо оптимізованої бібліотеки класів і повинні виконуватися гранично швидко. Як правило, будь-якого розподілу пам'яті після ініціалізації запиту не виконується;

код MySQL протестований за допомогою інструментів пошуку витоку пам'яті;

сервер доступний як окрема програма для використання в клієнт-серверної мережевий середовищі. Крім того, він також поставляється у вигляді бібліотеки, яка може бути вбудована в окремі автономні програми. Такі програми можуть застосовуватися в ізольованому середовищі або середовищі, що не має доступу до мережі;

На синтаксичному рівні даних виділяються наступні переваги:

безліч типів даних для стовпців таблиць: знакові табез знакові, цілі і просторові типи OpenGIS;

записи фіксованої і змінної довжини;

повна підтримка операцій і функцій в конструкціях SELECT і WHERE запитів, підтримка псевдонімів для таблиць і стовпців, як вимагає стандарт SQL.

повна підтримка конструкцій GROUP BY і ORDER BY. Підтримка групових функцій (COUNT (), COUNT (DISTINCT ), AVG (), STD (), SUM (), ІGROUP_CONCAT () MAX (), MIN (),);

підтримка LEFT OUTER JOIN і RIGHT OUTER JOIN як з синтаксисом SQL, так і з синтаксисом ODBC;

оператори DELETE, insert, REPLACE і UPDATE повертають кількість рядків, які були змінені. Авангард-чемпіон. Замість цього можна задати повернення кількості рядків, які відповідають запиту, для чого буде потрібно встановити відповідний прапор при підключенні до сервера;

специфічна для MySQL команда SHOW може бути використана для добування інформації про бази даних, таблицях і індексах. Команда EXPLAIN дозволяє переглянути, як оптимізатор виконує запит;

клієнтам надано можливість підключатися до сервера MySQL, використовуючи сокети TCP / IP на будь-якій платформі. У Windows-системах сімейства NT (NT, 2000 або ХР) клієнти можуть підключатися з використанням іменованих каналів. У системах на базі UNIX клієнти можуть підключатися через файли сокетів UNIX-доменів;

інтерфейс Connector / ODBC дозволяє MySQL підтримувати клієнтські програми, які використовують ODBC-з'єднання. Наприклад, для підключення до сервера MySQL можна використовувати MS Access. Клієнтське програмне забезпечення може виконуватися під управлінням Windows або UNIX. Вихідні тексти інтерфейсу Connector / ODBC доступні. Підтримуються всі функції ODBC 2.5, так само як і безліч інших;

сервер MySQL має вбудовану підтримку SQL-операторів для перевірки, оптимізації і відновлення таблиць. Ці оператори можна виконувати в режимі командного рядка, використовуючи клієнтський додаток mysqlcheck. MySQL включає також myisamchk - дуже швидку утиліту командного рядка для реалізації тих же операцій над таблицями MylSAM.

Таким чином, СУБД MySQL є досить потужним інструментом для розробки додатків, різних за структурою і призначенням. Притаманні СКБД MySQL особливості та можливості дозволяють реалізувати досить складні за своєю структурою, об'ємні бази даних, що складаються з безлічі таблиць з даними певних типів. Характер зв'язку між таблицями також може бути повною мірою вказаний для всіх відносин. Специфічні команди дозволяють швидко виконувати ряд операцій з таблицями, полями та даними, що в них знаходиться.

  1.  Концептуальне проектування бази даних

Виходячи з поставленого завдання була розроблена база даних розташована на сервері mysql та складається з набору таблиць, зв’язаних між собою. Концептуальну схему створеної бази даних зображено на рис.2.4. та складається з шести таблиць, де Prewikka _ Filter, Prewikka _ Filter_ Criterion, Prewikka _ Permission, Prewikka_Session,  Prewikka_Version– таблиці вимірів та Prewikka_Userтаблиця фактів.

Рис.2.4. Концептуальна схема бази даних

 Кожна таблиця створеної бази даних необхідна для збереження інформації, що фіксуюється розроблюваною системою підтримки прийняття рішень в системою виявлення вторгнень. Так, як приклад, таблиця Prewikka_User призначена для збереження даних про налаштування обліковіого запису користувача, таблиця Prewikka_Permissionдля збереження привілеїв, що надані користувачам у використанні розроблюваної системи, таблиця Prewikka_Version призначена для зберігання версії СППР, для подальшого оновлення її налаштувань.

  1.  Фізичне проектування бази даних підсистеми

Створивши та перевіривши концептуальну модель бази даних за допомогою інструментів програми SybasePowerDesigner 15.3 згенеруємо фізичну модель бази даних. Вона матиме наступний вигляд, як це показано на рис.2.5:

Рис.2.5. Фізична модель бази даних

Наступним етапом є генерація самої бази даних. Результатом генерації бази даних є скрипт, приведений у додатку Б.

Отже, використовуючи утиліту SybasePowerDesigner 15.3. спроектовано концептуальну модель бази даних, згенерувано фізичну модель та відповідний скрипт бази даних.

Висновки

Таким чином, в даному розділі проаналізовано та сформовано вимоги до програмного модулю що розробляється. Обґрунтовано вибір програмного середовища та мови програмування для розробки підсистеми, побудована концептуальна та фізична схема бази даних. Обґрунтовано вибір СКБД MySQL як досить потужного інструменту для розробки додатків, різних за структурою і призначенням.


  1.  ПРОГРАМНА РЕАЛІЗАЦІЯ ПІДСИСТЕМИ (ПРОГРАМНОГО                МОДУЛЮ)

3.1. Проектування та розробка узгодженого інтерфейсу взаємодії             користувача з підсистемою

Оскільки якість процесу інтерактивної взаємодії користувача із системою (швидкість, зручність, низький рівень втоми) пов’язана з такими психологічними характеристиками людини як короткострокова та середньострокова пам’ять, час реакції, можливості сприйняття візуальної інформації, то при розробці інтерфейсу необхідно пам’ятати, що:

інтерфейс – сама важлива частина СВВ з точки зору її реклами з метою продажу і з точки зору безпосереднього адміністратора безпеки інформаційної мережі, який може працювати з нею по декілька годин поспіль;

інтерфейс впливає на характер рішень, які приймає ОПР, він може прискорювати час прийняття рішення та покращувати або погіршувати їх якість;

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

Основними  властивостями, яким повинні задовольняти інтерфейси, є:

адаптованість означає, що інтерфейс повинен бути: сумісним з потребами та можливостями користувача; забезпечувати простоту переходу від виконання однієї функції до іншої; забезпечувати користувача, на високому рівні, вказівками стосовно його можливих дій, а також генерувати належний зворотній зв’язок на його запити; надавати користувачу можливість відчувати себе повноправним керівником ситуації при розв’язанні всіх типів задач, тобто, забезпечувати його всією необхідною інформацією; користувач повинен бути впевненим, що він сам розв’язує поставлену задачу; забезпечувати користувача різними, взаємно доповнюючими формами представлення результатів в залежності від типу запиту або від характеру отриманого рішення; враховувати особливості користувачів різних рівнів;

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

гнучкість інтерфейсу: гнучкість інтерфейсу – це можливість його адаптування до розв’язання конкретної задачі. Якщо розв’язувана задача дуже складна, то інтерфейс повинен полегшувати формулювання запитів і видавати результати у формі, яка легко і швидко сприймається користувачем. Тобто інтерфейс повинен буди максимально простим навіть у випадку, коли розв’язується дуже складна задача.

При цьому простота означає таке: інтерфейс не повинен бути перевантажений деталями щодо представлення розв’язку поставленої задачі – користувач може не охопити всіх подробиць (і в цьому, як правило, немає потреби) – тобто нічого зайвого, крім того, що необхідно для розуміння результату; він не повинен містити зайвих декоративних деталей, які відволікають від головної задачі; інтерфейс повинен бути консистентним, тобто, ґрунтуватись на використанні відомих, загальноприйнятих методів і засобів представлення інформації; в ідеалі процес взаємодії адміністратора безпеки з системою не повинен представляти ніяких труднощів.

Вміле поєднання вказаних атрибутів дозволяє суттєво підвищити швидкість сприйняття та глибину розуміння результатів роботи СППР, прискорити процеси вводу/виводу даних.

3.2. Розробка компоненти ведення БД підсистеми

При розробці програмного забезпечення були використанні різні технології побудови програмних засобів. Система ведення бази знань системи підтримки прийняття рішень будується на основі web інтерфейсу, та розміщується на сервері Apache, що являє собою найпопулярніший сервер для розміщення web-додатків.

Для того, щоб система виявлення вторгнень здійснювала внесення повідомлень до бази даних, у разі спрацювання відповідностей сигнатури атак до потоку інформації в комп’ютерній мережі, необхідно перш за все завантажити схему бази даних та налаштувати Prelude. Завантаження здійснюється за командою $ mysql -u prelude prelude -p < /usr/share/libpreludedb/classic /mysql.sql. Всі налаштування зберігаються в конфігураційному файлі prelude-manager.conf. Для цього необхідно прописати наступні рядки:

[db]

type = mysql

host = localhost

port = 3306

name = prelude

user = prelude

pass = prelude

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

Рис.3.1. Таблиця Prelude_User в базі даних Prelude

Для того, щоб розроблювана СППР здійснювала внесення даних до бази

даних, необхідно створити в MySQL базу данних Prewikka и надати права користувачу prewikka наступними командами:

# mysql -u root -p:

Prelude

mysql> CREATE DATABASE prewikka;

mysql> GRANT ALL PRIVILEGES ON prewikka.* TO prewikka@localhost

   -> IDENTIFIED BY 'prewikka';

Далі завантажити раніше згенерований, використовуючи утиліту SybasePowerDesigner 15.3. скрипт для створення таблиць, індексів в БД – командою #mysql –u prewikka prewikka –p < /usr/share/prewikka/database /mysql.sql

Налаштувати конфігураційний файл prewikka.conf. Для цього необхідно прописати наступні рядки:

[database]

type: mysql

host: localhost

user: prewikka

pass: prewikka

name: prewikka

Після цього маємо створену БД з відповідними таблицями, що вказано на рисунку 3.2:

Рис.3.2. База даних Prewikka

Розроблювана СППР буде заносити інформацію, наприклад версії розробки, до бази даних, що у відповідності буде мати вигляд, зображений на рис. 3.3:

Рис.3.3. Таблиця Prewikka_Version в базі даних Prewikka

Для взаємодії СППР з створеною БД Prewikka використовується мова запитів SQL. Приклад запиту:

def createUser(self, login, email=None):

       self.query("INSERT INTO Prewikka_User (login, email) VALUES (%s,%s)" % \ (self.escape(login), self.escape(email)))

  1.  Розробка компоненти аналізу даних моніторингу об’єктів мережі

В рамках дипломної роботи було спроектовано та розроблено СППР, яка у режимі реального часу здатна відслідковувати зміни, що викликають потік інформації до сховища даних, їх аналіз та виведення на екран попередження про спробу чи реалізацію комп’ютерного вторгнення. СППР на основі сигнатур СВВ Prelude має функціональні можливості відображення атак та суб’єктів атаки за останні 24 години, за розподілом часу а також графічно представляти виявлення підозрілої активності. Все це дає змогу адміністратору безпеки в режимі реального часу відслідковувати зміни, що відбуваються в мережі та приймати невідкладні рішення щодо подальших дій.

Для доступу до розробленої системи необхідно запустити сервер, на якому вона розташовується, та в адресній строчці web-оглядача вписати наступну адресу: http://localhost/, або якщо доступ здійснюється віддалено то ввести адресу сервера , а саме: http://10.0.2.15/. Після автентифікації відкривається стартове вікно з вкладкою «Сигнали тривоги». Для детального розбору подій в мережі, які зафіксувала СВВ було розроблено додаткове вікно, перехід до якого можливо здійснити натисканням по запису події після чого з’являється підказка «Переглянути деталі попередження». Приклад зображено на рисунку 3.4:

Рис.3.4. Підказка «Переглянути деталі попередження», що з’являється при натисканні на подію

В розробленому додатковому вікні деталізується інформація про сигнал тривоги, аналізатор, що виявив дану подію, ціль та додаткову інформацію, як вказано на рис. 3.5.

Рис.3.5. Додаткове вікно деталізації інформації про сигнал тривоги

Для прикладу адреса вузла, тобто цілі вторгнення визначається наступним чином:

def buildNode(self, node):

       if not node:

           return

       self.newTableEntry(_("Node location"), node["location"])

       addr_list = None

       node_name = None

       for addr in node["address"]:

           address = addr["address"]

           if not address:

               continue

           node_name = resolve.AddressResolve(address)

           if addr["category"] in ("ipv4-addr", "ipv6-addr", "ipv4-net", "ipv6-net") and self.env.enable_details:

               addr_list += self.getUrlLink(address, "%s?host=%s" %(self.env.host_details_url, address))

           else:

               addr_list += address

       if node["name"]:

           self.newTableEntry(_("Node name"), node["name"])

       self.newTableEntry(_("Node address"), addr_list)

  1.  Розробка компоненти візуалізації даних аналізу

Система оповіщення, в залежності від потоку інформації в комп’ютерній мережі, а саме від інтенсивності спрацювань системою виявлення вторгнень на деструктивні дії, що відбуваються на систему, відображає інтенсивність цих дій за допомогою графіків та кругових діаграм, які будуються за допомогою бібліотеки cairoplot, що побудована на мові програмування python, та служить для конструювання графіків та діаграм різного вигляду та різних завдань. Вона досить легко вбудовується до розроблюваних додатків. Вкладка «Статистика», де реалізовані графіки та кругові діаграми, розроблена для полегшення роботи адміністратора безпеки інформаційної мережі шляхом візуалізації отриманих даних про події від системи виявлення вторгнень Prelude. Для побудови графіку використовується мова програмування python, загальний опис має наступний вигляд:

class CairoTimelineChart(TimelineChartCommon):

   def render(self, name, expire=None, suffix=".png", uid=None, gid=None):

       fname = self._getFilename(name, expire, uid, gid);

       colors = []

       values = utils.OrderedDict()

       for name in self._values.keys():

           nname = name[0:min(len(name), 25)]

           if not values.has_key(nname):

               values[nname] = []

           for item in self._values[name]:

               values[nname].append(item[0])

           colors.append(self.hex2rgb(self.getItemColor(name)))

       cairoplot.dot_line_plot(fname, values, self._width, self._height, border=0, axis=True, grid=True,

                               x_labels=self._labels, series_legen=True, series_colors=colors)

Після чого створюється графік часу роботи системи, встановлюються налаштування, та вказується джерело даних для відображення:

def _generateTimeline(self, user, width, height):

       start, end, step, format, zoom_view, timeline_type, timeline_time = self._getStep(self.parameters["timeline_type"])

       timeline = self._newTimeline(user, width, height)

       if timeline_type != "custom":

           base_parameters = { "timeline_unit": "min" }

       else:

           base_parameters = { "timeline_type": timeline_type }

       self.dataset["timeline_user_type"] = self.parameters.get("timeline_type")

       while start < end:

          c = self._getTimeCrit(start, step) + self._criteria

           if timeline_type != "custom":

               base_parameters["timeline_start"] = long(time.mktime(start.timetuple())) #long(start)

           else:

               self._setTimelineZoom(base_parameters, start, start + step)

           link = utils.create_link(zoom_view, base_parameters)

           count = self._getAlertCount(c, link, zoom_view)

           label = start.strftime(format)

           start += step

           timeline.addLabelValuePair(label, count, link)

       return timeline

Графік відображення вторгнень за останні 24 години зображено на рис.3.6.

Рис.3.6. Графік відображення атак за останні 24 години

У відповідності, аналогічно до попереднього, відображення вторгнень за останній місяць має вигляд, що зображений на рис.3.7.

Рис.3.7. Графік відображення вторгнень за останній місяць

Тип сенсора та відсоток виявлених ним вторгнень зображено на панелі «Аналізатори» представлено на рис.3.8.

Рис.3.8. Діаграма, що відображає тип сенсорів

Система має змогу поряд з відображенням активності оповіщень, відображати суб’єкти, які стали ціллю дії вторгнення. Зокрема, останні суб’єкти зображено на рисунку 3.9.

Рис.3.9. Діаграма, що відображає суб’єкти, які стали ціллю дії вторгнення

  1.  Інструкція користувачу по роботі з підсистемою (програмним    модулем)

Для доступу до розробленої системи необхідно запустити сервер, на якому вона розташовується, та в адресній строчці web-оглядача вписати наступну адресу: http://localhost/, або якщо доступ здійснюється віддалено то ввести адресу сервера, а саме: http://10.0.2.15/. Далі відкриється вікно входу в систему, де користувач повинен вказати свій пароль та логін. Після успішної автентифікації завантажується для перегляду головна сторінка системи.

На вкладці «Сигнали тривоги» вказується інформація про події в системі, а саму джерело вторгнення, ціль, тип аналізатора, що виявив подію та час її виникнення. Аналогічно на вкладці «Агенти» - про сенсори, які використовуються в системі виявлення вторгнень, їх назва, модель версія клас, час останньої активації та стан на поточний момент, про вузли. Що аналізуються системою. Вкладка «Статистика» - призначена для візуалізації отриманих від СВВ даних про аналізатори, джерела подій їх цілі та завантаженість системи у вигляді графіків та діаграм. На вкладці «Налаштування» користувач має можливість переглядати та налаштовувати свій обліковий запис в залежності від наданих йому прав. Зокрема це створювати фільтри, змінювати пароль, мову та права доступу. Огляд додаткової інформації про дану систему виявлення вторгнень Prelude її комерційні ліцензії, контакти розробників системи можливо здійснити на вкладці «Про систему».

Додавання користувача можливе тільки для адміністратора системи користувачам, які мають відповідні права.

Необхідно перейти на вкладку «Налаштування» - «Список користувачів» та натиснути кнопку «Створити користувача». Після чого відкриється вікно для налаштувань нового облікового запису, як це зображено на рисунку 3.10, де необхідно заповнити поля: «Логін», «Мова», «Привілеї», «Новий пароль», «Підтвердити новий пароль» та натиснути кнопку «Підтвердити зміні».

Рис.3.10. Вікно для налаштувань нового облікового запису

Значення прав, які надаються користувачам:

IDMEF_VIEW – доступ до вкладок «Сигнали тривоги» та «Агенти»;

IDMEF_ALTER – можливість видалення записів про події та активацію агентів;

USER_MANAGER – можливість створення, зміни, видалення облікових записів користувачів на вкладці «Налаштування»;

COMMAND, INTRUSIVE_COMMAND – дозвіл на введення команд, доступний тільки в комерційній версії Prewikka.

Аналогічно видалення користувачів можливе тільки для адміністратора безпеки або для користувачів, які мають відповідні права. Необхідно перейти на вкладку «Налаштування» - «Список користувачів» встановити галочку навпроти відповідного запису та натиснути кнопку «Видалити користувача».

Налаштування облікового запису користувача можливе при переході на вкладку «Налаштування» - «Мій обліковий запис», або при натисканні на посилання в полі «логін», після чого відкриються налаштування відповідного користувача на вкладці «Налаштування» - «Список користувачів.

Зміна налаштувань необхідної мови здійснюється на вкладці «Налаштування» - «Мій обліковий запис» де в полі «Мова» потрібно обрати необхідну мову : англійська, німецька, українська, російська, італійська, польська, португальська(Бразилія), французька та натиснути на кнопку «Прийняти зміни».

Для зміни паролю на вкладці «Налаштування» - «Мій обліковий запис» в полі «Змінити пароль» необхідно ввести поточний пароль, новий та підтвердити пароль, а далі натиснути на кнопку «Прийняти зміни».

Створення нових, видалення та завантаження існуючих фільтрів здійснюється на вкладці «Налаштування» - «Фільтр». В полі «Доступні фільтри» потрібно обирати з випадаючого списку наявні в системі фільтри та натиснути кнопку «Завантажити» для завантаження фільтрів, що були створені раніше. Для додавання нового фільтру необхідно в полі А ввести шлях, оператор та значення фільтру, при необхідності додати нові чи видалити існуючі аргументи можливо при натисканні на знак «+» або «-», навпроти поточного поля, в полі «Формула» за прикладом ввести формулу нового фільтру, як це вказано на рисунку 3.11, в полі «Ім’я» - назву нового фільтру та в полі «Коментар» - коментарі до створюваного фільтрую й натиснути кнопку «Зберегти» для збереження нового фільтру в БД.

Рис.3.11. Додавання нового чи зміна поточного фільтру подій в ІМ

Для детального розбору подій в мережі, які зафіксувала СВВ потрібно перейти до додаткового вікна натисканням по запису події на вкладці «Сигнали тривоги», після чого з’являється підказка «Переглянути деталі попередження». В даному вікні здійснюється детальний розбір події. Також для детального розбору активності сенсорів потрібно натиснути на посилання назви сенсора на вкладці «Агенти», після чого з’явиться підказка з трьома пунктами для аналізу: «Аналіз пульсу», «Список пульсу», «Список подій». Натиснувши на відповідне посилання відкриється додаткова вкладка з докладною інформацією про відповідні властивості.

Щоб вийти з системи необхідно натиснути на посилання «Вихід» в правому верхньому куті сторінки.

Висновки

Отже, спроектована та розроблена СППР здатна відслідковувати зміни, що викликають потік інформації до сховища даних, їх аналіз та виведення на екран попередження про спробу чи реалізацію комп’ютерного вторгнення. Програмний модуль системи оповіщення про виявлені атаки дозволяє досягти мети дослідження: підвищити ефективність роботи адміністратора безпеки за рахунок покращення показника оперативності в його роботі.


  1.  ОЦІНКА ЕФЕКТИВНОСТІ ФУНКЦІОНУВАННЯ СИСТЕМИ ТА       ЗАПРОПОНОВАНИХ РІШЕНЬ

  1.  Обґрунтування підходу до оцінки ефективності функціонування        системи та вибір показників ефективності для оцінки отриманих результатів

На сьогоднішній день у галузі моніторингу мережевої активності на випадок атаки різко зростає необхідність більш ретельно та достовірно аналізувати та виявляти деструктивні дії, що спрямовані на заподіяння будь-якого ураження комп’ютерним системам. Це, безперечно, впливає на якісні зміни вимог, що висуваються до СВВ. Сучасна система виявлення вторгнень в інформаційно-аналітичній системі має забезпечувати безпечне і швидке функціонування інформаційної системи за різних умов з урахуванням різноманітних чинників.

Відповідно до основних завдань, що вирішує система виявлення вторгнень в інформаційну мережу, її властивостями має бути оперативність qоп та обґрунтованість qоб. Кількісною мірою оперативності (критерієм оперативності cоп) обирається допустимий відрізок часу такий що :

, де

 – витрати часу на обробку мережевого трафіку системою виявлення вторгнень;

– витрати часу на співставлення сигнатур відомих атак до мережевих пакетів, та занесення інформації до сховища даних;

– витрати часу на представлення інформації про виявлену атаку;

– витрати часу на реакцію оператора системи виявлення атак щодо прийняття рішення.

У свою чергу, витрати часу визначаються методами й алгоритмами обробки інформації й прийняття рішення адміністратором безпеки і містять дві складові:

, де

– витрати часу на підготовку рішення за допомогою засобів автоматизації, – витрати часу на прийняття рішення адміністратором безпеки.

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

Загальну структуру прийняття рішення можливо представити у вигляді графа Г (), який зображено на рисунку 4.1, де – множина елементів або дій адміністратора безпеки, а  – множина існуючих відображень. Зміст етапів прийняття рішення пояснюється в таблиці 4.1. Дії 1 – 6 відносяться до етапу інформаційної підготовки (Н1), 7 – 10 – до вибору рішення та його реалізації (Н2  та Н3 ). З цього слідує, що для автоматизації інформаційного забезпечення прийняття рішення необхідно покласти виконання дій 1 – 6 на технічні засаби, тобто автоматизувати функції розпізнання подій в інформаційній мережі, управління системою для відбору необхідної для прийняття рішення інформації та оптимізації умов сприйняття [24].

Область роботи адміністратора безпеки полягає у виконанні повязаних між собою дій, що проектують модель роботи системи в цілому. Оперативність прийняття рішення визначається на етапі 10 (H3). Показник оперативності залежить від комплексу дій самої системи, щодо своєчасного оповіщення про можливі вторгнення до компютерної системи. Розроблена підсистема здійснює аналіз бази даних, і в режимі реального часу оповіщає адміністратора безпеки про виявленні порушення нормальної роботи системи, що і є підвищенням одного з пунктів роботи адміністратора безпеки – оперативності його реагування на виявлені вторгнення.

Таблиця 4.1.

Зміст етапів процесу аналізу даних та прийняття рішення адміністратором безпеки

Етап прийняття рішення

Формальне представлення

Опис етапу

1

2

3

Прослуховування інформаційної мережі

Збір даних сенсорами СВВ

Управління системою для покращення умов сприйняття

Реалізація окремих операцій з управління відображенням

Виявлення конфліктних ситуацій та їх реєстрація

Контроль обстановки при відсутності конфліктних ситуацій

Корегування СВВ для деталізації інформації (візуалізаціяданих)

Обробка результатів аналізу

Перехід до прийняття рішення

Повернення до контролю обстановки при відсутності конфліктних ситуацій

Визначення цілі та критеріїв прийняття рішення

Затвердження рішення і перехід до його реалізації

Генерування альтернатив і оцінка результатів рішення

Продовження таблиці 4.1.

1

2

3

Додаткове прогнозування стану системи при труднощах в виборі рішення

Реалізація ПР і перехід до аналізу обстановки

Оцінка результатів ПР та їх запам’ятовування (накопичення знань)

Перехід до повторного ПР при незадовільних результатах

Рис.4.1. Область роботи адміністратора безпеки

Ступінь обґрунтованості рішення, що приймається, визначається як відношення:

, де

– максимально доцільна кількість розглядуваних варіантів рішень.

N – кількість варіантів, що може розглянути та проаналізувати адміністратор безпеки за час .

Підвищення ступеня обґрунтованості рішення є можливим за рахунок збільшення кількості аналізу варіантів прийняття рішень адміністратором безпеки про ситуацію, що виникла у мережі.

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

З іншого боку, приблизною кількісною мірою обґрунтованості рішень можна вважати кількість варіантів, яку здатна підготовити автоматизована система та проаналізувати й оцінити адміністратор безпеки перед прийняттям рішення. Тому, кількість рішень N, що може розглянути й проаналізувати адміністратор за час  зростає, за рахунок більшої швидкодії запропонованого метода, в результаті чого, підвищується обґрунтованість рішень Q, що приймаються адміністратором безпеки в цілому.

  1.   Оцінка ефективності функціонування системи та запропонованих      рішень

Досвід експлуатації системи показує, що для прийняття обґрунтованого рішення щодо виявлення вторгнення в інформаційну мережу, адміністратором безпеки за допустимий час Tдоп необхідно проаналізувати N варіантів (табл. 4.2). У випадку існуючого підходу (робота оператора зі штатними засобами системи) він має можливість аналізу 1 варіантів, а у випадку запропонованого математичного та програмного забезпечення – 2.

Таблиця 4.2

Можливості аналізу варіантів за допустимий час Tдоп

Необхідна кількість варіантів (N0)

Існуючий підхід (Nісн)

Запропонований підхід (Nзапр)

3

1

2

N

N

2n

Qісн= Nісн / N0 = 1 / 3 = 0,3 ;

Qзапр= Nзапр / N0 = 2 / 3 = 0,6 ;

∆Q = | Qзапр - Qісн| = | 0,6 – 0,3 | = 0,3 .

На рисунку 4.2 зображено залежність кількості рішень, що може розглянути та проаналізувати адміністратор безпеки від часу, що витрачається на аналіз.

Рис.4.2. Залежність кількості рішень, що може розглянути та проаналізувати адміністратор безпеки від часу, що витрачається на аналіз


Висновки

Таким чином, розроблене програмне забезпечення  дозволяє підвищити обгрунтованість рішень, які приймає адміністратор безпеки під час аналізу ситуацій щодо виявлення вторгнень в інформаційну мережу на 30 %.


ЗАКЛЮЧЕННЯ

Отже, в сучасних умовах постійного зростання інтенсивності атак на інформаційно-телекомунікаційні системи важливе місце в системі інформаційної безпеки відводиться системам виявлення вторгнень. На сьогоднішній день неможливо організувати ефективний захист інформації без використання СВВ. Виходячи з мети та завдань роботи можна зробити наступні висновки: по-перше, системи виявлення комп'ютерних вторгнень є одним з найважливіших елементів систем інформаційної безпеки інформаційної мережі органу військового управління, враховуючи, як зростає в останні роки число проблем, пов'язаних з комп'ютерною безпекою. IDS являють собою спеціалізовані програмно-апаратні комплекси, призначені для виявлення інформаційних атак в ІС. Аналіз показав, що до основних задач системи виявлення вторгнення можна віднести задачі, що вирішують питання своєчасної та достовірної ідентифікації виникнення помилок, нестандартних чи конфліктних ситуацій. Проведено аналіз наступних програмних продуктів виявлення комп’ютерних вторгнень:OSSEC, розробником якої є Daniel B. Sid, STAT, розробленої в університеті University of California at Santa Barbara, Prelude, розробниками якої є Yoann Vandoorselaere та Laurent Oudot, Snort, розробної Martin Roesch, Bro, розробленої в університеті University of California, Lawrence Berkeley National Laboratory. Жодна з розглянутих вище відкритих СВВ, не відповідає повною мірою критеріям «ідеальної» СВВ. Основним недоліком є відсутність адаптивності до невідомих атакам і неможливість аналізувати поведінку об'єктів РІС на всіх рівнях одночасно. На даний момент найбільш сприятлива система виявлення вторгнень – це Prelude.

По-друге, в якості системи виявлення вторгнень, було обрано систему Prelude, яка є найбільш сприятливою для роботи через свої широкі можливості. З усіх розглянутих в даній роботі систем, система Prelude дозволяє забезпечити аналіз як даних з локальних системних джерел, так і мережевих даних, має додаткові механізми, що забезпечують безпеку її компонентів, а також має найменше недоліків як в архітектурі, так і в реалізації. Дана система побудована на використанні відкритих стандартів, що дає змогу надалі інтегрувати компоненти сторонніх виробників і навпаки. Для полегшення роботи та пришвидшення реагування на події в СВВ доцільно використовувати методи візуалізації даних для покращення аналізу інформації. Візуальне представлення даних є набагато інформативнішим за інші методи отримання та сприйняття інформації, більш зручним і легшим для сприйняття та розуміння ніж наприклад представлення даних у таблицях, схемах, математичних матрицях, або просто в числах.

У результаті проведеного дослідження було розроблено удосконалену структуру системи виявлення вторгнень Prelude, яка включає графічну підсистему взаємодії адміністратора безпеки з системою. Операції обробки великої кількості подій щодо реагування на невідомі досі події в системі виявлення вторгнень вручну є трудомістким рутинним процесом, що уповільнює роботу адміністратора безпеки. Тому розроблене програмне забезпечення  дозволяє підвищити обгрунтованість рішень, які приймає адміністратор безпеки під час аналізу ситуацій щодо виявлення вторгнень в інформаційну мережу на 30 %.


СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ

  1.   ЛукацкийА.В. Обнаружение атак / ЛукацкийА.В. – СПб. : БХВ –Петербург, 2003. – 256 c.
  2.   Kazienko P. Intrusion Detection Systems Part I – (network intrusions; attack symptoms; IDS tasks; and IDS architecture)/Kazienko P., Dorosz P., [On-line] http://www.windowsecurity.com/articles-tutorials/ intrusion_detection / Intrusion_Detection_Systems_IDS_Part_I__network_intrusions_attack_symptoms_IDS_tasks_and_IDS_architecture.html
  3.   Норткат С.А. Обнаружение нарушений безопасности в сетях. / Норткаг С.А. / Пер. с англ. – М.:ДМК Пресс, 2003. – 200 с.
  4.   Preece J.I. Human – Computer Interaction: Concepts and design /  J.I. Preece, Y.K. Rogers, H.E. Sharp, D.O. Benyon, S.J. Holland, T.C. Carey. – New York: Addison–Wesley, 1994. – 168 p.
  5.   Хоменко Д.О. Cистема виявлення вторгнень Prelude. Тактико-технічні характеристики. Шляхи удосконалення / Хоменко Д.О. / XIII воєнно-наукова конференція курсантів (студентів) – К: ВІТІ ДУТ. – 2014. – 24 с.
  6.   Khomenko D. О. The usage of multiagent approach for a computer attacks detection / Khomenko D. О. / Матеріали XI міжнародної науково-практичної студентської інтернет-конференції – К: НТУУ КПІ. – 2013. – 157 с.
  7.   Сердюк В.А. Перспективы развития новых технологий обнаружения информационных атак / В.А. Сердюк // Системы безопасности связи и телекоммуникаций. – 2002. – №5. – С.5–7.
  8.   Пауер P.A. Експерти дискутують про сьогодення і майбутнє систем виявлення атак / Пауер P.A.; пер. з англ. О.I. Лукацкого. – Днепропетровск : Computer Security Journal, 2002. – XIV, 10 с.
  9.   Біячуєв Т.А. Безпека корпоративних мереж. / під ред. Л.Г.Осовецкого – СПб: СПб ГУ ІТМО, 2004.– 161 с.
  10.   Абрамов Е.С. Построение адаптивной системы информационной безопасности / Абрамов Е.С. // «Известия ЮФУ. Технические науки». Тематический выпуск «Информационная безопасность». – 2011. – №12 (125). – С. 99.
  11.   «Trusted Computer System Evaluation Criteria», The Orange Book, Department of Defense, NCSC, National Computer Security Centre, DoD 5200.28–STD, December, 1985.
  12.   Гамаюнов Д. Ю. Обнаружение компьютерных атак на основе анализа поведения сетевых объектов: дис. кандидата физ.–мат. наук: 05.13.11 / Гамаюнов Денис Юрьевич. – М., 2007. – 89 с.
  13.   Fischer F.I. Largescale network monitoring for visual analysis of attacks, [in: F.F. Mansmann, D.A. Keim, S.F. Pietzko, M.J. Waldvogel / F.I. Fischer //   Proc. of ACM VizSEC/DMSEC, – 2008.  
  14.   Elhenawy I. J. Data Visualization Technique Framework for Intrusion detection/ I.J. Elhenawy // IJCSI International Journal of Computer Science Issues – vol. 8. – September, 2011. – P. 27-35. [on-line] www.IJCSI.org
  15.   Chen, P. P. Entity-relationship modeling: historical events, future trends, and lessons learned / P.P. Chen // Entity-Relationship Approach to Software En gineering: international conference, November 27–30, 2001, Yokohama, Japan: proceedings. – 2001. – P. 71–77.
  16.   Blustein J.I.  Information  Visualization  for  an Intrusion Detection System / J.I. Blustein C.C. Fu, D.L. Silver. – Queber: ACM, 2005. – 52p.
  17.   Peng J.J. A Hybrid Intrusion Detection and Visualization System / J.J. Peng, C.D. Feng J.I. W.Rozenblit. – New York: IEEE, 2006. – 100p.
  18.   Чаплыгин А.Н.  Учимся програмировать вместе с Питоном: Учебное пособие /Чаплыгин А.Н.  – СПб. : БХВ –Петербург, 2003. – 256 c.
  19.   Басюк Т.М. Аналіз та класифікація методів візуалізації / Т.М. Басюк// Поліграфія і видавнича справа. –2003. – № 40. – С. 109–114.
  20.   Codd, E. F.  Data  Models  in  Database  Management /  E. F. Codd // Workshop in  Dat a Abstraction, Databases, and  Conceptual  Modelling: international  conference,  June  23–26,  1980,  Pingree  Park,  Colorado:  proceedings. – 1980. – P. 18–36.
  21.   Сільвейструк,  Л.  М. Формалізація  моделі  "сутність -зв 'язок ":  типи  сутностей,  типи  зв 'язків  та їх обмеження : автореф. дис. канд .  фіз.- мат.  наук : 01.05.03 – математичне  та   програмне забезпечення   обчислювальних машин та систем. –  К., 2009.
  22.   Chen, P. P.  The entity-relationship model – towards a unified view of data / P. P. Chen // ACM Transactions on Database Systems. – March 1976. – Vol. 1, No. 1. – P. 9–36;
  23.   Мезенко Л.В. Справочное руководство по MySQL / Мезенко Л.В. – М.: «Полис», 2003, – 208с. 
  24.   Герасимов Б.М. Человекомашинные системы принятия решений с элементами искуственного интелекта / Герасимов Б.М., Тарасов В.А., – К.: Наукова думка, 1993. – 183с.


Додаток А





THE USAGE OF MULTIAGENT APPROACH FOR A COMPUTER          ATTACKS DETECTION

Khomenko D. О.

Military Institute of Telecommunications and information technologies

The State university of Telecommunication

The development computer attacks distributed systems through multiagent approach, acquires greater and perspective scope of information technologies. For a few last decades сcomputer networks especially technical decision, became a global phenomenon many spheres of activity. Nowadays it is difficult to imagine any IT project that does not provide informatization safety in all functional levels. With the steady increase of volumes of information that is processed and by the increase of her value, as to the "commodity" so, the first place sets the questions of reliable and safe work of the informative systems.

The detection of computer attacks is one of the major elements of networks systems informatization security of any modern enterprise, including, a great number of problems that are related with computer security. It happened historically, that all the systems attacks’ detection can be divided into two categories: anomaly detection and misuse detection [2].

The most modern commercial systems (Cisco IPS, ISS RealSecure, NFR ) are based on the first type of methods - they use the signature expert methods of detections.

The methods of A-one are based on the presence of the prepared description of normal behavior of objects of the distributed informative systems (DIS), and any deviation from normal behavior is considered anomalous violation. The methods of abuses detection are based on description of well-known violations or attacks: if there is behavior of some object DIS coincides with description of well-known attack, behavior of object is considered as an attack.

Multiagent approach that will be used in the basis of the developed system with make cardinal changes. The centralization, hard management and global optimization, will concede a place to decentralization. The expected result is high efficiency, flexibility and reliability of the systems of production and distribution [1].

Therefore one of the tasks, is to work out the hybrid method of attacks, detection that will unite a signature method and method of system analysis of transitions for the exposure of deviations from normal behavior. The association of these methods will help to save verification, firmness and low calculable complication  during abuses exposure and complement their property of adaptation to the unknown attacks. The presence of these properties will allow to use a method in the system of exposure of attacks of general-purpose, and also in the off-line systems for that all are listed above to property is critical.

The analysis of existent literary sources, showed that none of the systems can covere all types of attacks. The enormous amount of accessible realization of СВА is presented, mainly by the commercial systems, that are lack of information about programmatic architecture and usage of formal methods of attacks detection exposure.

It is suggested to develop the method of attacks detection on the distributed informative systems (DIS). The creation of computer attack’s model and it’s method of automatic exposure, will allows to find out computer attacks during behavior, watching of DIS objects.

References:

1. Amoroso, Edward, G., Intrusion Detection // 1st ed., Intrusion.Net Books, Sparta, New Jersey, USA, 1999  

2. Denault M., Gritzalis D., Karagiannis D., and Spirakis P. (1994). Intrusion Detection: Approach and Performance Issues of the SECURENET System. // Computers and Security Vol. 13, No. 6, pp. 495-507.


Додаток Б

/*=============================================*/

/* DBMS name:      MySQL 5.0                                    */

/* Created on:     06.07.2014 8:46:17                           */

/*=============================================*/

drop table if exists Prewikka_Filter;

drop table if exists Prewikka_Filter_Criterion;

drop table if exists Prewikka_Permission;

drop table if exists Prewikka_Session;

drop table if exists Prewikka_User;

drop table if exists Prewikka_Version;

/*===========================================*/

/* Table: Prewikka_Filter                                       */

/*=============================================*/

create table Prewikka_Filter

(

  id_f                 bigint not null,

  login                varchar(32) not null,

  comment              varchar(255) not null,

  formula              varchar(255) not null,

  primary key (id_f)

);

/*=============================================*/

/* Table: Prewikka_Filter_Criterion                             */

/*=============================================*/

create table Prewikka_Filter_Criterion

(

  id_f_c               bigint not null,

  name_f               varchar(32) not null,

  id_f                 bigint not null,

  path                 varchar(255) not null,

  operator             varchar(8) not null,

  value_f              varchar(255) not null,

  primary key (id_f_c, name_f)

);

/*=============================================*/

/* Table: Prewikka_Permission                                   */

/*=============================================*/

create table Prewikka_Permission

(

  id_p                 bigint not null,

  login                varchar(32) not null,

  permission           varchar(32) not null,

  primary key (id_p)

);

/*=============================================*/

/* Table: Prewikka_Session                                      */

/*=============================================*/

create table Prewikka_Session

(

  session_id           bigint not null,

  login                varchar(32) not null,

  time                 datetime not null,

  primary key (session_id)

);

/*=============================================*/

/* Table: Prewikka_User                                         */

/*=============================================*/

create table Prewikka_User

(

  login                varchar(32) not null,

  lang                 varchar(32) not null,

  password             varchar(32) not null,

  email                varchar(64) not null,

  primary key (login)

);

/*=============================================*/

/* Table: Prewikka_Version                                      */

/*=============================================*/

create table Prewikka_Version

(

  version              varchar(32) not null

);

alter table Prewikka_Filter add constraint FK_Relationship_1 foreign key (login)

     references Prewikka_User (login) on delete restrict on update restrict;

alter table Prewikka_Filter_Criterion add constraint FK_Relationship_5 foreign key (id_f)

     references Prewikka_Filter (id_f) on delete restrict on update restrict;

alter table Prewikka_Permission add constraint FK_Relationship_3 foreign key (login)

     references Prewikka_User (login) on delete restrict on update restrict;

alter table Prewikka_Session add constraint FK_Relationship_2 foreign key (login)

references Prewikka_User (login) on delete restrict on update restrict;
Додаток В

Вкладка підказка

import re

import time

import struct

import socket

import urllib

from prewikka import view, User, utils, resolve

def buildProcess(self, process):

       self.beginTable()

       self.newTableEntry(_("Process"), process["name"])

       self.newTableEntry(_("Process Path"), process["path"])

       self.newTableEntry(_("Process PID"), process["pid"])

       self.endTable()

   def buildNode(self, node):

       if not node:

           return

       self.newTableEntry(_("Node location"), node["location"])

       addr_list = None

       node_name = None

       for addr in node["address"]:

           address = addr["address"]

           if not address:

               continue

           node_name = resolve.AddressResolve(address)

           if addr_list:

               addr_list += "<br/>"

           else:

               addr_list = ""

           if addr["category"] in ("ipv4-addr", "ipv6-addr", "ipv4-net", "ipv6-net") and self.env.enable_details:

               addr_list += self.getUrlLink(address, "%s?host=%s" %(self.env.host_details_url, address))

           else:

               addr_list += address

       if node["name"]:

           self.newTableEntry(_("Node name"), node["name"])

       elif node_name.resolveSucceed():

           self.newTableEntry(_("Node name (resolved)"), node_name)

       self.newTableEntry(_("Node address"), addr_list)

   def buildAnalyzer(self, analyzer):

       self.beginTable(cl="message_summary_no_border")

       self.beginTable()

       self.newTableEntry(_("Model"), analyzer["model"], cl="section_alert_ entry_value_emphasis")

       self.newTableEntry(_("Name"), analyzer["name"], cl="section_alert_ entry_value_emphasis")

       self.newTableEntry(_("Analyzerid"), analyzer["analyzerid"])

       self.newTableEntry(_("Version"), analyzer["version"])

       self.newTableEntry(_("Class"), analyzer["class"])

       self.newTableEntry(_("Manufacturer"), self.getUrlLink(analyzer["manufacturer"]))

       self.endTable()

       self.newTableRow()

       self.beginTable()

       self.buildNode(analyzer["node"])

       if analyzer["ostype"] or analyzer["osversion"]:

               self.newTableEntry(_("Operating System"), "%s %s" % (analyzer["ostype"] or "", analyzer["osversion"] or ""))

       self.endTable()

       self.newTableRow()

       if analyzer["process"]:

           self.buildProcess(analyzer["process"])

           self.newTableRow()

       self.endTable()

   def buildAnalyzerList(self, alert):

       l = []

       for analyzer in alert["analyzer"]:

           l.insert(0, analyzer)

       l.pop(0)

       self.beginSection(_("Analyzer Path (%d not shown)") % len(l), display="none")

       self.beginTable(cl="message_summary_no_border")

       i = 1

       index = len(l) - 1

       for analyzer in l:

           self.newTableCol(i - 1, _("Analyzer #%d") % index, None, header=True)

           self.buildAnalyzer(analyzer)

           self.newTableRow()

           i += 1

           index -= 1

       self.endTable()

       self.endSection()

def buildClassification(self, alert):

       if not alert["classification.text"]:

           return

       self.newTableEntry(_("Text"), alert["classification.text"],

                          cl="section_alert_entry_value_emphasis impact_severity_%s" % alert["assessment.impact.severity"])

       self.newTableEntry(_("Ident"), alert["classification.ident"])

 def buildSource(self, alert):

       i = 0

       for source in alert["source"]:

           self.beginSection(_("Source(%d)") % i)

           self.buildDirection(source)

           self.endSection()

           i += 1

   def buildTarget(self, alert):

       i = 0

       for target in alert["target"]:

           self.beginSection(_("Target(%d)") % i)

           self.buildDirection(target)

           for f in target["file"]:

               self.buildFile(f)

           self.endSection()

           i += 1

Вкладка статистики

import sys

import time

import copy

import urllib

import datetime

from prewikka import User, view, Chart, utils, resolve

class DistributionStatsParameters(view.Parameters):

   def register(self):

       self.optional("timeline_type", str, default="hour", save=True)

       self.optional("from_year", int, save=True)

       self.optional("from_month", int, save=True)

       self.optional("from_day", int, save=True)

       self.optional("from_hour", int, save=True)

       self.optional("from_min", int, save=True)

       self.optional("to_year", int, save=True)

       self.optional("to_month", int, save=True)

       self.optional("to_day", int, save=True)

       self.optional("to_hour", int, save=True)

       self.optional("to_min", int, save=True)

       self.optional("filter", str, save=True)

       self.optional("idmef_filter", str)

       self.optional("apply", str)

def _processTimeCriteria(self):

       now = time.time()

       self._period_end = time.localtime(now)

       if self.parameters["timeline_type"] == "hour":

           self.dataset["timeline_hour_selected"] = "selected=\"selected\""

           self._period_start = time.localtime(now - 3600)

       elif self.parameters["timeline_type"] == "day":

           self.dataset["timeline_day_selected"] = "selected=\"selected\""

           tm = time.localtime(now - 24 * 3600)

           self._period_start = time.localtime(now - 24 * 3600)

       elif self.parameters["timeline_type"] == "month":

           self.dataset["timeline_month_selected"] = "selected=\"selected\""

           tm = list(time.localtime(now))

           tm[1] -= 1

           self._period_start = time.localtime(time.mktime(tm))

       else:

           self.dataset["timeline_custom_selected"] = "selected=\"selected\""

           self._period_start = time.struct_time((self.parameters["from_year"], self.parameters["from_month"],

                                                  self.parameters["from_day"], self.parameters["from_hour"],

                                                  self.parameters["from_min"], 0, 0, 0, -1))

           self._period_end = time.struct_time((self.parameters["to_year"], self.parameters["to_month"],

                                                self.parameters["to_day"], self.parameters["to_hour"],

                                                self.parameters["to_min"], 0, 0, 0, -1))

       self.dataset["from_year"] = "%.4d" % self._period_start.tm_year

       self.dataset["from_month"] = "%.2d" % self._period_start.tm_mon

       self.dataset["from_day"] = "%.2d" % self._period_start.tm_mday

       self.dataset["from_hour"] = "%.2d" % self._period_start.tm_hour

       self.dataset["from_min"] = "%.2d" % self._period_start.tm_min

       self.dataset["to_year"] = "%.4d" % self._period_end.tm_year

       self.dataset["to_month"] = "%.2d" % self._period_end.tm_mon

       self.dataset["to_day"] = "%.2d" % self._period_end.tm_mday

       self.dataset["to_hour"] = "%.2d" % self._period_end.tm_hour

       self.dataset["to_min"] = "%.2d" % self._period_end.tm_min

       criteria = [ "alert.create_time >= '%d-%d-%d %d:%d:%d' && alert.create_time < '%d-%d-%d %d:%d:%d'" % \

                    (self._period_start.tm_year, self._period_start.tm_mon, self._period_start.tm_mday,

                     self._period_start.tm_hour, self._period_start.tm_min, self._period_start.tm_sec,

                     self._period_end.tm_year, self._period_end.tm_mon, self._period_end.tm_mday,

                     self._period_end.tm_hour, self._period_end.tm_min, self._period_end.tm_sec) ]

       return criteria

def _setTimelineZoom(self, base_parameters, start, end):

       #tm = time.localtime(start)

       base_parameters["from_year"] = start.year

       base_parameters["from_month"] = start.month

       base_parameters["from_day"] = start.day

       base_parameters["from_hour"] = start.hour

       base_parameters["from_min"] = start.minute

       #tm = time.localtime(end)

       base_parameters["to_year"] = end.year

       base_parameters["to_month"] = end.month

       base_parameters["to_day"] = end.day

       base_parameters["to_hour"] = end.hour

       base_parameters["to_min"] = end.minute

109




1. В воздухе с электрическими параметрами ~ 1 ~ 1 распространяется радиоволна с частотой f 30 ГГц
2. темных рук А всетаки он красивый теперь я понимаю почему тот археолог сошел с ума после визита в этот з
3. тема Дата основания библиотеки Адрес- Октябрьск
4. дней направляется Президенту Российской Федерации для подписания и обнародования
5. Установка КСМ4 на заданную норму посадки
6. Признаки повреждения при выстрелах с различного расстояния
7. МУП ЖЭУРуководитель практики на предприятии- Гл.html
8. это массовое убийство еврейского народа нацистами во время Второй мировой войны который жил в Германии и в
9. тематикой. Создайте уменьшенные эскизы всех изображений коллекции
10. Rom nd Juliet [Джульетта
11. Социология и право
12. Град же Казань твёрд бяше паче меры подобен каменной горе стена дубовая рубленная и в целых древесах а в го
13. РЕФЕРАТ дисертації на здобуття наукового ступеня кандидата економічних наук Київ ~
14. Создаем вместе праздничную атмосферу
15. Базы данных Не тему- Анализ рынка программных продуктов для проведения добычи данных Выпо
16. то особое наслаждение видеть как огонь пожирает вещи как они чернеют и меняются
17. Варіант 3 Так чи ні Боротьба з інфляцією і боротьба з безробіттям це взаємодоповнюючі цілі економічн
18. Диагноз- атрезия желчевыводящих протоков
19. .koob.ru НАПОЛЕОН ХИЛЛ ДУМАЙ И БОГАТЕЙ Перевод с английского- Г
20.  Подружиться с ребятами найти друзей