Метричні показники як засіб визначення відповідності інформаційної системи вимогам

Работа из раздела: «Производство и технологии»

/

Содержание

• Вступ
• 1. Класифікація метричних показників
• 1.1 Цілі безпеки
• 1.1.2 Вимоги безпеки
• 1.1.2 Кращі практики
• 1.1.3 Нормативи безпеки
• 1.1.4 Відповідне зусилля
• 1.1.5 Моделі зрілості
• 1.2 Методи вимірювання
• 1.2.1 Пряме тестування
• 1.2.2 Виміри
• 1.2.3 Оцінка
• 1.2.4 Акредитація
• 1.2.5 Тренінги, освіта та рівень компетентності
• 1.2.6 Огляд ефективності системи
• 1.3 Метричні показники безпеки технічної інформації
• 1.4 Метричні показники безпеки організаційної інформації
• 1.5 Метричні показники безпеки експлуатаційної інформації
• 1.6 “Мозкові штурми”
• 2. Проблеми при застосуванні метричних показників в інформаційній безпеці
• 2.1 Гнучкість концепції метричних показників в IS
• 2.2 Важкість в отриманні кількісних результатів для об'єктів IS
• 2.3 Важкість вимірювання експлуатаційних метричних показників
• 2.4 Природа проблем інформаційної безпеки
• 3. Аналіз існуючих систем метричних показників
• 3.1 Модель за стандартом NIST SP800-55
• 3.2 Модель Еркана Карамана
• 4. Побудова підходу реалізації впровадження метричних показників
• 5. Огляд підходу впровадження метричних показників безпеки
• 6. Основа впровадження метричних показників безпеки ІТ
• 7. Види метричних показників
• 8. Реалізація впровадження метричних показників безпеки
• 8.1 Фактори успіху
• 8.1.1 Організаційний розгляд
• 8.1.2 Керованість
• 8.1.3 Підприємства управління даними
• 8.2 Технологія розробки та застосування метричних показників
• 8.2.1 Процес розробки метричних показників
• 8.2.2 Визначення інтересів співвласника
• 8.2.3 Визначення цілей
• 8.2.4 Перегляд процедур, керівництв та політик безпеки ІТ
• 8.2.5 Розробка та вибір метричних показників
• 8.2.6 Встановлення цілей ефективності
• 8.3 Реалізація впровадження метричних показників в організації
• 8.3.1 Підготовка для збору даних
• 8.3.2 Збір даних та аналіз результатів
• 8.3.3 Ідентифікація коригуючих дій
• 8.3.4 Розвиток необхідного бюджету та отримання ресурсів
• 8.3.5 Прийняття коригуючих дій
• Висновок
• Перелік посилань

Вступ

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

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

Метричні показники надають виміряну інформацію (відсотки, приблизні значення, числа) для порівняння, використовуючи формули для аналізу. Результатом є дані про ефективність, які базуються на цілях ефективності безпеки ІТ.

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

В дипломному проекті приділяється увага двом системам метричних показників: за стандартом NIST SP 800-55 та система Еркана Карамана. В першій частині дипломного проекту надається огляд існуючих систем метричних показників. Проаналізувавши модель Пайне, можна зробити висновки, що стандарт NIST SP800-55 закріпив його модель та надав їй повний опис. Модель Еркана Карамана є більш повною та містить додатковий тип метричних показників, який замість виміряних даних повертає відповідь так/ні та використовується для перевірки існування політик та документів. Звичайно найкращих результатів можна досягти лише поєднавши існуючі системи, які будуть доповнювати одна іншу. Для обох систем будуть добудовані таксономії та повні таблиці метричних показників з формулами для обчислення та нормативами, до яких повинні наближатись значення метричних показників.

1. Класифікація метричних показників

Виміри надають одиничний погляд на специфічні виміряні параметрі та представлені числами, вагою та бінарними значеннями. З іншого боку, метричні показники отримуються, беручи виміри у часі та порівнюючи один чи декілька вимірів з попередньо визначеними нормативами, таким чином надаючи значення для інтерпретації зібраних даних. Часто існує “значне протиріччя” коли термін метричний показник використовується всередині IS. Тому припускається, що вираз IS* використовується як синонім для наступних термінів: метричний показник, вимір, рахунок, оцінка, розряд чи результати оцінювання, з визначенням: “IS - це значення, обране з частково упорядкованого масиву деяким процесом оцінки, який представляє IS - залежну якість деякого об`єкту підприємства. IS надає чи допомагає створити опис, прогнозування чи порівняння, з деяким рівнем конфіденційності”. IS* також використовується як синонім для множинних властивостей, де воно розглядалось згідно з описом в більш широкому контексті ніж просто слово “метричний показник” [3].

Для того щоб зрозуміти які різні IS* можна побудувати необхідно подивитися на визначення та конструкції, запропоновані в літературі для моделі метричних показників разом з різними класифікаціями та категоріями IS*. Згідно з Катцке (2001), модель метричних показників складається з 3 компонентів:

1. Об`єкт, який вимірюється;

2. Цілі безпеки;

3. Метод виміру.

Модель показана на рисунку 1.1.

Рисунок 1.1 - Модель метричних показників безпеки згідно з Катцке (2001)

1.1 Цілі безпеки

Використовуючи класифікацію Катцке (2001), цілі безпеки можуть бути розділені наступним чином:

· вимоги безпеки (специфікації, стандарти, цілі заходів та Загальні Критерії Профілю Захисту);

· кращі практики;

· нормативи безпеки;

· відповідна аудиторія;

· моделі зрілості (SSE-CMM, IA-CMM).

Таблиця 1.1 - Цілі безпеки

Цілі безпеки	Метод застосування	Очікуваний результат	Приклад
Вимоги безпеки	Дії з безпеки порівнюються з вимогами	Припущення для покращення	Стандарти, Загальні Критерії Профілю Захисту
Кращі практики	Дані чи визначені безпечні процедури для певної діяльності	Інструкції для безпечних процедур	Інструкції для вірусів, e-mail.
Нормативи безпеки	Оцінка та інспекція безпеки організації	Мінімальний набір необхідних дій з безпеки	Необхідні заходи безпеки
Відповідна аудиторія	Менеджмент безпеки, що базується на досвіді	Рівень безпеки організації чи бізнес партнера	Оцінка заходів безпеки
Моделі зрілості	Практики безпеки інспектовані та порівняні з моделлю	Явний рівень безпеки	SSE-CMM

1.1.2 Вимоги безпеки

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

Застосування якісних моделей залежить від характеру організації. Часто використовуваними критеріями є серії ISO 9000 (The ISO Survey of ISO 9000 та Сертифікати ISO 14001, 2002) Загальний Менеджмент Якості (TQM,Gummer & McCallion, 1995) та критерії Малколма Балдриджа (The Baldridge Criteria for Performance Excellence, 2004). Загальний менеджмент безпеки (TSM, Мієтінен, 2001) та Система менеджменту загальної безпеки та оточення (TSEM, Мієтінен, 2001) є критеріями якості, які спеціалізуються по проблемам менеджменту безпеки. Однак, Мієтінен (2001) вважав “загальні' стандарти набагато більш ефективними, коли вони використовуються для покращення якості менеджменту безпеки в організації.

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

1. Керівництво;

2. Стратегічне планування;

3. Фокусування на покупці;

4. Виміри, аналіз та оцінка знань;

5. фокусування на людських ресурсах;

6. менеджмент процесу;

7. результати дій.

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

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

Рисунок 1.4 ілюструє процес GQM:

