Побудова моделі загроз інформаційній безпеці інформаційної системи з використанням методології об'єктно-орієнтованого проектування

питання безпеки

Грибанова-підкинемо М.Ю. - Побудова моделі загроз інформаційній безпеці інформаційної системи з використанням методології об'єктно-орієнтованого проектування // Питання безпеки. - 2017. - № 2. - С. 25 - 34. DOI: 10.7256 / 2409-7543.2017.2.22065 URL: https://nbpublish.com/library_read_article.php?id=22065

Побудова моделі загроз інформаційній безпеці інформаційної системи з використанням методології об'єктно-орієнтованого проектування

Анотація.

DOI:

Дата направлення до редакції:

Дата рецензування:

Дата публікації:

Abstract.

Keywords:

Загальні питання використання об'єктно-орієнтованого підходу при проектуванні систем інформаційної безпеки

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

1) оцінку поточного стану інформаційної безпеки інформаційної системи;

2) опис моделі загроз інформаційній безпеці;

3) формування рекомендацій щодо вдосконалення системи забезпечення інформаційної безпеки.

З точки зору проектування системи інформаційної безпеки, перші два етапи є взаємопов'язаними, так як оцінка поточного стану інформаційної безпеки проводиться з урахуванням актуальних загроз інформаційної безпеки, які визначаються в результаті аналізу моделі загроз. В оцінці поточного стану системи важливу роль відіграє проект інформаційної системи, який дозволяє детально проаналізувати функціонал системи на предмет захищеності від можливих загроз інформаційної безпеки. Це, до речі, дозволяє аналізувати захищеність системи на будь-якому етапі її життєвого циклу. Для сучасних систем, що відрізняються складною багаторівневою архітектурою, безліччю неоднорідних компонентів і структур, розробка проекту є також автоматизованим процесом, який здійснюється із залученням CASE (computer-aided software engineering) коштів [1] . Цілком розумно і при розробці проекту системи інформаційної безпеки використовувати аналогічні інструменти. У цьому контексті модель загроз може мати два варіанти реалізації:

- самостійний проект інформаційної безпеки інформаційної системи;

- інтегрований компонент безпеки в проекті інформаційної системи.

Для побудови моделі загроз інформаційній безпеці інформаційної системи використовуються методики та каталоги загроз з офіційного стандарту ГОСТ Р 51275-2006, методичних документів ФСТЕК, Стандартів Банку Росії. Сам процес побудови моделі є послідовність наступних операцій:

- виявлення джерел загроз інформаційної безпеки;

- визначення критично важливих активів;

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

Згідно «Методикою визначення загроз безпеки інформації в інформаційних системах» (ФСТЕК), модель загроз безпеки інформації повинна містити такі основні розділи:

- опис інформаційної системи і особливостей її функціонування.

- можливості порушників (модель порушника).

- актуальні загрози безпеці інформації.

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

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

Дане питання порушувалося в науковій літературі і розглядав описані вище можливості моделювання: розробка самостійних моделей інформаційної безпеки [2,3] і вбудовуються в проект ІС функції системи безпеки [4,5] . При цьому методологія розробки об'єктно-орієнтованих моделей загроз не представлена ​​ні в одному джерелі.

Об'єктно-орієнтована модель загроз інформаційній безпеці

В рамках цього дослідження створювалася об'єктно-орієнтована модель загроз для інформаційної системи, яка має такі характеристики:

1. Система розподілена, функціонує на базі сервера додатків, клієнтська частина системи реалізована у вигляді веб-додатки.

2. Доступ до системи мають тільки співробітники організації.

3. Система повинна безперебійно функціонувати протягом всього робочого дня.

4. Вкрай небажана витік інформації, що обробляється в інформаційній системі.

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

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

- відповідність інформаційної системи заданим стандартам;

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

- використання засобів антивірусного захисту;

- межсетевое екранування;

