2.2. Проектування програмного модуля для категоризації загроз
Оскільки СУІІБ не є досконалою з точки зору автоматизації процесу категоризації інцидентів і є вразливою до кіберзлочинів, необхідно її удосконалити за рахунок розробки відповідного програмного модуля. В такому разі буде підвищений рівень захищеності ІКС університету та студмістечка НАУ, шляхом розробки програмного модуля категоризації інцидентів ІБ.
У роботі удосконалюється модуль виявлення атак, що взаємодіє напряму із поштовим сервером, дане введення модуля категоризації інцидентів, дасть принципово нову можливість для СУІІБ диференціювати кібератаки. Це, у свою чергу, дозволить підвищити ефективність роботи команди NAU-CERT (щодо збору статистики) і загальний рівень безпеки ІКС НАУ.
Програмним забезпеченням «1С:Предприятие», було створена базу даних, яка містить 12 різних класифікаторів. Коли дані про інцидент подаються на вхід поштового серверу, програмний модуль обробляє повідомлення щодо інциденту і класифікує його до певної групи.
Інциденти, що входять до складу системи виявлення атак поділяються на 12 різних груп:
викрадення конфіденційної інформації;
низька якість ПЗ;
фізична безпека;
неправомірне використання ІТ-систем за участю третіх сторін;
фінансове шахрайство з використанням інформаційних систем;
DOS-атаки;
втрата конфіденційних даних клієнта;
СПАМ;
неправомірна дія співробітників з використанням інформаційних систем;
віруси, черв’яки, троянські програми;
інші;
невідсортировані.
За допомогою програмного продукту «1С: Предприятие», в режимі «Конфігуратор» можна управляти об’єктами (даними і метаданими), які містяться в програмі, налаштовівути під потрібну задачу, після чого запускається режим роботи під назвою «1С: Підприємство», в якому користувач отримує доступ до основних функцій, реалізованих в даному прикладному рішенні (конфігурації).
Технологічна платформа «1С: Підприємство» являє собою програмну оболонку над базою даних і має свою внутрішню мову програмування, що забезпечує, крім доступу до даних, можливість взаємодії з іншими програмами.
Клієнтська частина платформи функціонує тільки в середовищі ОС Microsoft Windows, а також може функціонувати на ОС Linux [56].
Проаналізувавши літературу [ 12-15, 43-56] , було виділено ключові слова по кожному інциденту.ІБ:
«викрадення конфіденційної інформації»: DDoS, DOS-атака, ICMP-флуд, SYN-флуд, UDP-флуд, веб-сервер, виведення зі строю, відмова в обслуговувані, гибридний метод виявлення, доступ до серверу, захист від DOS-атаки, мережеві утеліти ping, методи виявлення DoS-атак, сигнатурний метод, статистичний метод, флуд.
«Викрадення конфіденційної інформації»: Firewalls, витік конфіденційної інформації, записуючі пристрої, збирати відомості про, міжмережеві екрани, незаконне збирання конфіденційної інформації, підслуховуючі пристрої, шляхом викрадення.
«Віруси черв'яки, троянські програми»: вірус, доступ до файлів, зловмисник, злом пароля, кіберзлочин, поштовий черв'яки, прихована загроза, сигнатурний вірус, троянські коні, троянські програми, черв'як.
«Втрата конфіденційних даних клієнта»: витік даних, витік конфіденційних даних клієнта, втрата даних клієнта, дані про клієнта, загроза витоку, загроза конфіденційним даним клієнта, інформація про клієнта, клієнт, конфіденційні дані, конфіденційні дані клієнта, ненавмисна втрата даних клієнта, халатність персоналу.
«Неправомірне використання ІТ-систем за участю третіх сторін»: знімаючі носії, ІТ-система, неправомірне використання, несанкціонований доступ, носії інформації, проникнення в приміщення, треті особи.
«Неправомірні дії співробітників з використанням інформаційних систем»: використання інформаційних технологій, використання ІТ, ненадійні співробітники, ненадійність, неправомірні дії, персональні дані.
«Низька якість ПЗ»: втрата даних, знищення бази даних, модифікація БД, некоректна робота, низький рівень надійності послуг, операційна система, помилка при управлінні, пошкодження бази даних,програмне забезпечення, програмний вплив, управління програмним забезпеченням.
«Спам»: e-mail, icq, SPAM, комерційна інформація, масова розсилка, письма щастя, реклама, розсилка реклами, соціальна мережа, спам-атака, спамер, спамери, фільтр.
«Фізична безпека»: електроживлення, засоби зв'язку, захист кабельної системи, ІБ, інформаційна безпека, кабельна безпека, несправність обладнання, серверні засоби, серверне обладнання, технічне обладнання, технічні засоби, утилізація обладнання, фізичні активи.
«Фінансове шахрайство з використанням інформаційних систем»: банківська сфера, бухгалтерські документи, взлом пароля, довіра, засоби доступу, кошти, криптографічні методи, інформаційні технології, обман, пароль, правила відправлення повідомлення, правила доступу, рахунок клієнта, фінансове шахрайство, фінансові дані, фінансові махінації, фінансові ресурси, цінні папери, шахрайство.
Для «Інші» та «Невідсортовані» не виділялися ключові слова, адже повідомлення, які будуть міститися в даних об’єктах будуть переміщуватися вручну користувачем ПЗ.
Перечень ключових слів не можна вважати остаточним і в подальшому може доповнюватися і змінюватися.
За допомогою ключових слів програмний модуль аналізуватиме дані про інцидент в автоматичному режиму і формуватиме звіт на виході програми буде видаватися статистика за певний проміжок часу:
по частоті виникнення інциденту;
по заявникам (скільки заявок було надіслано);
по статусу опрацювання (опрацьовано та неопрацьовано).
Платформою «1С: Підприємство» надається фіксований набір об’єктів, орієнтованих на вирішення завдання прикладної області:
Константи – це прикладні об'єкти конфігурації. Вони дозволяють зберігати в інформаційній базі дані, які не змінюються в часі, або змінюються дуже рідко. Кожна константа дозволяє зберігати одне значення.
Довідники – це прикладні об'єкти конфігурації, які дозволяють зберігати в інформаційній базі дані, що мають однакову структуру і характер списків. Це може бути, наприклад, список співробітників, перелік товарів, список постачальників або покупців.
Документи – прикладні об'єкти конфігурації, які дозволяють зберігати в прикладному рішенні інформацію про здійснені операції або про події, що відбулися в "життя" організації взагалі. Це можуть бути, наприклад, прибуткові накладні, накази про прийом на роботу, рахунки, платіжні доручення і т.д..
Журнали документів – це прикладні об'єкти конфігурації. Вони призначені для перегляду документів різних видів. Для журналу документів можуть бути визначені графи, призначені для відображення реквізитів документів різного виду, віднесених до даного журналу.
Перерахування – прикладні об'єкти конфігурації, які дозволяють зберігати в інформаційній базі набори значень, які не змінюються в процесі роботи прикладного рішення.
Звіти – це об'єкти, які призначені для обробки накопиченої інформації і отримання зведених даних в зручному для перегляду та аналізу вигляді. Конфігуратор дозволяє формувати набір різних звітів, достатніх для задоволення потреби користувачів системи в достовірній і докладній вихідній інформації.
Як правило, для формування вихідних даних звіт використовує систему компоновки даних. Але, взагалі кажучи, звіт може містити довільний алгоритм формування «паперового» або «електронного» звіту на вбудованій мові.
Звіт може містити одну або декілька форм, за допомогою яких, при необхідності, можна організувати введення будь-яких параметрів, які впливають на хід алгоритму.
Обработки – це об'єкти конфігурації, які призначені для виконання різних дій над інформацією. Наприклад, з їх допомогою можна виконувати видалення із системи застарілих даних, імпорт інформації з інших систем та багато іншого. Характер виконуваних в цьому випадку дій відображає назву об'єкта конфігурації – Обработка, так як в результаті інформація, що зберігається в системі, зазнає будь-яких змін.
Обработка може містити одну або декілька форм, за допомогою яких, при необхідності, можна організувати введення будь-яких параметрів, які впливають на хід алгоритму. Висновок результатів виконання алгоритму на екран і принтер здійснюється за допомогою конструктора запиту з обробкою результату.
Основна відмінність обробки від звіту полягає в тому, що звіт може використовувати схему компоновки даних, а в іншому обробка не відрізняється від звіту.
План рахунків – кожен з даних об'єктів дозволяє описати сукупність синтетичних рахунків, призначених для групування інформації про діяльність організації. Шляхом настройки плану рахунків організується, власне, необхідна система обліку.
та інші конфігуратори [56].
Для виконання мети дипломної роботи будуть застосовуватися тільки такий набір об’єктів: Довідники; Документи, Звіт, Обработки, Регістр накопичення, Перерахування.
Потрібно розробити БД, що має містити такі об’єкти:
Довідники: КласифікаторІнцидентів, КлючовіСлова, НастройкиПід-ключенняДоПочти, Заявники.
Документи: РеєстраціяІнцидентів.
Перерахування:СтатусиІнцедентів, ТипиЗаявників.
Звіти: СтатистикаІнцидентів.
Обработки: СозданиеАвтоматическихЗаявок, ЗагрузкаАвтоматомЗая-вокИзПапки.
Регістр накопичення: Інциденти.
Довідник «КласифікаторІнцидентів»
В даному довіднику будуть зберігатися обрані класифікатори інцидентів ІБ, з прикріпленими до них ключовими словами.
Структура довідника:
Реквізити:
Таблиця 2.1
Реквізити довідника «КласифікаторІнцидентів»
|
Код |
Тип: Строка (9 символів) |
|
Наименования |
Тип: Строка (100 символів) |
Табличні частини:
Таблиця 2.2
Таблична частина довідника «КласифікаторІнцидентів»
|
КлючовеСлово |
Тип: СправочникСсылка.КлючовіСлова |
Довідник «КлючовіСлова»
Цей довідник містить ключові слова по кожному інциденту ІБ.
Структура довідника:
Реквізити:
Таблиця 2.3
Реквізити довідника «КлючовіСлова»
|
Код |
Тип: Строка (9 символів) |
|
Наименования |
Тип: Строка (100 символів) |
Довідник «НастройкиПідключенняДоПошти»
Цей довідник міститиме інформацію про налаштування підключення до пошти з якої будуть скачуватися файли про інцидент ІБ.
Структура довідника:
Реквізити:
Таблиця 2.4
Реквізити довідника «НастройкиПідключенняДоПочти»
|
Код |
Тип: Строка (9 символів) |
|
Наименования |
Тип: Строка (100 символів) |
|
Адрес сервера РОР3 |
Тип: Строка (50 символів) |
|
Аутентификация РОР3 |
Тип: Строка (50 символів) |
|
Порт РОР3 |
Тип: Число (10 символів) |
|
Пользователь |
Тип: Строка (100 символів) |
|
Пароль |
Тип: Строка (100 символів) |
|
Время ожидания |
Тип: Число (3 символи) |
Довідник «Заявники»
Довідник «Заявники» надаватиме відомості про заявника, який надсилає дані про інцидент ІБ.
Структура довідника:
Реквізити:
Таблиця 2.5
Реквізити довідника «Заявники»
|
Код |
Тип: Строка (9 символів) |
|
Наименование |
Тип: Строка (100 символів) |
|
Тип заявника |
Тип: ПеречислениеСсылка.ТипиЗаявників |
|
Електронна пошта |
Тип: Строка (100 символів) |
Документ «РеєстраціяІнцидентів»
Цей об’єкт призначений для реєстрації інциденту.
Структура довідника:
Реквізити:
Таблиця 2.6.
Реквізити документу «РеєстраціяІнцидентів»
|
Дата |
Тип: Дата |
|
Номер |
Тип: Строка (9 символів) |
|
Ідентифікатор інциденту |
Тип: СправочникСсылка.КласифікаторІнцидентів |
|
Опис інциденту |
Тип: Строка (200 символів) |
|
Заявник |
Тип: СправочникСсылка.Заявники |
|
Електронна пошта |
Тип: Строка (100 символів) |
|
Статус |
Тип: ПеречислениеСсылка.СтатусиІнцедентів |
|
Коментарій |
Тип: Строка (100 символів) |
Перерахування «СтатусиІнцедентів»
Дане перерахування потрібне для того, щоб зазначити статус інциденту.
Значення:
НеОпрацьовано;
ВПроцесі;
Опрацьовано.
Перерахування «ТипиЗаявників»
Це перерахування показує тип заявника.
Значення:
ФізЛице;
ЮрЛице.
Звіти «СтатистикаІнцидентів»
В даному звіті буде виводитися статистика інцидентів за вказаними в налаштуваннях параметрами:
за статусом інциденту;
за заявником;
по ідентифікатору (заявник, опис інциденту, статус);
діаграма.
Обработки «СозданиеАвтоматическихЗаявок»
Ця обработка потрібна для створення автоматичних заявок.
Структура обработки:
Реквізити:
Таблиця 2.7
Реквізити обработки «СозданиеАвтоматическихЗаявок»
|
Количество |
Тип: Число (4 символів) |
|
ПапкаЗаявок |
Тип: Строка (100 символів) |
|
ШаблонИменФайла |
Тип: Строка (100 символів) |
Обработки «ЗагрузкаАвтоматомЗаявокИзПапки»
Дана обработка потрібна для автоматичного формування тестування роботи загрузки.
Структура обработки:
Реквізити:
Таблиця 2.8
Реквізити обработки «ЗагрузкаАвтоматомЗаявокИзПапки»
|
ПапкаЗаявок |
Тип: Строка (100 символів) |
Регістр накопичення «Інциденти»
В даному об’єкті використовуються такі Виміри:
ІдентифікаторІнцидента:
Структура регістру:
Реквізити:
Таблиця 2.9
Реквізити регістру «ІдентифікаторІнцидента»
|
ІдентифікаторІнцидента |
Тип: СправочникСсылка.КласифікаторІнцидентів |
ОписІнцидента:
Структура регістру:
Реквізити:
Таблиця 2.10
Реквізити регістру «ОписІнцидента»
|
ОписІнцидента |
Тип: Строка (10 символів) |
Заявник:
Структура регістру:
Реквізити:
Таблиця 2.11
Реквізити регістру «Заявник»
|
Заявник |
Тип: СправочникСсылка.Заявники |
Статус:
Структура регістру:
Реквізити:
Таблиця 2.12
Реквізити регістру «Статус»
|
Статус |
Тип: ПеречислениеСсылка.СтатусиІнцедентів |
А також використовуються Ресурсы:
Кількість:
Структура ресурсу:
Реквізити:
Таблиця 2.13
Реквізити регістру «Кількість»
|
Ресурсы |
Тип: Число (15 символів) |
Всі інциденти ІБ СУІІБ, які надходять на поштовий сервер класифікуються за допомогою програмного середовища «1С: Предприятие». Повідомлення подається на вхід програми, а на виході виводиться статистика по кожному класифікатору за певний проміжок часу і тим самим автоматизує роботу СУІІБ НАУ.
При автоматизації процесів управління інцидентами в першу чергу необхідно приділяти увагу автоматизованій обробці подій ІБ – основі практично будь-якого інциденту. Події від різних технічних засобів захисту є найважливішим постачальником інформації про процеси, що відбуваються в СУІІБ, порушення, ризики. На підставі подій проводиться коригувальні дії, оцінка поточної захищеності системи, ефективності функціонування СУІІБ. Тільки володіючи повним і достовірним набором подій, можна провести належне розслідування інцидентів, отримати уявлення про динаміку розвитку СУІІБ. Можна сказати, що події – основний канал зворотного зв'язку для керуючих впливів у рамках СУІІБ. Важливим є і те, що події легко документовані і відтворювані.
Організація процесу обробки подій (інцидентів) без використання засобів автоматизації являє собою складну і трудомістку задачу. Необхідно збирати і консолідувати велику кількість даних в різних форматах, вести центральний архів. Для ручної обробки подій потрібна велика кількість висококваліфікованих фахівців-аналітиків. В силу великого обсягу рутинної ручної роботи обробка подій часто буває неповною, не відбиває всю повноту поточної ситуації. При цьому можлива ситуація, коли події, критичні для надійного та захищеного функціонування бізнес-систем, виявляться поза полем зору аналітиків, і щодо них не будуть прийняті відповідні превентивні заходи.
Для підтримки процесу обробки подій на рівні, відповідному сучасним вимогам, можливе застосування різних автоматизованих систем обробки подій.
Такі системи повинні забезпечувати наступний функціонал [4]:
дозволяти збирати події від всіх технічних засобів забезпечення захищеності, використовуваних в рамках СУІІБ;
проводити нормалізацію подій, приводячи їх до єдиного формату;
здійснювати зберігання подій способом, що дозволяє зберігати необхідні обсяги даних;
надавати інструментарій для пошуку в сховищі даних;
надавати механізми формування звітів різного роду;
системи обробки подій повинна бути розширюваною і масштабованої;
опціонально здійснювати кореляцію зібраних подій.
Процес обробки подій (інцидентів) автоматизованими системами включає такі основні кроки: нормалізація (приведення до єдиного формату) даних, агрегування (накопичення), кореляція і візуалізація. На перших двох стадіях інформація про події безпеки збирається практично з усіх використовуваних в рамках СУІІБ засобів захисту: міжмережевих екранів, систем виявлення атак, антивірусних систем, операційних систем та програм різних виробників, засобів контролю фізичного доступу, і перетвориться в єдиний, зручний для розуміння формат . Зібрані дані піддаються кореляції і виводяться на консоль оператора системи.
Розвинені засоби пошуку дозволяють проводити оперативне і всебічне розслідування інцидентів, забезпечувати факт наявності та функціонування засобів захисту в рамках СУІІБ при проведенні різних аудитів.
Система автоматизації процесу управління інцидентами додатково дозволить:
обробляти і зберігати інформацію про події та інциденти ІБ, а також про всі дії щодо їх усунення;
оперативно приймати рішення щодо усунення інциденту, який виник, грунтуючись на аналізі інформації про попередні інциденти;
проводити аналіз накопичених даних [4].
Тому, удосконалена СУІІБ НАУ за допомогою програмного модуля дасть змогу в подальшому формувати статистику щодо інцидентів, які надходять на поштовий сервер «Zimbra». Зібрана статистика буде використана для запобігання виникненню рецидиву, а також проведення превентивних заходів усунення наслідків інцидентів ІБ.
Процедура обробки інцидентів та інцидентів ІБ сприяє поліпшенню стандартних операцій і процедур в університеті, щоб запобігти повторній появі інциденту й мінімізувати будь-які наслідки й витрати. Звіт про перевірку виконання може призвести до зміни процесів обробки інциденту. При цьому керівникам NAU-CERT надаються короткі відомості про інциденти та інциденти безпеки, статистика появи, їхні масштаби, наслідки та витрати, а також ефективність роботи команди.
Команда NAU-CERT використовує поштовий сервер «Zimbra» на який надходять дані про інформаційні інциденти, що відбулися в ІКС університету та студмістечка НАУ.
«Zimbra» – повноцінний поштовий сервер, який надає адміністраторам і їх користувачам інноваційні особливості, здатні вирішити труднощі, з якими стикаються організації, використовуючи сьогоднішню інфраструктуру комунікацій. Головні переваги містять у собі: сумісність з Windows, Mac, GNU \ Linux; масштабованість; гнучке управління; російську мову; загальні компоненти пошти для корпоративної роботи; веб-клієнт і т.д. «Zimbra» має деякі можливості, такі як:
глобальна книга адрес – видно всі поштові ящики в домені співробітників університету;
календар і щоденник – можна планувати завдання і робити нагадування про них;
документи – можна зберігати, переглядати і редагувати прямо в браузері.
Також зручно є те, що на даному почтовому сервері можна робити всі ресурси (адресну книгу, або частину її, деякі каталоги з листами, документи, календарі та завдання) доступними для інших користувачів, наприклад, для всіх всередині кафедри.
Можна підключати зовнішні поштові ящики з яких усі листи будуть копіюватися на сервер Zimbra [49].
Для автоматизації збору, реєстрації та обробки інформації щодо інцидентів ІБ впроваджується підсистема автоматизованої обробки інцидентів. На рис. 2.3 зображено її загальну функціональну схему. В цій схемі використовується класична модель безперервного поліпшення процесів, що одержала назву від циклу Шухарта-Деминга - PDCA (Plan – планування, Do – виконання, Check – перевірка, Act – дії).
Рис. 2.3. Функціональна схема системи обробки інцидентів ІБ ІКС НАУ
За допомогою оперативно-диспетчерського контролю автоматизованою системою обробки інцидентів ІБ проводиться оцінка стану СУІІБ і виявлення інцидентів. Групою аналізу та розслідування інциденту на основі раніше здобутого досвіду та поточних даних виробляється план дій. У результаті цього аналізу, планування та охоронно-роз’яснювальної роботи виробляються рішення та заходи обробки інциденту безпеки.
На виконання цих заходів проводяться ремонтні та аварійно-відновлювальні роботи. Реалізація рішень після перевірки та остаточного розслідування заноситься у базу даних системи.
Основні етапи циклічного процесу реагування на інциденти безпеки СУІІБ у ІКС університету та студмістечка НАУ такі:
оперативно-диспетчерський контроль стану СУІІБ (виявлення й реєстрація інциденту безпеки ІКС НАУ). Оперативні дані робочих станцій повинні аналізуватися та оцінюватися у пункті контролю та управління на предмет наявності ознак інцидентів за допомогою бази даних системи. Після чого кожен диспетчер, оператор чи інженер повинен одержати інструкцію, що визначатиме, які повинні бути його дії. Електронний звіт щодо виявлення та реєстрації інциденту безпеки СУІІБ, повинен містити докладний опис інциденту, точне місце інциденту та ступінь серйозності (ушкоджень), перелік залучених осіб, прізвище співробітника, що зафіксував інцидент, дату виникнення й реєстрації.
Ремонтні та аварійно-відновлювальні роботи ІКС (усунення причин, наслідків інциденту, його обробка). База даних системи на підставі отриманого електронного звіту повинна надавати інструкцію щодо усунення причин і наслідків інциденту безпеки СУІІБ, включаючи опис необхідних ремонтних та аварійно-відновлювальних заходів, які необхідно розпочати, а також строки, протягом яких варто усунути наслідки й причини інциденту. Обов’язково потрібно описати інциденти кожного рівня й строки їх усунення.
Аналіз та розслідування інцидентів безпеки ІКС НАУ. Повинна надавати інформаційно-аналітичну підтримку у вигляді досвіду та знань, що містять у собі визначення винних у виникненні інциденту, збір доказів, визначення дисциплінарних стягнень тощо.
Охоронно-роз’яснювальні роботи щодо СУІІБ – цей етап направлено на реалізацію коригувальних та превентивних дій. На постійній регулярній основі, й особливо після усунення наслідків інциденту та відновлення нормального функціонування ІКС НАУ, доцільно організовувати та виконувати заходи щодо запобігання повторного виникнення інциденту. Для визначення необхідності реалізації таких заходів база даних системи повинна провести аналіз ризиків, у рамках якого визначити доцільність охоронно-роз’яснювальної роботи у вигляді коригувальних і превентивних заходів.
Для того, щоб процедура виконувалася правильно й ефективно, всі ці етапи повинні безупинно, послідовно й циклічно повторюватися. Комплексний підхід до забезпечення безпеки вимагає, щоб реалізація засобів та заходів захисту розпочиналась ще на етапі проектування системи [13].