· концептуальній рівень (GOAL): для об`єкту визначається ціль;

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

· Рівень вимірів (METRIС): набір даних, асоційованих з кожним питанням, для відповіді на нього у кількісному змісті.

метричний показник стандарт норматив

Рисунок 1.4 - Процес GQM (Базілі та ін., 1994)

Загальні критерії (СС, 1999) є “каталогом чи словником вимог' для побудування базису для оцінки властивостей безпеки продуктів ИТ та систем. Вони включають Профілі захисту (РР) та Цілі Безпеки (ST). Їх концепція відрізняється інших, тому що РР є незалежно - використовуваним та ST є специфічно - використовуваним. Тому, ST можуть вважатись як цілі безпеки для різної аудиторії (покупці продукту, конструкторів). СС представляє просту концепцію, що вже була раніше описана під назвою “цілі безпеки”, яка є головним елементом РР та ST. В СС цілі безпеки описані як “відображати значення індикатору вторгнень та адресувати всі ідентифіковані організаційні політики безпеки та припущення”.

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

1. Оцінка критеріїв, що належать до адміністративних вимірів безпеки, які прямо не відносяться до вимірів безпеки ІТ;

2. Оцінка технічних фізичних аспектів безпеки ІТ;

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

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

На рисунку 1.5 зображені головні елементи, які формують контекст оцінок.

Рисунок 1.5 - Контекст оцінки Загальних Критеріїв (Common Criteria, 1999)

1.1.2 Кращі практики

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

1.1.3 Нормативи безпеки

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

1.1.4 Відповідне зусилля

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

1.1.5 Моделі зрілості

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

Однією з найбільш часто використовуваною моделлю зрілості є SSE-CMM. Ціллю SSE-CMM є діяти як засіб для визначення ефективності організації в впровадженні продуктів безпеки, служб чи операцій. Модель визначає дії для покращення безпеки в організації, які називаються Кращі практики (ВР); вони є часткою визначеної Зони Процесу (РА). SSE-CMM визначає різні рівні зрілості від 1 до 5, де 5 - найбільше значення. Кожен рівень може бути досягнутий виконанням необхідних Універсальних Практик (GP) та визначених ВР в відповідних РА. Процес SSE-CMM проілюстрований на рисунку 1.6. Метод для оцінки процесу ефективності процесу системи безпеки в організації та процес зрілості, визначений в SSE-CMM показаний в SSE-CMM Методі Оцінки (SSAM, 1999). Система метричних показників складається з Процесу Метричних Показників та Метричних Показників Безпеки. Останнє визначено Кормосом та ін. (1999): “атрибут виміряння результатів моделі зрілості SSE-CMM процес технічної безпеки, який може служити як доказом його ефективності”. Метричні показники безпеки можуть бути ціллю, та якісними чи кількісним. Тому використання одного вимагає використання іншого.

Рисунок 1.6 - Безперервна Модель Зрілості Ефективності

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

1.2 Методи вимірювання

Методи вимірювання за Каткце (2001) включають пряме тестування (функціональне, тестування на проникність), виміри, оцінка (оцінка ризиків та уразливостей), акредитація, тренінги, освіта та рівень компетентності так само, як і огляд рівню результативності системи, наприклад знаходження вторгнень. Методи вимірювання порівняні в таблиці 1.3.

Таблиця 1.2 - Методи вимірювання

Метод вимірювання	Як застосовується	Очікувані результати	Приклад
Пряме тестування	Стан системи оцінюється тестуванням її якостей	Експлуатаційний стан системи	Тестування на проникність
Виміри	Виміри безпеки порівнюються з критеріями	Отримання нормативу, припущення для покращення	Аудит
Оцінка	Виміри безпеки оцінюються	Пріоритетні справи, припущення для покращення	Техніки аналізу ризиків
Акредитація	Виміри безпеки оцінюються	Можливий сертифікат, Виміри безпеки оцінюються	ISO 9000 Series Certificate
Тренінги, освіта та рівень компетентності	Знання персоналу та організації оцінюються та збільшуються	Можливій сертифікат, покращення в індивідуальній експертизі	Конференції, тестування навичок, зустрічі
Огляд рівню результативності системи	Система аналізується технічними засобами	Стан якості деяких технічних аспектів в визначений момент чи період	Визначення вторгнень, виміри завантаження мережі

1.2.1 Пряме тестування

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

Тестування на проникність є діючим шляхом для виміряння інцидентів безпеки. Як приклад універсальних можливостей для застосування методу тестування, заходи тестування Коденомікона тестують інтерфейс протоколу для дефектів IS та стійкість недоліків. Заходи тестування базуються на роботі, яка виконується PROTOS - проектом (Каксонен, 2001). Ці види заходів можуть бути використані, наприклад, в:

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

· Тестування прийняття;

· Оцінка продукту;

· Регресійне тестування.

1.2.2 Виміри

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

· Ціль вимірів (ТОЕ);

· Загрози, які необхідно рахувати;

· Цілі безпеки;

· Функціональність безпеки, яку необхідно застосувати;

· Рівень гарантії, який повинен досягти продукт;

· Необхідна мінімальна сила функцій/механізмів безпеки;

· Критерії, за якими проводяться виміри.

Методи вимірів можуть бути розділені на:

· Аналіз свідоцтва, яке надає розробник;

· Відвідування сайтів;

· Тестування (відповідно тестам розробника, додатково тести на відповідність та тести на проникність);

· Незалежний аналіз уразливостей.

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

1.2.3 Оцінка

Оцінка в загальному випадку відноситься до оцінки ризиків чи уразливостей. Аналіз уразливостей, що проводиться разом із тестуванням на проникність, здається на сьогоднішній день найбільш загальним методом вимірянь. Оцінка ризиків зазвичай вимагається перед тим, як можуть бути застосовані функції IS для того, щоб визначити пріоритети оцінкам організації, її загрозам, та визначити які факти необхідні для захисту. Головними кроками в оцінці ризиків є визначення ризику, аналіз та контроль ризику. Останній крок виключає оцінки ризиків. Одним з підходів для оцінки якості різних методів оцінки та заходів, що використовуються в робочих місцях, є метод, представлений Мікконеном та ін. (2003). Вони представили технології, які можуть бути використані разом чи окрема для оцінки застосовності певного методу оцінки ризиків. Існують переліки питань, інтерв`ю, SW - тести та групи розробників, які складаються з користувачів.

1.2.4 Акредитація

Існує декілька комерційних та урядових IS акредитацій них сервісів та доступні проекти. Як приклад критеріїв акредитації, проект NIST FISMA (Росс та ін. 2004), метою якого є:

· співпраця в розвитку стандартів та керівництв для підтримки Федерального Інформаційного сайту;

· Безпека катигорування інформації та інформаційних систем згідно з Актом Менеджменту Безпеки;

· Вибір відповідних заходів безпеки для інформаційних систем;

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

· Експлуатаційна авторизація для процесів (акредитація безпеки) інформаційних систем.

1.2.5 Тренінги, освіта та рівень компетентності

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

1.2.6 Огляд ефективності системи

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

Метою Системи Визначення Вторгнень (IDS) є визначення вторгнень в систему інформаційних технологій, це визначається завдяки моніторингу, та бути в змозі відповісти на вторгнення (Бабаоглу, 2003, Інтернаціональна Корпорація Наукових програмних засобів, 2002). ІТ система може змінюватись від комп`ютерної системи до комп`ютерної мережі. IDS складається з центру, сканерів та аналізаторів, з опціями, наприклад, баланс завантаженості, та опції управління. Сенсори та сканери збирають інформацію, яка відноситься до дій в інформаційній системі та уразливостей, та вони передають зібрані дані до аналізаторів. Аналізатори виконують аналіз вторгнення та роблять звіт о зібраній інформації. (Бабаоглу, 2003, Інтернаціональна Корпорація Наукових програмних засобів, 2002). Існує 2 концепції, які близько відносяться до виміряння техніки IDS: помилка позитивна та помилка негативна. Помилка позитивна - це ситуація, коли трапляється щось ненормальне, але це не вторгнення, помилка негативна - коли вторгнення уже здійснилось, але IDS не перехопило його. Таким чином, метою IDS є знаходження вторгнень та, в додаток, мінімізувати помилки негативні та позитивні для отримання більш точних результатів. (Бабаоглу, 2003.)

IDS можуть бути характеризовані джерелом даних (тобто, звідки отримуються дані для аудиту), чи моделями, які представляють вторгнення. Таким чином, IDS можуть мати різні види механізмів визначення вторгнень. Характеристика за джерелом даних розділяє IDS на host-based, multihost-based та network-based. Різні моделі вторгнень є моделлю визначення аномальних дій та модель визначення хибних дій. Коли використовується модель визначення аномальних дій, IDS визначає вторгнення, розглядаючи діяльність, яка відрізняється від нормальної дії користувачів чи системи, при використанні моделі визначення хибних дій, IDS визначає вторгнення, шукаючи діяльність відповідає відомим технікам вторгнень чи фолу автомат системи. (Бабаоглу, 2003.)

Линдквист та інші (1998) категоріювали керівництво по безпеці згідно з аудиторією, для якої вони запропонували найбільші переваги. Вони стверджували, що для продавців та виготовлювачів, функціональність системи та процес розробки описані в стандартах [TCSEC (Trusted Security System Evaluation Criteria, 1985), ITSEC (Information Technolagy Security Evaluation Criteria, 1991) та СС], які визначають критерії, за якими може бути проведене оцінювання безпеки. За їхньою думкою, нормативні документи з безпеки були створені для того, щоб виробники могли визначити набір вимог для ознак безпеки, які повинні містити інформаційні технології. Політики безпеки є корисними для менеджерів, операторів та користувачів систем інформаційних технологій, тому що вони повинні дотримуватись певних правил для мінімізації потенційних загроз. В цьому контексті стандарти означають керівництва та кодекси практик.

Джонсон (2003) зробив сортування методів вимірювання на наступні технології:

1. Аналіз ризику - оцінка вірогідності специфічних вторгнень та їх наслідків та вартостей. Ці вартості можна розглядати як відповідні вартості на захист;

2. Сертифікація - класифікація системи на класи, що базуються на змодельованих характеристиках та механізмах безпеки, “чим ліпше “моделювання” тим більш захищена система”;

3. Вимірювання процесу вторгнення - статистичне вимірювання системи, яке базується на зусиллі зробити вторгнення. “Чим важче зробити вторгнення тим більш захищена система' (Джонсон, 2003).

Модель метричних показників може бути розглянута як абстракція в визначенні Хеннінга (2001). Воно розділяє IS* на 4 категорії:

· Технічна;

· Організаційна;

· Експлуатаційна IS*;

· “Мозковий штурм”, який відноситься до синтезованої великої картини метричних показників.

Хеннінг зробив акцент на тому, що деякі точки зору були взяті з цієї класифікації, тобто індивідуальні IS* (що описують індивідуальну експертизу) та IS* оточення (що описують аспекти організаційного та експлуатаційного оточення, що відносяться до безпеки, в загальному випадку вторгнення). Рисунок 1.2 пояснює цю абстракцію та прив`язує IS* до процесу. Модель розглядалась з перспективи “типу об`єкту”, що означає IS*, “ціль”, іншими словами, як IS* використовується, та “можлива аудиторія”, що означає людей, які в основному використовують інформацію, збільшену через використання IS*. Однак, таблиця 1.3 представляє головні вади кожної категорії IS*, які доповнюються індивідуальними IS* та IS* оточення для запропонування повного висновку про зону впливу IS*.

Рисунок 1.7 - Характеристика IS* (Хеннінг, 2001)

Згідно з Хеннінгом (2001), ціль для якої розробляється IS*, може бути розділена на підтримку рішення та мандатний звіт статусу IS* чи цілі. Згідно з рисунком 1.2, IS* може бути використана для опису, порівняння чи прогнозування поведінки та атрибутів системи чи її компонентів.

Хеммінг та інші (2003) запропонував іншу класифікацію в його Керівництві Метричних Показників Безпеки:

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

· Метричні показники ефективність/результативності для виміру продуктивності результатів служб безпеки;