- виконання процедур резервного копіювання та інші.

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

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

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

Малюнок 1. Діаграма варіантів використання. Концептуальна модель загроз.

Представлена ​​на малюнку 1 діаграма описує варіанти реалізації загроз по всіх активів інформаційної системи і за всіма джерелами загроз. У цьому сенсі дана модель є концептуальною моделлю загроз.

Способи реалізації описаних за допомогою прецедентів загроз - це погляд на окремо взяту загрозу. Об'єктна методологія UML дозволяє проводити декомпозицію об'єктів, представлених на діаграмах. У нашому випадку способи реалізації - це теж загрози, що розширюють вихідні. Відповідно, вони повинні бути пов'язані відношенням спадкування в діаграмах декомпозиції (Use Case Composite Diagram). Приклади опису способів реалізації загроз «розголошення інформації» та «несанкціонований доступ» приведена на рисунках 2 і 3. Окремо слід відзначити, що всі діаграми в Enterprise Architect є інтерактивними, тому для перегляду способів реалізації загрози можна перейти на діаграму декомпозиції з діаграми варіантів використання.

Малюнок 2. Способи реалізації загрози «Розголошення інформації»

Малюнок 3. Способи реалізації загрози «Несанкціонований доступ»

Для перегляду загроз, спрямованих на кожен окремий актив, доцільно використовувати діаграму взаємодії (Communication Diagram). Отримана діаграма описує зв'язки між об'єктами системи. На малюнку 4 такими об'єктами є користувач, порушник і цілісність інформації, які пов'язані прецедентами. Відзначимо, що в Enterprise Architect об'єкти, перенесені з інших діаграм, «пам'ятають» свої зв'язки, що виявляється зручним механізмом при проектуванні системи інформаційної безпеки.

Малюнок 4. Діаграма взаємодії. Загрози активу «Цілісність системи»

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

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

- за способами реалізації загроз - за допомогою дочірньої діаграми варіантів використання.

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

Моделювання сценаріїв загроз

Опису сценаріїв реалізації загроз реалізовані за допомогою діаграм діяльності (Activity Diagram), але слід зазначити, що це можливо і за допомогою розширення мови UML - нотації BPNM, також представленої в Enterprise Architect [7] . Вказану нотацію слід застосовувати для складних сценаріїв, які вимагають більш детального опису бізнес-процесів і використання спеціальних композиційних і структурних блоків.

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

- сценарій реалізації загроз;

- сценарій захисту від загрози.

Сценарій реалізації загрози можна розглядати як поточний стан інформаційної безпеки. У термінах моделювання бізнес-процесів така ситуація описується терміном As - Is (як є). Приклад реалізації загрози «Несанкціонована зміна даних» наведено на малюнку 5. Такий сценарій описує ситуацію, коли користувач системи, який здійснив вхід в систему, може виконати будь-які дії зі зміни даних, надані йому інтерфейсом системи. Таким чином, з боку системи відсутній контроль доступності операції для користувача, можливість її виконання відповідно до посадових обов'язків, рівнем доступу і т.д.

Малюнок 5. Діаграма діяльності.

Сценарій As-Is реалізації загрози «Несанкціонована зміна даних»

Для вдосконалення системи забезпечення інформаційної безпеки для загрози «Несанкціонована зміна даних» описана модель сценарію To - Be (як повинно бути), представлена на малюнку 6.

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

1) перевірка прав на виконання операції, заснована на політиці привілеїв;

2) перевірка критичності змін, що використовує класифікатор операцій;

3) логирование (реєстрація в таблицях логів) операцій.

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

- використання політики привілейованого доступу;

- наявність класифікатора критичності операцій;

- наявність таблиць логів по здійснюваним операціям;

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

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

Малюнок 6. Діаграма діяльності.

Сценарій To-Be реалізації загрози «Несанкціонована зміна даних»

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

висновок

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

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

Бібліографія