3.2.3 Перспективи розвитку, модернізації Системи.
Повинна бути передбачена можливість додавання нових функцій в Систему, поліпшення коду Системи (ре факторинг коду, що дозволяє виявити похибки в проектуванні і реалізації окремої функції до того, як помилки будуть визначати стиль розробки).
Повинна бути передбачена можливість розширення механізму аутентифікації і персоналізації змісту відповідно до появи нових вимог до Системи.
Повинна бути передбачена можливість вдосконалення механізму публікації, спрощення та зведення до допустимого мінімуму дій з розміщення інформації в Системі.
Справжнє ТЗ описує вимоги до розробки першої (експериментальної) версії Системи.
3.2.4 Вимоги до надійності.
Система повинна забезпечувати відновлення інформації при програмно-апаратних збоїв (відключення електроживлення, відмовах носіїв інформації, віруси і т.д.), стабільність роботи в розрахованому на багато користувачів режимі і живучість Системи при виході з ладу окремих її компонентів.
3.2.5 Вимоги щодо збереження інформації при аваріях.
Збереження інформації при збоях і аваріях повинна досягатися для баз даних, файлів даних на файлових серверах - за рахунок архітектури побудови технічних засобів і програмного забезпечення Системи.
При цьому, повинно бути забезпечено автоматичне відновлення даних в базах даних і відновлення файлів з даними на серверах за станом на момент часу, що не перевищує більш ніж 10 годин від моменту збою або аварії технічних і програмних засобів, що забезпечують зберігання цих даних.
Крім цього, повинна бути передбачена система довгострокового архівування даних і файлів, розміщених на серверної частини системи, для забезпечення схоронності вищевказаних даних в разі форс-мажорних обставин, пожеж, стихійних лих і т.д. Повний архів даних повинен формуватися з періодичністю, встановленої адміністратором, або по досягненню критичного розміру попереднього архіву (за замовчуванням). Кожен архів повинен формуватися в двох примірниках, один з яких повинен зберігатися безпосередньо в місці розміщення Системи, інший - в приміщенні з контрольованим обмеженим доступом (порядок доступу до архіву повинен визначатися керівництвом служби ІБ) в будівлі, відмінному від того, де фізично розміщена Система.
Для забезпечення схоронності призначених для користувача даних архітектурою побудови Системи повинно бути передбачено зберігання інформації виключно в базах даних і файлах, що розміщуються на серверах Системи.
3.2.6 Вимоги до ергономіки та технічної естетики.
Дизайн Системи повинен відповідати таким вимогам по ергономіки та технічної естетики:
• адекватно відображатися в залежності від типу підключення користувача і від його особистих переваг;
• бути достатньо «легким» за обсягом графічних елементів і забезпечувати якомога більшу швидкість завантаження модулів Системи;
• забезпечувати легку ідентифікацію розділу Системи, в якому знаходиться користувач;
• забезпечувати мінімум зусиль і тимчасових витрат користувача для навігації по розділах Системи;
• володіти розвиненою системою пошуку інформації;
• коректно відображатися при всіх можливих дозволах і кількості одночасно відображаються монітора;
• володіти системою контекстних підказок на сторінках, де у користувача потенційно можуть виникнути труднощі;
• забезпечувати прийнятний результат при роздруківці сторінок Системи на принтері;
• коректно відображати інформацію на комп'ютерах без встановлених флеш-модулів, з відключеною підтримкою скриптів і ін .;
• передбачати можливість підтримки мульти мовний змісту;
• передбачати можливість кроссплатформенной підтримки;
передбачати сумісність з популярними браузерами.
3.2.7 Вимоги до функцій (завдань), що виконуються Системою.
Інтерфейс Системи повинен забезпечувати наочне, інтуїтивно зрозуміле уявлення структури, розміщеної на ньому інформації, швидкий і логічний перехід до розділів і сторінок. Навігаційні елементи повинні забезпечувати однозначне розуміння користувачем їхнього змісту: посилання на сторінки повинні бути забезпечені заголовками і коментарями (підказками), умовні позначення відповідати загальноприйнятим. Графічні елементи навігації повинні бути забезпечені альтернативної підписом.
Система повинна забезпечувати навігацію по всім доступним користувачеві ресурсів і відображати відповідну інформацію. Для навігації повинна використовуватися система контент-меню, яке має являти собою текстовий блок (список гіперпосилань). Місце розташування меню на сторінці залежить від затвердженого дизайну типовий сторінки. Всі номери нові сторінки і елементи повинні відкриватися в новій вкладці.
3.2.8 Пошук інформації.
Для пошуку інформації повинна застосовуватися пошукова система, розроблена для порталу в залежності від типу використовуваних баз даних. Пошук інформації в документах повинен здійснюватися засобами бази даних, використовуваної при розробці.
Крім загального пошуку, повинні бути доступні локальні пошукові інтерфейси і фільтри, призначені для пошуку специфічної інформації в конкретних розділах Системи.
Пошук повинен здійснюватися за принципом максимальної релевантності.
3.2.9 Наповнення інформацією.
Сторінки всіх розділів сайту повинні формуватися програмним шляхом на підставі інформації з баз даних на сервері.
Наповнення інформацією повинно проводитися з використанням спеціальних форм введення. Повинна бути передбачена можливість розміщення інформації, посилань і файлів будь-якого формату, розміщення і форматування тексту, графічній, табличній і мультимедійної інформації.
Після здачі Системи в експлуатацію інформаційне наповнення розділів, включаючи обробку та підготовку до публікації графічних матеріалів, має здійснюватися Замовником самостійно.
3.2.10 Можливість розширення.
Додавання нових функціональних можливостей не повинно призводити до погіршень в раніше розроблених і експлуатованих частинах Системи. Взаємодія з зовнішніми інформаційними системами, якщо воно буде потрібно, повинно будуватися на використанні загальноприйнятих відкритих стандартів передачі і структурування інформації. Даний документ описує функціонал першої версії Системи, що повинно враховуватися при її розробці.
3.2.11 Простота впровадження, підтримки і адміністрування
Регламентні процеси установки на новому комплекті обладнання, підтримки і адміністрування повинні бути описані в документації і детально опрацьовані в ході реалізації Системи з урахуванням забезпечення їх простоти і зручності. При цьому повинні бути явно сформульовані вимоги до кваліфікації персоналу, який буде експлуатувати Систему.
3.3 Автоматизація модуля інформаційних активів
Для скорочення часу обробки даних моніторингу в Систему було введено уніфікаційні дані баз інформаційних активів.
3.3.1 Характеристика об'єкта автоматизації
В даний час одним з ключових напрямків інформаційної безпеки в багатогалузевих компаніях є досягнення максимальної синергії та консолідації в СМІБ. З огляду на це, логічним кроком стануть удосконалення наступних областях:
• підвищення ефективності роботи служб ІБ в вертикально-інтегрованої багатогалузевий компанії і вибудовування відмовостійкої системи реагування на події ІБ;
• реалізація комплексної системи заходів щодо зменшення загроз ІБ;
• приведення до єдиних стандартів моделей взаємодії між службами ІБ підрозділів Групи, а також більш чіткий поділ їх відповідальності всередині вертикалі СМІБ, вибудовування чіткої системи взаємної підзвітності.
При цьому виділяється ряд основних напрямків, за якими відбувається автоматизація і консолідація процесів СМІБ, серед яких одним з найважливіших є поліпшення якості та ефективності роботи служб ІБ.
З цією метою вводяться єдині стандарти, форми і методи роботи в рамках СМІБ, співробітники служб ІБ отримують можливість оперативного взаємодії та експертної підтримки при максимальній прозорості роботи СМІБ. Саме такий підхід до побудови СМІБ використовується в провідних світових стандартах в області ІБ в даний час.
В даний момент в підрозділах Групи відсутня єдність механізмів роботи, що викликає певну ентропію і низький ступінь консолідації. З огляду на, що інформаційні потреби кожного з підрозділів мають досить високий ступінь спільності, впровадження єдиної системи централізованого управління процесами СМІБ істотно підвищить функціональні можливості використовуваних рішень і дозволить виключити неуніфікованих, витратні процеси підготовки, узгодження, затвердження і реалізації.
Для досягнення єдності механізмів і узгодженості роботи служб ІБ необхідно:
• забезпечення активної участі представників служб ІБ ключових підрозділів Групи в розробці та обговоренні спеціалізованої експертної системи;
• сприяння представників служб ІБ всіх підрозділів Групи в рамках надання інформації, необхідної для побудови максимально релевантної і зручної системи централізованого управління СМІБ;
• забезпечення відкритого доступу всіх відповідальних співробітників служб ІБ до інформації, необхідної в процесі їх діяльності.
3.3.2 Автоматизація модуля.
В рамках управління інформаційною безпекою одним з найважливіших процесів є процес обліку і класифікації об'єктів захисту, або так званих інформаційних активів. K інформаційних активів компанії зазвичай відносять інформацію, апаратне, програмне забезпечення та інші засоби, необхідні для отримання, обробки та зберігання даних, які використовуються в певних бізнес-процесах. Це можуть бути сховища даних, бази даних, бази клієнтів, виробничі показники (звіти), фінансові звіти, інформаційні системи і т. ін. Найчастіше процес підтримки даних про інформаційні активах в актуальному стані представляється скрутним, враховуючи складність інформаційної інфраструктури, велика кількість прикладних систем, де обробляється інформація обмеженого доступу, великий перелік критичних активів, які підлягають захисту т. ін. Зазначені особливості обумовлюють необхідність використання засобів автоматизації для підтримки процесів управління ІБ.
3.3.3 Опис модуля.
Модуль призначений для автоматизації діяльності співробітників департаменту інформаційної безпеки, а також власників інформаційних активів. Головною метою автоматизації каталогу інформаційних активів є оптимізація та удосконалення системи управління ІБ.
3.3.4 Опис рішення.
Рішення реалізовано на базі програмного забезпечення з закритим вихідним кодом і являє собою готовий інструмент для оцінки та обробки ризиків інформаційних активів компанії. Для роботи з системою не потрібна установка додаткових клієнтських додатків, достатня наявність будь-якого сучасного браузера. Рішення включає в себе такі можливості:
- Централізоване зберігання інформації по всіх об'єктах оцінки ризиків;
- Централізоване зберігання інформації за наявними уразливості ІБ, ймовірним загрозам і ризикам, пов'язаним з реалізацією загроз;
- Проведення оцінки ризиків для кожного інформаційного активу відповідно міжнародним стандартам;
- Розробка плану обробки ризиків і призначення завдань виконавцям за його реалізації;
- Розмежування прав доступу користувачів до інформації в системі відповідно до рольової моделі;
- Можливість одночасної роботи користувачів при проведенні оцінки ризиків;
- Відправлення повідомлень власникам інформаційних активів про внесення змін до оцінку;
- Можливість перегляду всіх дій над об'єктами системи;
- Побудова звітів з інформацією про оцінку ризиків, а також плані обробки ризиків з можливістю вивантаження в Excel.
3.3.5 Завдання, які вирішуються.
Процес автоматизації спрямований на оптимізацію та удосконалення системи управління ІБ, створення реєстру інформаційних активів і управління записами. Саме в ньому концентруються дані про всі активи компанії, визначається їхня критичність, ступінь впливу на бізнес-процеси компанії і надалі ці дані можуть використовуватися в модулі.
• Формування довідників активів компанії;
• Оцінка критичності об'єктів захисту;
• Класифікація активів і передача їх в модуль;
• Інтеграція з системами інвентаризації;
• Створення єдиного інформаційного середовища для взаємодії з суміжними системами.
3.4 Етапи та результати виконання проекту.
Проект автоматизації модуля інформаційних активів проходить через наступні етапи:
1. Інвентаризація інформаційних активів. Визначення всіх інформаційних активів компанії та поточного їх стану.
2. Категоризація інформаційних активів. Визначення ключових активів, від яких залежить функціонування бізнес-процесів компанії.
3. Логічне проектування процесу управління каталогом інформаційних активів. Структурування, опис та проектування процесів для подальшої автоматизації.
4. Автоматизація процесу управління каталогом інформаційних активів.
5. Проектування розроблених процесів на систему автоматизації. Автоматизація процесів.
В результаті автоматизації модуля інформаційних активів формується перелік активів, визначається їхня критичність з урахуванням впливу на бізнес-процеси компанії, а також створюються матриці доступу для розподілу прав до інформаційних активів. Автоматизація модуля інформаційних активів дозволяє:
• Забезпечити оперативну підтримку в актуальному стані інформації про активи в умовах обмеженого штату співробітників і великої кількості облікових об'єктів;
• Забезпечити застосування єдиних ідентифікаторів активів, що дозволяють використовувати дані для реалізації інших процесів управління інформаційною безпекою (управління ризиками, управління інцидентами).
3.5 Налаштування системи моніторингу ІА.
3.5.1 Користувач.
Для редагування властивостей користувача необхідно в лівому верхньому кутку в меню, яке викликається натисканням на ім'я користувача, вибрати пункт "профіль" (рис. 3.1).
Рис. 3.1. Вибір профілю
Після чого буде відкрито вікно редагування профілю користувача (рис. 3.2).
Рис. 3.2. Вікно редагування профілю користувача
3.5.2 Двухфакторна авторизація.
Для включення двухфакторной авторизації (далі 2FA) для свого облікового запису необхідно встановити параметр "включити 2FA" (рис. 3.3), після чого в формі з’явиться QR-код, який необхідно сканувати додатком Google Authenticator.
Рис. 3.3. Двуфакторна авторизація
Після успішної активації 2FA форма входу в систему змінить свій вигляд. Після введення логіна і пароля буде відображено додаткове поле OTP, код для якого знаходиться у вас в телефоні в Google Authenticator.
3.5.3 Головна сторінка.
На головній сторінці відображені:
- Перелік відкритих вразливостей; (рис. 3.4):
- Список інцидентів;
- Статистика записів в базу даних.
Рис. 3.4. Вікно головної сторінки.
При виборі уразливості в списку її можна відредагувати. Редагується тільки одна уразливість, а не всі із запису (рис. 3.5.).
Рис. 3.5. Викно списку вразливостей.
3.5.4 Вразливості.
Форма редагування вразливостей представлена на рисунку 3.6.
Рис.3.6. Вікно редагування.
3.5.5 Створення нової групи активів.
Натиснувши на "+" в попередньому вікні відкриється форма створення нової групи активів, в якій потрібно вказати назву групи і вибрати активи для групи (рис. 3.7). Для збереження необхідно натиснути на кнопку "Зберегти".
Рис. 3.7. Створення нової групи активів
Після збереження групи вона автоматично з'явиться у списку вибору груп активів.
3.5.6 Створення вразливості.
Для створення вразливості необхідно на таблиці вразливостей в "Форма редагування вразливості" викликати контекстне меню натисненням правої кнопки миші і вибрати "новий запис" (рис. 3.8).
Рис. 3.8. Вікно "Форма редагування вразливості".
Після чого з'явиться запис в таблиці, яку необхідно заповнити. Для редагування доступні наступні поля "опис вразливості", "ймовірність", "збиток" (рис. 3.9.). Поля «бал» і «статус» недоступні для редагування. Поле статус доступно для редагування тільки з Dashboard.
Рис. 3.9. Створення нової вразливості.
3.5.7 Розділ "Інциденти".
Для створення нового інциденту необхідно на головній сторінці на таблиці "Інциденти" викликати контекстне меню і вибрати пункт "новий запис" (рис. 3.10).
Рис. 3.10. Вікно форми "Інциденти".
Заповнивши форму необхідно натиснути кнопку "зберегти".
Перегляд реєстру інцидентів проводиться шляхом переходу по меню "Інциденти". У цьому реєстрі можна редагувати і створювати нові інциденти (рис. 311).
Рис. 3.11. Створення нового інциденту.
1 2 3 4 5 6 7 8 9