· Метричні показники збитку для виміру збитку діяльності чи завдань подій безпеки.

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

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

1.3 Метричні показники безпеки технічної інформації

Технічні IS* можуть бути використані для опису та, отже порівняння, технічних об`єктів. Це включає алгоритми, специфікації, архітектури та альтернативні моделі, продукти, та застосовані систем на різних стадіях життєвого циклу системи. Метричні показники вторгнення є типовим прикладом технічних IS* для яких може бути визначена прийнятна кількість досліджень. Ці дослідження деталізують системи виявлення вторгнень (IDS), які, згідно з їх технічною природою, можуть бути змодельовані та параметризовані для подальшого розвитку. Важливою річчю, згідно з Хеннингом, є те, що технічні IS* в основному припускаються для керування об`єктами так, щоб вони могли бути порівняні.

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

Хеммінг також зазначив, що дослідження повинні фокусуватися на керуванні особливо абстрактними об`єктами при створенні технічних IS*, таких як криптографічні алгоритми чи протокол сертифікації, ніж застосованими об`єктами. Через це цикл розвитку застосування продукту швидкий. Тому, коли відповідні метричні показники були створені для продукту, він міг бути замінений на більш нову версію, для якої такі ж самі IS* не можуть бути прийняті. Іншою альтернативою є фокусування на еволюційний життєвий цикл всередині розробки IS* (Хеннінг, 2001).

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

Однак, коли дві захищені системи поєднуються, результат не обов`язково буде явною комбінацією двох. Можлива неочікувана поведінка. Через це, прогнозування, зроблене для такої поведінки системи, не може бути завжди реалістичним. Існує необхідність розробляти кращі моделі допустимої поведінки системи, обмеженої для характеристик поведінки технічних об`єктів. Іншою точною зору є те, що для створення реалістичних прогнозувань технічні IS* будуть вимагати основну модель IA (Оцінка Інформації), в якій значення, асоційовані з технічними об`єктами, є значними факторами в безпеці системи та також в яких майбутнє нагадує минуле (Хеннінг, 2001).

1.4 Метричні показники безпеки організаційної інформації

Організаційні IS* використовуються для опису та слідкування за ефективністю організаційних програм та процесів, таких як відсоток персоналу, який проходив тренінги з безпеки, та відсоток акредитованих систем. Таким чином, організаційні IS* представляють як кількісні, так і якісні метричні показники в моделі Миеттинена (1999). Одним прикладом цього є навчання Каяви та Лейко (1994) про штат інформаційної безпеки в організаціях. Вони обговорюють підхід для виміру кількості штату IS та його застосування в Фінляндії; підхід базується на дослідженнях, що проводились в USA Вудом (1989).

Метою комерційних організацій в основному є використання метричних показників для визначення ефективності організаційних програм та процесів, та також кількість на якість дій по безпеці. Керівництво в основному вимарює як гарно організація зустрічає необхідні мандати (метричні показники звітів). Метричні показники IS для таких організацій часто використовуються як захід для підтримки прийняття рішень. Різниця між цілями цих секторів може бути результатом різних потрібностей для IS* (Хеннінг, 2001).

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

1.5 Метричні показники безпеки експлуатаційної інформації

Хеннінг (2001) звертається до використання експлуатаційних IS* для опису та управління ризиками експлуатаційного середовища, включаючи системи та практики. Експлуатаційні IS* - відповідно метричні показники для оцінки в основному ризиків, в чому їм допомагають метричні показники, що відносяться до значення активів, серйозності збитку, загроз, уразливостей та ефективності вимірів безпеки. Отже експлуатаційний IS* - в основному якісний метричний показник (оцінка ризику), але може також надати кількісні значення в моделі Муетінена (1999).

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

1.6 “Мозкові штурми”

“Мозковий штурм”, згідно з Хеннінгом (2001), звертається до концепцій синтезу, перехресних результатів та великої картини визначення. Підхід системної інженерії був схвалений для об`єднання вимірів, тому що цей процес може охопити повний життєвий цикл системи, означаючи що технічні, експлуатаційні та організаційні техніки та IS* можуть бути інтегровані в цю структуру найбільш ефективно. “Мозковий штурм' найчастіше надає якісні метричні показники в моделі Міетінена (1999), яка має перевагу: точність збору кількісних метричних показників.

Таблиця 1.3 - Класифікація IS* згідно з Хеннінгом (2001) з додатковими якостями

	Тех. IS*	Орг. IS*	Експл. IS*	МШ. IS*	Інд. IS*	IS* Сер.
Описання	Технічні об`єкти	Ефективність програм та процесів організації	Ризики експлуатаційного середовища, включаючи системи та операційні практики	Синтез, перехресне рішення, велика картина визначення	Індивідуальна експертиза	Аспекти оточення організації чи операції, що залежать від безпеки
Приклад	Логи	Відсоток акредитованих систем	Значення активу	Комбінація 3 інших IS* в єдину систему	Розуміння чи рівень освіти працівників	Загрози, спричинені функціонуванням в середовищі
Ознаки	Можуть містити багато незвичайних даних, часто необхідно фільтрувати та раціоналізувати	Вимагає огляду всієї організації, не обов`язково точно застовованого в інших організаціях	Вимагає щоб середовище організації та його ефекти були зрозумілими, це часто може бути просто оцінене	Вимагає огляд всього життєвого циклу організації	Важко вирівняти шкалу організації	Можливо важко змоделювати функції середовища, може містити неочікувані фактори та комбінації

2. Проблеми при застосуванні метричних показників в інформаційній безпеці

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

Рисунок 2.1 - Проблеми, що відносяться до метричних показників IS

2.1 Гнучкість концепції метричних показників в IS

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

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

2.2 Важкість в отриманні кількісних результатів для об'єктів IS

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

Хеннінг (2001) також класифікує IS* в чисельні та не чисельні форми. Замість розділення Міетинена (1999) на якісні і кількісні значення, в її перспективних, якісних атрибутах, таких як “червоний/жовтий/зелений” - типи класифікації, все ще необхідні кількісні виміри для результатів, наприклад, при “зелений ” застосовується до нульових уразливостей. Якщо б існували загальні визначення для IS*, було б набагато легше розвинути загальні методи та зібрати якісні та кількісні результати.

2.3 Важкість вимірювання експлуатаційних метричних показників

Джонсон (1998) показав, що існуючий шлях виміру безпеки використовує класи та ранги Помаранчевої книги (TCSEC, 1985) чи інші критерії оцінки. Схожа проблема обговорювалась раніше, відносно технічних IS*. Поведінка система, особливо при комбінації двох систем в одну функціональну систему, повинна бути взята до уваги. Більш того, метричні показники повинні розвиватися так само, як і процеси навколо них, отже метричні показники будуть постійно виміряти якості в реальному часі.

Література підкреслює кількісний підхід до експлуатаційних IS*: типово рахується кількість уразливостей, вторгнень та вірусних спалахів. Цей підхід не допомагає в оцінці експлуатаційної готовності та не завжди допомагає менеджерам в розумінні потенційних порушень безпеки в системі чи процесі. Вимірі, отримані завдяки заходам оцінки безпеки системи, повинні представити якомога точніший стан безпеки системи в експлуатації. (Хеннінг, 2001).

Можливо з`явиться необхідність в конструктивному, систематизованому розвитку використаних IS*, що базуються архівних даних. Оточення та інтерфейс системи повинні також бути взяті до уваги. Згідно з Хеннінгом (2001), властивості IS експлуатаційного оточення часто не можуть бути виміряні напряму. Непрямі індикатори можуть бути корисними, але вони повинні бути визначені на використані дуже обережно.

2.4 Природа проблем інформаційної безпеки

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

Концепція метричних показників є комплексною. В організаціях, де управління не знає о проблемах IS, може бути дуже важко умовити їх інвестувати ресурси в кращу безпеку. Чим кращий рівень безпеки, тим непомітніші стають проблеми безпеки в житті організації. Але інвестиції в безпеку не показують видимі результати в повсякденному житті, і через це буває важко отримати інвестиції в безпеку, якщо “нічого не трапляється”.

Часто процес виміряння може вимагати знання зовнішньої оточення, наприклад, сесії аудиту персоналу. Це може суттєво збільшити ризик для організації, порівняно з вигодами, отриманими використанням ефективних метричних показників. Людський фактор враховується для кожного IS та відносна вигода отримання доступу до цінної інформації організації, її слабкості та переваги можуть стати дуже привабливими для деяких людей. Інформація, що потрапила до невірних рук, може навіть бути спустошена для заслуговуючих довіри в компанії (Каява та Лейко, 1994). Тому, багато організацій повинні запитати в себе: “чи можемо ми дозволити собі хороший рівень безпеки? ”

3. Аналіз існуючих систем метричних показників

3.1 Модель за стандартом NIST SP800-55

NIST SP800-55 визначає 16 типів метричних показників, які можна розділити на 3 галузі: адміністративні, менеджменту, технічні (рисунок 3.1). Для опису метричних показників в стандарті NIST SP800-55 використовується Детальна Форма Метричних Показників (pисунок 3.1). Метричні показники, які відносяться до групи адміністративних оцінюють безпеку персоналу, обладнання, ефективність системи реагування на інциденти. В організації обов`язково повинно бути розділення обов`язків та прав користувачів. Якщо метричний показник має низьке значення, що свідчить про загрозу зовнішніх дій, бо декілька користувачів мають право виконувати одні й ті самі дії. Іншим прикладом може бути перевірка наявності плану на випадок непередбачених подій. Якщо метричний показник показує низький відсоток це свідчить про відсутність необхідної політики в агенції, яка б вимагала наявність такого плану, чи помилки при впровадженні політики [4].

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

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

Таблиця 3.1 - Детальна Форма Метричних Показників.

Ціль виконання	Визначити бажані цілі застосування одного чи декількох об`єктів/методів заходів безпеки, які оцінюються метричними показниками. При застосуванні NIST SP800-26 цей пункт буде перераховувати критичні елементи
Методи Виконання	Визначає дії, які необхідно виконати для досягнення цілі При застосуванні NIST SP800-26 цей пункт буде перераховувати один чи декілька питань. Багато методів виконання можуть відноситись до однієї цілі виконання.
Метричні показники	Визначає метричні показники, описуючи кількісну оцінку, що надається цими метричними показниками. Використовує числове формулювання, що починається зі слів “процент”, “кількість”, “частота”, “середня кількість' та інших схожих термінів.
Ціль вимірів	Визначає загальну функціональність, що надається збором метричних показників.
Обґрунтованість застосування	Доведення існування заходів безпеки. Доведення застосування використовується для обчислення метричних показників, як непрямих показників того, що діяльність виконана, так як причинні фактори, які можуть указати на причину незадовільного результату.
Частота	Пропонує часові періоди для збору даних, що використовуються для оцінки змін в часі. Часові періоди, що пропонуються, базуються на схожих змінах в використанні заходів.
Формула	Описує обчислення, щоб отримати результати у вигляді числового виразу. Інформація збирається завдяки використанню служб, як вхідних даних для формули для обчислення метричних показників.
Джерело даних	Перечислює розміщення даних для обчислення метричних показників. Включає бази даних, організації, або специфічні посади всередині організації, які можуть надати необхідну інформацію.
Індикатори	Надають інформацію про значення метричних показників та їх напрямок дії. Пропонують можливі причини дій, ідентифікованих в ході оцінці та показують на можливе рішення для виправлення можливих недоліків. Визначають ціль метричних показників та який напрямок дії буде вважатися позитивним в відношенні до цілі виконання.

Рисунок 3.1 - Таксономія метричних показників за стандартом NIST SP800-55

Таблиця 3.1

Назва	Вимірювання	Формула	Норматив
Керування ризиками	К1 - кількість систем, які виконують оцінку та документування ризиків на протязі попередніх 12 місяців. К2 - кількість систем, які виконують оцінку та документування ризиків на протязі попередніх 2 років. К3 - кількість систем, які виконують оцінку та документування ризиків на протязі попередніх 3 років. Кз - кількість систем в агенції	*100	100%
	Кв - кількість наслідків ризиків, які було визнано органами керування Кнев - кількість наслідків ризиків, які не було визнано органами керування Кзаг_насл - кількість наслідків ризиків, які було знайдено для всіх зібраних оцінок ризиків за звітний період	*100	100%
	Kт - кількість систем, для якої тестувалися заходи безпеки за минулий рік Кз - кількість систем в агенції	*100
Заходи безпеки	tс - середній час К30 - кількість слабостей, які було знайдено та закрито за звітний період за 30 днів К60 - кількість слабостей, які було знайдено та закрито за звітний період за 60 днів К90 - кількість слабостей, які було знайдено та закрито за звітний період за 90 днів К180 - кількість слабостей, які було знайдено та закрито за звітний період за 180 днів К12 - кількість слабостей, які було знайдено та закрито за звітний період за 12 місяців
Життєвий цикл розвитку системи	Кsdlc - кількість систем, які пройшли чи знаходяться в SDLC Кз - кількість систем в організації	*100
	Кзб_змін - кількість систем зі змінами в заходах безпеки, які були повторно сертифіковані після реалізації Кз - кількість систем, що мали зміни в заходах безпеки після розвитку	*100
Авторизація процесу (Сертифікація та акредитація)	КC&A - кількість систем, які отримали повну C&A Кpеєстр - кількість систем, які було зареєстровано	*100	100%
	КIATO - кількість систем, які не є сертифікованими, працюють з IATO Кз - кількість систем в агенції	*100	0%
План безпеки системи	Кпланів - кількість планів безпеки системи, які було схвалено управлінням Кз - кількість систем в агенції	*100
	К6 - скільки планів безпеки системи було переглянуто та оновлено за звітний період за минулі 6 місяців К12 - скільки планів безпеки системи було переглянуто та оновлено за звітний період за минулі 6-12 місяців К1-2 - скільки планів безпеки системи було переглянуто та оновлено за звітний період за минулі 1-2 роки Кзаверш_планів - загальна кількість завершених планів безпеки системи	*100
Безпека персоналу	Кперев - кількість систем, перевірених для введення вимоги Кформ - кількість систем, які формально погодились на вимогу	*100
	Кспец - кількість користувачів зі спеціальним доступом, в яких закінчився доступ Кзаг__олу - загальна кількість користувачів зі спеціальним доступом	*100	100%
Фізична безпека	Ксхов - кількість сховищ, які фіксують перевірки та депозити Кзаг_медіа - загальну кількість медіа сховищ	*100	100%
	Ктв - загальна кількість пристроїв для передачі даних з обмеженнями фізичного доступу на всіх точках входу Кзаг_теле - загальна кількість телекомунікаційних пристроїв, які містять лінії передачі даних	*100	100%
	Кл_шифр - кількість _олу авто з можливістю шифрування Кл_заг - загальна кількість лап топів	*100	100%
Продукція, заходи вводу/виводу	Квир - кількість вирішених проблем, пов`язаних з безпекою Кфікс - кількість зафіксованих проблем, пов`язаних з безпекою	*100
	Кочищ - кількість очищених медіа Кзнищ - кількість медіа засобів, затверджених для знищення чи багаторазового використання	*100	100%
Планування на випадок непередбачених обставин	Квстанов - кількість критичних файлів, для яких встановлена частота бекапів Кпотреб - кількість критичних файлів, які потребують бекап	*100	100%
	Кплан - кількість систем, які мають план на випадок непередбачених обставин Кз - загальна кількість систем	*100	100%
	Кплан_чп - кількість систем, які мають опротестований план на випадок непередбачених обставин Кз - загальна кількість систем	*100
Підтримка апаратних та програмних засобів системи	Кобмеж - кількість систем з обмеженнями на персонал для підтримки Кз - загальна кількість систем	*100
	Ксхвалень - кількість задокументованих схвалень змін в програмах з ухваленням Кпрогр_змін - загальна кількість змін в програмах	*100
	Кпатч - кількість систем з патчами Кскан - загальна кількість _олу автоматич систем	*100
Цілісність даних	Кавто - кількість систем з автоматичним оновленням антивірусних баз та автоматичною перевіркою на наявність вірусів Кз - загальна кількість систем	*100	100%
	Кп_перев - кількість систем з перевіркою паролів Кп_заг - загальна кількість систем з паролями	*100	100%
Документація	Кдок - кількість програмних продуктів з супроводжувальною документацією в файлі Кпрогр_з - загальна кількість програмних продуктів	*100	100%
	Кд - кількість систем з задокументованою оцінкою ризику Кз - загальна кількість систем	*100	100%
Розуміння, навчання та тренінги безпеки	Кслужб - службовців з важливими обов`язками в галузі безпеки, які пройшли належні тренінги Кслужб_з - загальна кількість службовців з важливими обов`язками	*100
Можливість реагування на інциденти	Креаг - кількість частин агенції які мають можливість відповідати на інциденти Ккомп_з - загальна кількість компонентів	*100	100%
	Ка - кількість звітів було, які було зроблено в агенції за звітний період Кnipc - кількість звітів було, які було зроблено в NIPC за звітний період КFedCIRC - кількість звітів було, які було зроблено в FedCIRC за звітний період	И30= (Ка+ Кnipc+ КFedCIRC) *100
Ідентифікація та авторизація	Кзмын_пост - кількість систем зі зміненими паролями постачальника Кз - загальна кількість систем	*100	100%
Заходи логічного доступу	Кдоступ_перс - кількість персоналу з доступом до програмного забезпечення безпеки, що не є адміністраторами Кзаг_перс - кількість користувачів, які мають доступ до програмного забезпечення безпеки	*100	100%
	Кпротокол - кількість систем, які використовують заборонені протоколи Кз - загальна кількість систем	*100	0%
	Квеб_приват - кількість сайтів з політикою приватності Кзаг - загальна кількість сайтів в організації	*100	100%
Тривалий аудит	Клог_дій - кількість систем, в яких виконується зберігання дій користувачів Кзаг - загальна кількість користувачів	*100	100%

3.2 Модель Еркана Карамана

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

Через це, можна розділити метричні показники на 4 типи: результативності, ефективності, збитку та реалізації. Метричні показники, які обираються для оцінки, повинні відповідати цілям ефективності та повинні допомагати оцінити ключові аспекти ефективності. В деяких випадках метричні показники можна розділити на 3 типи: результативності, ефективності та реалізації. За моделлю Еркана Карамана, метричні показники розробляються згідно з 3 специфічними зонами оцінювання (Організаційні, Людські та Технічні аспекти оцінювання).

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

1. Фізична безпека;

2. Безпека мережі;

3. Заходи безпеки;

4. Полу автоматич;

5. Шифрування;

6. Аудит та періодичний перегляд;

7. Тренінги з безпеки;

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

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

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

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

Рисунок 3.2 - Таксономія метричних показників Еркана Карамана

Таблиця 3.2 - Таблиця метричних показників за стандартом Еркана Карамана

Метричний показник	Метод	Формула	Пояснення
1 Організаційний огляд
1.1 Перевірка політики
1. Чи організація має розвинену Політику Безпеки?	Контрольний лист	Так (1), Ні (0)	Для того, щоб почати перевірку повинен існувати Політика Безпеки
2. Чи є обов`язковим читати та підписувати Політику Безпеки для нових службовців?	Контрольний лист	Так (1), Ні (0)	Перший крок для того, щоб Політика Безпеки була застосована в організації. Ця процедура повинна повторюватись при прийомі нового службовця чи зміні посади
3. Який відсоток відділів має останню версію Політики Безпеки?	Розрахунок	Квідділів - кількість відділів з останньою версією ПБ Кзаг - загальна кількість відділів		Недостатньо мати Політику Безпеки, її необхідно розповсюдити серед відповідних відділів та керівників
4. Який відсоток службовців читав та підписав Політику Безпеки?	Розрахунок	Кслужб - кількість службовців, які читали та підписали Політику Безпеки Кзаг - загальна кількість службовців		Виходячи з 2 метричного показника, для того, щоб Політика Безпеки була ефективною необхідно, щоб її знали та прийняли користувачі системи
5. Який відсоток веб-сайтів має застосовану політику приватності?	Розрахунок	Квеб-сайтів - кількість веб-сайтів з застосованою політикою приватності Кзаг-загальна кількість веб-сайтів в організації		Якщо публіка має доступ до системи, повинні існувати заходи контролю цілісності програм та конфіденційності публіки
6. Який відсоток інцидентів, що трапились, незважаючи на попереджувальні міри, вказані в Політиці Безпеки?	Розрахунок	Кінц - кількість інцидентів, які трапились з урахуванням попереджувальних мір Кзаг - загальний відсоток інцидентів		Це свідчить про ефективність та простоту Політики Безпеки. Чи інциденти ще трапляються, незважаючи на попереджувальні мірі, вказані в Політиці Безпеки?
7. Чи Політика Безпеки ІТ легка в застосуванні (проста та практична)?	Аналіз	взагалі не (0), (1), (2), (3), (4) легка та практична	Політика, яка написана лише для того, щоб лежати на полиці, не буде ефективна. Менеджмент повинен підтвердити те, що користувачі задоволені Політикою Безпеки.
8. Чи Політику Безпеки ІТ легко підтримувати та керувати нею?	Аналіз	взагалі не (0), (1), (2), (3), (4) легка для підтримки та керування	Політика Повинна бути відкрита для змін та розвитку.
9. Який середній проміжок часу між перевірками політик на необхідність змін?	Аналіз	Тсер - середній проміжок часу Кзаг - загальна кількість переглядів політики з Тсер		Чи політика переглядається для змін та доповнень? Бажано мати як найменший проміжок часу між перевірками а також регулярні перевірки по встановленим датам та нерегулярні перевірки під час технічних змін.
10. Чи легко можуть отримати доступ до Політики Безпеки люди, які шукають інформацію?	Аналіз	взагалі не (0), (1), (2), (3), (4) легко отримати доступ та шукати інформацію	Цей метричний показник є індикатором доступності Політики Безпеки. Чи ПБ зберігається в електронному вигляді в мережі для доступу та пошуку інформації, або користувачі мають копію на вінчестері? Чи вона структурована та проіндексована для специфічних програм?
11. Чи Політика Безпеки ІТ містить класифікацію даних?	Контрольний Лист	Так (1), Ні (0)	Чи дані класифіковані за конфіденційністю та метою використання? Найбільш вживаною класифікацією є: некласифіковані дані, загальнодоступні, тільки для компанії, конфіденційні
12. Який відсоток даних зберігається за принципом “класифікація даних”?	Розрахунок	Ккласс - кількість даних, які зберігаються за принципом “класифікація даних” Кзаг - загальна кількість загальнодоступних даних		Обчислюється в мегабайтах. Цей метричний показник використовується для визначення рівня застосування принципу “класифікації даних' в Політиці Безпеки ІТ.
13. Чи фізичне обладнання мережі класифікується таким же чином?	Контрольний Лист	Так (1), Ні (0)	_олу авт та інші портативні пристрої, мейнфрейми, сервери повинні мати правила використання та директиви захисту.
14. Чи визначає політика рівень відповідальності кожної особи за ІБ?	Контрольний Лист	Так (1), Ні (0)	Коли користувачі підписують Політику Безпеки ІТ, вони повинні розуміти, що вони відповідальні за захист ІТ інфраструктури.
15. Чи вказується авторство?	Контрольний Лист	Так (1), Ні (0)	Політика Безпеки ІТ повинна відноситись до когось, хто б міг обробляли запитання користувачів. Автор також відповідає за підтримку документів їх керуванням.
16. Чи пояснюються функції та відповідальності Службовцю Безпеки?	Контрольний Лист	Так (1), Ні (0)	Чи в документі вказані обов`язки та роль Службовця Безпеки?
17. Чи хто-небудь крім власника має право змінювати політику	Контрольний Лист	Так (1), Ні (0)	Для захисту цілісності Політики Безпеки повинна існувати гарантія, що тільки один автор (окрема персона чи члени групи) має право вносити зміни в документ
18. Чи визначена відповідальність за специфічні технічні проблеми для відповідних людей?	Контрольний Лист	Так (1), Ні (0)	Чи План Безпеки ІТ визначає хто відповідає за техніку? Чи політика вимагає, щоб важлива інформація та технології фізично захищались весь час?
19. Чи політика передбачає мінімальний контроль _олу автоматич?	Контрольний Лист	Так (1), Ні (0)	Контроль аутентифікація, наприклад, довжина паролю, мінімальний інтервал зміни паролю та ін. повинні бути встановлені для того, щоб отримати надійну політику безпеки
20. Чи політика включає документацію по охороні багатьох з ваших технологій?	Контрольний Лист	Так (1), Ні (0)	Метою політики безпеки є гарантія того, що організація розуміє суть ризиків безпеки ІТ.
21. Чи існує процедура реєстрації користувачів?	Контрольний Лист	Так (1), Ні (0)	Чи відділ ІТ реєструє кожного користувача згідно з процедурами, відповідно Політиці Безпеки? Чи процедура слідкує за вибором унікальних та важних для відгадування _олу ав та паролів?
22. Чи існує процедура усунення реєстраційного _олу а користувача?	Контрольний Лист	Так (1), Ні (0)	Чи існує процедура для усунення застарілого реєстраційного _олу а користувача? Відомо, що після звільнення службовця, його _олу ав можуть зловживати.
23. Який відсоток систем використовує політику перевірки паролів	Розрахунок	Кперевірки - кількість систем з політикою перевірки паролів Кзаг - загальна кількість систем		Чи існують політики перевірки паролів?
24. Чи існує процедура, за якою проекти повинні проходити тест на відповідність політиці безпеки та контролю якості?	Контрольний Лист	Так (1), Ні (0)	Проекти можуть використовувати конфіденційні дані та важливі інформаційні технології; для попередження втрати інформації чи уразливостей проекти повинні оцінені виміряннями безпеки ІТ
25. Який відсоток проектів пройшов тест на відповідність політиці безпеки?	Розрахунок	Ксхвал - кількість схвалених проектів Кзаг - загальна кількість проектів		Метою метричного показника є виміряння ефективності процедур по тестуванню на відповідність політиці безпеки
26. Чи існує процедура, яка відповідає за оновлення антивірусних баз?	Контрольний Лист	Так (1), Ні (0)	Чи оновлення антивірусних баз виконується через визначений проміжок часу або воно виконується після виникнення нової загрози?
27. Який середній проміжок часу між оновленнями антивірусних баз?	Розрахунок	Кперіод - визначений проміжок часу Кзаг - кількість оновлень в рамках обраного проміжку часу		Менший проміжок часу між оновленнями забезпечить більший захист від вірусів.
28. Чи існує процес встановлення патчів?	Контрольний Лист	Так (1), Ні (0)	Деякі продавці надають можливість автоматичних оновлень, але адміністратори повинні керувати схемою оновлень та важливістю патчів. Чи існує людина чи сервіс, якій відповідає за цей процес та чи визначено як часто необхідно перевіряти програми на наявність оновлень?
29. Який середній проміжок часу між реалізацією патчів та їх встановленням?	Розрахунок	Кзатримки - загальна кількість часової затримки для встановлення патчів Кзаг - загальна кількість процесів встановлення патчів за визначений часовий період		Системи, які включають ОС, фаерволи та сервери повинні регулярно оновлюватись; коротший період буде давати кращий рівень захисту
30. Чи існує процедура для процесу створення бекапів	Контрольний Лист	Так (1), Ні (0)	Схвалена процедура для створення бекапів рекомендується для планування процесів, керування плівками та їх зберіганням
31. Чи існує процедура для тестування та нового/оновленого технічного обладнання перед застосуванням	Контрольний Лист	Так (1), Ні (0)	Частка системи управління конфігурацією, усе нове технічне обладнання повинно бути опротестоване та занесене в базу даних
32. Який відсоток службовців проходить перевірку минулого життя перед прийняттям на роботу?	Розрахунок	Кслужб_пройшли - кількість службовців, які пройшли процес Кзаг - загальна кількість службовців		Процес гарантує те, що конфіденційні дані не потраплять до рук людини з кримінальним минулим чи обмеження, пов`язані з хакерською діяльністю
33. Чи існує дисциплінарний процес за порушення безпеки організації?	Контрольний Лист	Так (1), Ні (0)	Чи політика передбачає дисциплінарний процес для службовців, які порушили процеси та процедури безпеки організації?
34. Кількість працівників, які зіткнулися з дисциплінарним процесом за минулий рік	Розрахунок	Кількість працівників, які зіткнулися з дисциплінарним процесом за минулий рік	Чи система дійсно використовується та чи є ефективними її правила. Кількість працівників, які зіткнулися з дисциплінарним процесом за минулий рік повинна бути в балансі з кількістю інцидентів
35. Чи існує процедура для створення звітів про інциденти, слабкості чи збої в програмах	Контрольний Лист	Так (1), Ні (0)	Чи система передбачає, щоб користувачі відчували відповідальність за інциденти та слабкості в безпеці та повідомили про таки випадки адміністраторів?
36. Яка кількість інцидентів, слабкостей та збоїв за минулий проміжок часу?	Розрахунок	Загальна кількість отриманих звітів
2 Оцінка людських ресурсів
37. Чи користувачі інформуються про політику безпеки та про те, як захищати важливу інформацію?	Контрольний Лист	Так (1), Ні (0)	Чи політика безпеки роздрукована та розповсюджена чи навіть підписана користувачами без надання відповідних тренінгів на тему “навіщо все це” чи “як це працює”
38. Чи користувачі інформуються про їх рівень відповідальності за безпеку?	Контрольний Лист	Так (1), Ні (0)	Збереження паролів в таємниці, не залишання комп`ютера без уваги, не відкривання підозрілих листів та інші ключові пункти, про які користувачі повинні бути повідомлені
39. Чи досягнутий принцип індивідуальної відповідальності користувачів за безпеку інформації?	Контрольний Лист	Так (1), Ні (0)	Для досягнення принципу індивідуальної відповідальності повинна існувати не тільки Політика Безпеки ІТ, але й тренінги, листи з новинами, буклети та ін.
40. Який відсоток працівників зі значними відповідальностями в галузі безпеки, які пройшли спеціальні тренінги?	Розрахунок	Ксерт - кількість сертифікованих/тренованих працівників Кзаг - загальна кількість працівників		Цей метричний показник свідчить про рівень досвідченості серед певних ролей безпеки та відповідальностей для специфічних систем всередині організації. Як джерела даних можуть бути використані сертифікати працівників про завершення курсів
41. Чи можете ви визначити рівень знать розуміння працівників?	Контрольний Лист	Нема розуміння про Ризики Безпеки ІТ (0), (1), (2), (3), (4) розуміння проблем безпеки ІТ	Результати тестування на розуміння чи персональний огляд Службовців безпеки; рівень розуміння також свідчить про ефективність тренувальних програм, які проводились раніше, якщо вони проводились
42. Який середній час тренувань на кожного працівника?	Розрахунок	Квитрачений_час - загальний час, витрачений на тренування Кзаг - загальна кількість працівників		Завдяки гарним тренінгам може бути досягнутий більш високий рівень розуміння.
43. Який відсоток вищого рівня освіти?	Розрахунок	Квища_освіта - кількість працівників з вищим рівнем освіти Кзаг - загальна кількість працівників		Існує 3 рівні освіти: “undergraduate”, “graduate”, “post-graduate”. Дані для розрахунку метричного показника можуть бути отримані з бази даних працівників
3 Технічний огляд
3.1 Перевірка контролю доступу
44. Чи існує сильна політика паролів, введена в дію управлінням?	Контрольний лист	Так (1), Ні (0)	При встановленні політик та процедур без визначення правил для контролю доступу, неможна очікувати на ефективність
45. Чи аутентифікація користувачів виконується індивідуально, за допомогою паролів, старт карт чи інших пристроїв?	Контрольний лист	Так (1), Ні (0)	“Фази доступу' є більш ефективними ніж простий 6 - значний пароль, але система фізичної аутентифакації гарантує набагато більш високий рівень безпеки.
46. Який відсоток унікальний ID користувачів?	Розрахунок	Кунік - кількість користувачів з унікальними ID Кзаг - загальна кількість користувачів		Чи механізм контролю доступу використовує розділення обов`язків? Лист контролю доступу та файл з паролями будуть зручними для обчислення метричного показника
47. Який відсоток неактивних користувачів?	Розрахунок	Кнеактивних - кількість неактивних акантів Кзаг - загальна кількість акантів		В залежності від статистики логів, метричний показник допоможе адміністраторам виявити _олу а, які не заходили в систему 60 днів, тобто є неактивними. Ці _олу а повинні бути знищені для запобіганню появі вразливосте
48. Який відсоток вищого рівню в системах без активних паролів постачальників програмного забезпечення?	Розрахунок	Кбез паролів - кількість систем без активних паролів постачальників програмного забезпечення Кзаг - загальна кількість систем		Багато програмного забезпечення використовують паролі “з коробки”. Ці паролі, назначені постачальником програмного забезпечення, повинні бути негайно змінені, тому що вони загально відомі та вразливі до атак
49. Чи існує документація, яка пояснює правила контролю доступу та права для різних груп користувачів?	Контрольний лист	Так (1), Ні (0)	Правила та права контролю доступу повинні бути визначені згідно з політикою та повинні бути задокументовані для майбутніх перевірок. Для ефективності, документація повинна періодично переглядатися та тестуватися
50. Чи є регулярне переглядання прав доступу користувачів?	Контрольний лист	Так (1), Ні (0)	Це є мірою для перевірки списків доступу та залежної документації для виправлення помилок
51. Яка кількість користувачів має доступ до охоронного програмного забезпечення та не є адміністраторами безпеки.	Розрахунок	Кдоступу - кількість користувачів, які мають доступ до охоронного програмного забезпечення та не є адміністраторами безпеки Кадміністраторів - кількість адміністраторів безпеки		Отриманий з попереднього метричного показника, дані для аналізу беруться зі списку контролю доступу; службовці безпеки можуть оцінити рівень доступу до охоронного програмного забезпечення
52. Чи заходи безпеки використовуються в логах ваервола, в системах виявлення атак та VPN?	Контрольний лист	Так (1), Ні (0)	Чи система дозволяє віддалений доступ та з якою метою? Чи використовується шифрування? Якщо так, чи методи шифрування були офіційно схвалені? Чи генерація ключів також безпечна?
53. Чи зберігаються спроби входу в систему в логах?	Контрольний лист	Так (1), Ні (0)	Зберігання логів є критичним, але не достатнім, якщо ці логи не аналізуються
54. Чи Політика Безпеки ІТ визначає число спроб перед помилкою аутентифікації	Контрольний лист	Так (1), Ні (0)	Чи вимоги визначення кількості невдалих спроб _олу автоматич зазначені в політиці та прийняті процедурою _олу автоматич?
55. Чи контролюється фізичний доступ до обладнання та ІТ систем?	Контрольний лист	Так (1), Ні (0)	При інсталяції фаєрволів, VPN та ін. частку системи безпеки ІТ, організація може стати уразливою до старих трюків фізичної безпеки та соціальної інженерії
3.2 Перевірка логів безпеки
56. Чи вивчаються логи активності в фаєрволах?	Контрольний лист	Так (1), Ні (0)	Чи існує система або процес для вивчання активності в логах фаєрвола та аналізу даних для майбутньої діяльності?
57. Чи вивчаються логи IDS?	Контрольний лист	Так (1), Ні (0)	Чи існує система або процес для вивчання логів IDS та аналізу даних для майбутньої діяльності?
58. Чи вивчається використання веб-сайтів?	Контрольний лист	Так (1), Ні (0)	Чи використання веб-сайтів вивчається з продуктивних причин (загроза відказу сервісу)?
59. Яка кількість неавторизованих з`єднань на протязі минулого періоду?	Розрахунок	Обчисліть кількість неавторизованих з`єднань на протязі минулого періоду	В рамках визначеного періоду, обчислення кількості неавторизованих з`єднань через аналіз та вивчення логів може надати інформацію про зміни в продуктивності в часі
60. Яка кількість закритих з`єднань?	Розрахунок	Обчисліть кількість закритих з`єднань за визначений період	Так як фаєрволи надають логи (дані), закриті з`єднання можуть означати спроби атак чи небезпечні спроби з`єднання. Метричний показник показує рівень ефективності використання фаєвролів
61. Яка кількість електронних листів, відхилених за спам чи обмеження за розміром?	Розрахунок	Квідхилених - кількість відхилених електронних листів Кзаг - загальна кількість електронних листів		В залежності від кількості електронних листів, нормою є отримання низької кількості відхилених електронних листів
62. Яких загальний розмір (в мегабайтах) відхилених електронних листів?	Розрахунок	Обчисліть загальний розмір (в мегабайтах) відхилених електронних листів за минулий період	Для розуміння який об`єм каналу займають відхилені електронні листи знання загального їхнього розміру є ефективним вимірянням. Таким шляхом можна зрозуміти загрозу спам-листів для системи
63. Який відсоток вихідних електронних листів з невідповідним вмістом?	Розрахунок	Обчисліть відсоток вихідних електронних листів з невідповідним вмістом за минулий період	Фільтри вмісту часто використовуються в системі для припинення небажаного вмісту та зменшення трафіку для оптимізації каналу інтернету. Для оцінки ефективності попередження невідповідного вмісту, кількість вихідних електронних листів з невідповідним вмістом за минулий період буде представляти поточний стан, якщо вимірювати регулярно
64. Який коефіцієнт хибно відхилених електронних листів?	Розрахунок	Квхибно_відхилених - кількість хибно відхилених електронних листів Квідхилених - кількість відхилених електронних листів		Метричний показник необхідний для запобігання хибного відхилення електронних листів
65. Чи організація використовує заходи автоматичного ведення аудиту?	Контрольний лист	Так (1), Ні (0)	Аналіз логів є дуже важкою та дорогою працею, яка вимагає цілодобового спостерігання. Через це розробляються автоматизовані заходи. Але все ж таки людська експертиза є дуже важливою. Чи хто-небудь переглядає та перевіряє логи?
66. Яка кількість закритих спроб доступу до сайту?	Розрахунок		В деяких організаціях чи компаніях доступ до інтернету заборонений через мережу компанії або частково заборонений для деяких сайтів. Метричний показник може надати цінні дані для виміряння збитку Політики Безпеки ІТ від обмежень
67. Який відсоток систем захищений від вірусів/черв`яків / троянів?	Розрахунок	Канти-вірус - кількість систем, які захищені анти вір. програмами Кзаг - кількість систем, які повинні бути захищені від вірусів		Метою метричного показника є досягнення 100 відсотків. Після того, як усі система гарантовано захищені можна виконувати інші виміри.
68. Відсоток систем з регулярними оновленнями антивірусних баз та регулярним скануванням на наявність вірусів?	Розрахунок	Коновлення - кількість систем з регулярним оновленням антивірусних баз (щонеділі) Кзаг - загальна кількість захищених систем		Антивірусне програмне забезпечення вимагає регулярного оновлення антивірусних баз та керування. Простої інсталяції недостатньо, оновлення антивірусних баз та сканування повинні виконуватись автоматично чи вручну
69. Яка кількість систем була попереджена про вірусну активність за минулий період часу?	Розрахунок	Обчисліть кількість систем, яка була попереджена про вірусну активність за минулий період часу	Знаючи кількість інфікованих комп`_олу а, жорстких дисків та ін. буде свідчити про ефективність антивірусних оновлень та сканувань
3.4 Перевірка бекапів та непередбачених обставин
70. Який відсоток важливих даних в системі?	Розрахунок	Кважливі дані - розмір важливих даних в системі Кзаг - загальний розмір даних в системі		Визначення найбільш важливих даних допоможе назначити для них пріоритети. Всі обчислення даних в цій секції повинні проводитись згідно з розміром даних а не кількістю файлів
71. Для якого відсотку важливих даних періодично робляться бекапи?	Розрахнок	Кбекап - кількість критичних файлів, для яких робляться бекапи Кзаг - загальна кількість файлів, для яких необхідно виконувати бекапи		Чи часто проводяться бекапи для класифікованих даних та операцій, та яка ефективність цієї процедури? Необхідно досягнути високого відсотку для того, щоб сказати, що процес бекапу є ефективним
72. Який відсоток систем має план на випадок непередбачених обставин?	Розрахунок	Кплан - кількість систем, які мають план на випадок непередбачених обставин Кзаг - загальна кількість систем		Якщо система має план, вона готова до внутрішніх/зовнішніх впливів. Але для того, щоб план був ефективний, він повинен бути задокументований та розповсюджений серед працівників
73. Чи план на випадок непередбачених обставин тестується щорічно?	Контрольний лист	Так (1), Ні (0)	Для того, щоб план був ефективним його необхідно періодично тестувати. Регулярні тесту зроблять план більш обґрунтованим та легшим в застосуванні
74. Який відсоток систем, для яких план на випадок непередбачених обставин тестувався в минулому році?	Розрахунок	Ктест - кількість систем, для яких план тестувався в минулому році Кзаг - загальна кількість систем з планом		Якщо організація має архів планів на випадок непередбачених обставин, воно повинно раз на рік тестуватися та коригуватися.
75. Чи виконуються та документуються оцінки ризиків	Контрольний лист	Так (1), Ні (0)	В поєднання з планом на випадок непередбачених обставин оцінки ризиків займають важливе місце. Повинні проводитись та документуватись певні тести та сканування на уразливості.
76. Чи використовується система “безпеки в стані збою”?	Контрольний лист	Так (1), Ні (0)	Чи система зберігає безпечний стан у разі збою?
77. Чи обладнання зберігається від збоїв в електромережі?	Контрольний лист	Так (1), Ні (0)	Електромережі створюють великий рівень ризиків через розповсюдження. Ефективність джерел електроструму, УПС чи запасних генераторів може вирішити цю проблему
78. З якої кількості інцидентів були зроблені внутрішні звіти та звіти в юридичні інстанції?	Розрахунок	Обчисліть кількість внутрішніх звітів та звітів в юридичні інстанції	Багато компаній не подають звіти до юридичних організацій для того, щоб зберегти свій імідж. Але організації повинні використовувати цей метричний показник навіть для своєї найбільш секретної інформації для отримання реалістичних результатів
3.5 Перевірка конфігурації
79. Чи існує база даних управління конфігурацією, яка періодично переглядається адміністраторами?	Контрольний лист	Так (1), Ні (0)	База даних управління конфігурацією дозволяє працівникам використовувати програмне та апаратне забезпечення в мережі. Для управління мережею адміністраторі повинні добре знати її
80. Який відсоток систем з останньою встановленою версією патчів?	Розрахунок	Кпатч - кількість систем за патчами Кзаг - загальна кількість систем		Перевірка версії парчів може бути встановлена завдяки заходам сканування на вразливості чи через регулярні перевірки. Дуже важливо визначати версію патчів для виміряння рівню ефективності системи управління патчами
81. Чи використовуються стандарти по укріпленню ОС?	Контрольний лист	Так (1), Ні (0)	Укріплення ОС є дуже важливим в сьогоднішній мережі тому, що кожного дня з`являються нові уразливості та хакери намагаються отримати контроль над слабкими системами
82. Який відсоток систем зі схваленими стандартами по укріпленню ОС?	Розрахунок	Ксхвалені станд - кількість систем зі схваленими стандартами Кзаг - загальна кількість систем		Метричний показник надає інформації об ефективності застосування стандартів по укріпленню ОС. Бажан отримати 100%.
83. Який відсоток комп`_олу а з автоматичним блокуванням дисплею?	Розрахунок	Кблок - кількість комп`_олу а з авто блокуванням дисплею Кзаг - загальна кількість комп`_олу а		Автоматичне блокування дисплею є гарною мірою захисту коли дисплей залишився деякий час без уваги
84. Який відсоток комп`_олу а може бути загружений тільки з жорсткого диску?	Розрахунок	Кдиск - кількість комп`_олу а, які можуть бути загружені тільки з жорсткого диску Кзаг - загальна кількість комп`ютерів		Загрузка з USB,CD_Rom чи дискет може призвести до невизначених порушень в безпеці (привілеї адміністратора). Система має бути сконфігурована таким чином, щоб запобігти таким діям
85. Чи відключені непотрібні сервіси на сервері?	Контрольний лист	Так (1), Ні (0)	Сервери зазвичай мають набір сервісів та протоколів, багато з яких включені за умовчанням. Адміністратор безпеки повинен виключити непотрібні сервери, тому що вони є джерелом уразливостей
86. Чи в організації існує хоча б 1 прийнятий та схвалений крипто алгоритм, який використовується в захищених системах	Контрольний лист	Так (1), Ні (0)	Використання крипто алгоритмів для використання їх в засобах комунікації та конфіденційності важливих даних є необхідним.
87. Який відсоток внутрішнього та зовнішнього захищеного зв`язку?	Розрахунок	Кне захищений канал - кількість відправлених та отриманих ел. листів по незахищеному каналу Кзаг - загальна кількість електронних листів		Чи існує активне використання крипто алгоритмів? Метричний показник є дуже корисним для оцінки вимірянь ефективності крипто алгоритмів
88. Чи можливе невизнання гарантії оригінальності в системі зв`язку?	Контрольний лист	Так (1), Ні (0)	Ця система гарантує те, що відправник не зможе сказати, що він не відправляв дані. Необхідно використовувати метод, який би давав гарантію, що дані надаються з доведенням ореганальності інформації (цифровий підпис, криптографія відкритого ключа)
89. Чи можливе невизнання факту отримання в системі зв`язку?	Контрольний лист	Так (1), Ні (0)	Ця система гарантує те, що одержувач не зможе сказати, що він не одержав дані. Необхідно використовувати метод, який би давав гарантію, що дані надаються з доведенням отримання інформації
90. Який відсоток портативних пристроїв з можливістю шифрування важливих файлів?	Розрахунок	Кшифр - кількість пристроїв з можливістю шифрування Кзаг - загальна кількість пристроїв		Потративні пристрої повинні бути захищені, тому що вони вважаються більш уразливими через те, що постійно переміщуються разом зі своїми користувачами та є ризик викрадення чи залишання їх без уваги. Усі важливі файли повинні бути зашифровані на таких пристроях

4. Побудова підходу реалізації впровадження метричних показників

Пайне (2001) запропонував 7 кроків для керуванням процесом підходу побудови метричних показників:

· Визначення цілей та об`єктів метричних показників;

· Визначення які метричні показники необхідно зібрати;

· Розвиток стратегій для генерації метричних показників;

· Встановлення еталонів та завдань;

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

· Створення плану дій та дія за ним;

· Встановлення формального циклу перегляду/покращення підходу метричних показників.

Інший підхід, підхід метричних показників за стандартом NIST (Сван сон та ін. 2003), складається з 4 незалежних компонентів: Аналіз Результатів Метричних Показників, Вимірні Метричні Показники Ефективності, Практичні Політики Безпеки та Процедури, та Сильна Підтримка Управління на Верхньому рівні.

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

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

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

Існує декілька класифікацій, доступних для IS метричних показників згідно з їх використанням, користувачами чи методом або стандартом (наприклад, СС). Визначення для об`єктів безпеки та змінних методів концепцій вимірів може залежати від зони та концептуального оточення. Класифікація за Хеннінгом (2001) та Катцке (2001) були обговорені для розуміння різноманіття зон.

5. Огляд підходу впровадження метричних показників безпеки

Підхід до реалізації метричних показників безпеки всередині організації повинен включати 4 незалежні компоненти:

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

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

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

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

6. Основа впровадження метричних показників безпеки ІТ

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

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

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

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

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

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

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

7. Види метричних показників

Зрілість програми безпеки ІТ організації визначає тип метричних показників, які можуть бути успішно зібрані (рисунок 7.1).

Рисунок 7. 1 - Зрілість програми безпеки та типи вимірів

Зрілість програми визначається існуванням та рівнем розвитку процесів та процедур. В ході дозрівання програми безпеки її політики стають більш детальними та краще документованими, процеси, які використовує програма, стають більш стандартизованими, вони виробляють дані, які можуть бути використані для оцінки продуктивності. Згідно NIST SP 800-26, програма безпеки розвивається наступним чином:

1. Визначення політики;

2. Визначення процедур;

3. Реалізація процедур та заходів безпеки;

4. Тестування процедур та заходів безпеки;

5. Інтеграція процедур та заходів безпеки.

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

Типи метричних показників (результативність, ефективність, збиток), які дійсно можуть бути отримані та які можуть бути корисними для покращення продуктивності, залежать від зрілості реалізації заходів безпеки. Також різни типи метричних показників можуть бути використані одночасно, головна ціль метричних показників безпеки ІТ змінюється, як тільки реалізація заходів безпеки стає більш зрілою. Коли система досягає рівня 1 та рівня 2, результати цих метричних показників будуть менші за 100 %, показуючи, що система ще не досягла рівня 3. Коли результати реалізації метричних показників досягають та залишаються на 100%, система повністю реалізувала заході безпеки та досягла рівня 3.

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

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

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

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

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

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

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

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

Об'єкти безпеки - конфіденційність, цілісність та доступність.

Доступність - гарантія своєчасного та надійного доступу до інформації та її використання.

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

Цілісність - захист від несанкціонованої модифікації чи знищення інформації.

8. Реалізація впровадження метричних показників безпеки

8.1 Фактори успіху

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

8.1.1 Організаційний розгляд

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

8.1.2 Керованість

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

8.1.3 Підприємства управління даними

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

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

8.2 Технологія розробки та застосування метричних показників

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

8.2.1 Процес розробки метричних показників

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

Рисунок 8.1 - Процес розвитку метричних показників безпеки ІТ

Процес розробки метричних показників ІТ складається з двох головних дій:

1. Ідентифікація та визначення поточної програми безпеки ІТ;

2. Розробка та вибір метричних показників для оцінки використання, ефективності, результативності та збитку заходів безпеки.

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

8.2.2 Визначення інтересів співвласника

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

1. Директор підприємства;

2. Директор інформаційний службовець (СІО);

3. Менеджер програми безпеки/службовець безпеки інформаційної системи (ISSO);

4. Менеджер програми/власник системи;

5. Системний адміністратор/адміністратор мережі;

6. Персонал підтримки ІТ.

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

Прикладами другорядних співвласників безпеки є:

1. Директор фінансів (CFO);

2. Навчальна організація;

3. Людські ресурси/Організація персоналу;

4. Головні інспектори (IG).

Інтереси кожного співвласник будуть відрізнятися, вони залежать від їх посади в рамках ієрархії організації. Кожен співвласник може вимагати окремий набір метричних показників. Інтереси співвласників можуть бути визначені в ході інтерв`ю, “мозкової атаки”, перегляді обов`язків. Загальна кількість метричних показників повинна бути 5-10 для кожного співвласника окремо. Рекомендується використовувати меншу кількість метричних показників для кожного співвласника, якщо організація встановлює програму безпеки; кількість метричних показників буде збільшуватись по мірі дозрівання програми безпеки ІТ та метричних показників.

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

8.2.3 Визначення цілей

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

1. Акт Клінгера-Кохена;

2. Директиви президентських рішень;

3. FISMA,

4. Проспект ОМВ А-130, додаток lll,

5. NIST FIPS та спеціальні публікації.

8.2.4 Перегляд процедур, керівництв та політик безпеки ІТ

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

1. Плани системи безпеки;

2. FISMA OMB план дій POA&M звіти;

3. Пізні знаходження GAO та IG;

4. Контроль за діями, пов`язаними з безпекою, такими як звіти про інциденти, тестування, керування мережею, аудит логів та ін.;

5. Оцінка ризиків та результати тестових проникнень;

6. Документація С&A;

7. Плани непередбачених обставин;

8. Плани конфігурації управління;

9. Статистика та результати навчання.

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

8.2.5 Розробка та вибір метричних показників

Кроки 5,6 та 7 (рисунок 8.1) включають розробку метричних показників, що оцінюють процес застосування, ефективності, результативність та збиток діяльності. Специфічний аспект безпеки ІТ, на якому метричні показники будуть фокусувати свою діяльність, залежить від рівня ефективності. Реалізація буде виконуватись наступним чином:

1. Встановлення політик та процедур;

2. Оцінювання застосування політик та процедур;

3. Оцінювання результатів застосування політик та процедур;

4. Ідентифікація збитку від застосування політик та процедур.

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

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

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

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

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

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

8.2.6 Встановлення цілей ефективності

Після ідентифікації та описання метричних показників в лінії індикації форми метричних показників повинні бути ідентифіковані цілі ефективності. Цілі ефективності встановлюють критерій, на основі якого оцінюється успіх. Ступінь успіху базується на наближенні результатів метричних показників до сформованої цілі ефективності. Механізм встановлення цілей ефективності відрізняється для метричних показників реалізації та інших трьох типів метричних показників (ефективність, результативність та збиток). Для метричних показників реалізації ціль встановлюється в 100% завершенні специфічних завдань. Коли метричні показники реалізації, що відповідають всім критичним елементам NIST SP800-26, досягають 100% завершення завдання, організація досягає рівня 3.

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

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

На рисунку 8.2 надано приклад тенденції розвитку метричних показників безпеки ІТ, що базується на проценті схвалених планів безпеки.

Рисунок 8.2 - Приклад тенденції розвитку метричних показників безпеки ІТ

8.3 Реалізація впровадження метричних показників в організації

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

Рисунок 8.2 - Процес реалізації впровадження метричних показників безпеки ІТ в організації

8.3.1 Підготовка для збору даних

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

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

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

2. Аудиторія для плану;

3. Процес збору метричних показників, аналіз та складання звіту, визначеного для специфічної структури організації, процесів, політик та процедур;

4. Деталі координації всередині офісу CIO, тобто оцінка ризику, дії по складанню FISMA та C&A звітів;

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

6. Побудова чи вибір сукупності даних чи елементів контролю;

7. Модифікація сукупності даних чи елементів контролю;

8. Формати звітів по метричним показникам.

8.3.2 Збір даних та аналіз результатів

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

1. Збір даних метричних показників, згідно з процесами, що визначені в Плані Реалізації Метричних Показників;

2. Об`єднання зібраних даних та зберігання в форматі, який сприяє аналізу даних та складанню звіту, наприклад, в базах даних чи електронних таблицях;

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

4. Виявлення причин низької ефективності;

5. Визначення зон, що потребують покращення.

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

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

1. Ресурси - недостатність людських, грошових чи інших видів ресурсів;

2. Тренінги - відсутність відповідних тренінгів по інсталяції, адмініструванню та експлуатації системи;

3. Оновлення системи - виправлення в безпеці, які були усунені, але не заміщені на протязі операції оновлення системи;

4. Конфігурація практик менеджменту - нові чи оновлені системи, які не настроєні з відповідними установками;

5. Розуміння та обов`язки - відсутність розуміння менеджменту чи обов`язків безпеки;

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

7. Архітектури - неповна архітектура системи чи безпеки, що робить систему вразливою;

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

8.3.3 Ідентифікація коригуючих дій

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

Цей крок включає наступні дії:

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

2. Розділення коригуючих дій за пріоритетами, що базуються на цілях зменшення ризику - може бути декілька коригуючих дій, які можна застосувати для однієї проблеми з ефективністю; однак деякі не можуть бути застосовані, якщо вони не сумісні з проблемою чи занадто дорогі. Застосовні коригуючі дії повинні бути розділені за пріоритетами для кожної проблеми в порядку зростання ціни та в порядку убування збитку. Процес менеджменту ризику, описаний в NIST SP800-30, Керівництво з менеджменту ризику для Систем Інформаційних Технологій, повинен бути використаний для розділення на пріоритети. Якщо для метричних показників було назначено значення на кроці Підготовка для збору даних, ці значення повинні бути використані для розділення на пріоритети;

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

8.3.4 Розвиток необхідного бюджету та отримання ресурсів

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

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

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

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

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

4. Проведення чуттєвого аналізу для визначення які перемінні мають найбільший вплив на вартість;

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

6. Проведення аналізу ризиків, для знаходження ймовірностей перешкод та ризиків альтернатив;

7. Приготування бюджету.

Фаза отримання ресурсів включає наступні дії:

1. Відповідь на запроси оцінки бюджету;

2. Отримання виділеного бюджету;

3. Розділення доступних ресурсів за пріоритетами, припускаючи, що всі необхідні ресурси будуть розміщені;

4. Призначення ресурсів для виконання коригуючих дій.

8.3.5 Прийняття коригуючих дій

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

Висновок

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

Щодо рівню ефективності безпеки, службовці безпеки ІТ можуть, дивлячись на результати виміряння, аналізувати систему метричних показників та вирішити чи потрібно вносити якісь зміни в безпеку. В залежності від типа та розмірів організації, система метричних показників може допомогти спеціалістам визначити їх мережу як “слабку чи захищену”. Рівень ефективності безпеки для організації розраховується не для того, щоб порівняти її з іншими організаціями. Метою є тривала оцінка та перевірка ефективності безпеки ІТ виміряними метричними показниками. Таким чином, адміністратор безпеки може лише робити певні коментарії згідно з профілем організації, наприклад “Наш рівень безпеки вищий, ніж у минулому році, відсоток систем, в яких були вірусні попередженні, зменшився на 10 відсотків”.

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

Перелік посилань

1. FIPS PUB 200. Мінімальні вимоги безпеки для федеральної інформації та інформаційних систем. Гайзерсбург, MD 20899-8930, червень 2006.

2. FIPS PUB 199. Стандарти на катигоріювання федеральної інформації та інформаційних систем, Гайзерсбург, MD 20899-8900, лютий 2006.

3. NIST SP800-53. Інформаційна безпека,. Гайзерсбург, MD 20899-8930, лютий 2006.

4. NIST SP800-55. Комп`ютерна безпека, MD 20899-8933, червень 2008.

5. Оцінка ефективності безпеки ІТ за допомогою виміряних метричних показників, Erkan Kahraman.