Опорный конспект

з’єднання

"+" механізм придатний для реалізації даної функції безпеки; "-" механізм не призначений для реалізації даної функції безпеки.

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

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

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

Згідно рекомендаціям X.800, зусилля адміністратора засобів безпеки повинні розподілятися по трьох напрямах:

адміністрування інформаційної системи в цілому;

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

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

Серед дій, що відносяться до ІС в цілому, відзначимо забезпечення актуальності політики

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

аудит і безпечне відновлення.

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

Обов’язки адміністратора механізмів безпеки визначаються переліком задіяних механізмів. Типовий список такий:

управління ключами (генерація і розподіл);

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

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

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

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

управління маршрутизацією (виділення довірених шляхів);

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

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

3 Стандарт ISO/IEC 15408 "Критерії оцінки безпеки інформаційних технологій" 3.1 Основні поняття

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

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

101

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

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

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

Як і "Оранжева книга", ОК містять два основні види вимог безпеки:

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

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

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

Дуже важливо, що безпека в ОК розглядається не статично, а в прив’язці до життєвого циклу об’єкту оцінки. Виділяються наступні етапи:

визначення призначення, умов вживання, цілей і вимог безпеки;

проектування і розробка;

випробування, оцінка і сертифікація;

упровадження і експлуатація.

ВОК об’єкт оцінки розглядається в контексті середовища безпеки, яка характеризується певними умовами і загрозами.

У свою чергу, загрози характеризуються наступними параметрами:

джерело загрози;

метод дії;

вразливі місця, які можуть бути використані;

ресурси (активи), які можуть постраждати.

Вразливі місця можуть виникати через недолік в:

вимогах безпеки;

проектуванні;

експлуатації.

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

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

З погляду технології програмування в ОК використаний застарілий бібліотечний (не об’єктний) підхід. Щоб, проте, структурувати простір вимог, в "Загальних критеріях" введена ієрархія клас-

семейство-компонент-елемент.

Класи визначають саме загальне, "наочне" угрупування вимог (наприклад, функціональні вимоги підзвітності).

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

Елемент - неподільна вимога.

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

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

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

102

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

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

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

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

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

3.2 Функціональні вимоги

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

Перерахуємо класи функціональних вимог ОК:

ідентифікація і аутентифікація;

захист даних користувача;

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

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

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

доступ до об’єкту оцінки;

приватность (захист користувача від розкриття і несанкціонованого використовування його ідентифікаційних даних);

використовування ресурсів (вимоги до доступності інформації);

криптографічна підтримка (управління ключами);

зв’язок (аутентифікація сторін, що беруть участь в обміні даними);

довірений маршрут/канал (для зв’язку з сервісами безпеки).

Опишемо докладніше два класи, демонструючі особливості сучасного підходу до ІБ. Клас "Пріватность" містить 4 сімейства функціональних вимог.

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

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

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

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

103

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

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

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

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

Розподіл ресурсів. Вимоги направлені на захист (шляхом вживання механізму квот) від несанкціонованої монополізації ресурсів.

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

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

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

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

3.3 Вимоги довір’я безпеці

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

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

дії розробників;

уявлення і зміст свідоцтв;

дії оцінювачів.

Всього в ОК 10 класів, 44 сімейства, 93 компоненти вимог довір’я безпеці. Перерахуємо класи:

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

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

тестування;

оцінка уязвимостей (включаючи оцінку стійкості функцій безпеки);

поставка і експлуатація;

управління конфігурацією;

керівництво (вимоги до експлуатаційної документації);

підтримка довір’я (для підтримки етапів життєвого циклу після сертифікації);

оцінка профілю захисту;

оцінка завдання по безпеці.

104

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

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

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

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

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

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

На рівні 6 реалізація повинна бути представлена в структурованому вигляді. Аналіз відповідності розповсюджується на проект нижнього рівня.

Оцінний рівень 7 (найвищий) передбачає формальну верифікацію проекту об’єкту оцінки. Він застосуємо до ситуацій надзвичайно високого ризику.

На цьому ми закінчуємо короткий огляд "Загальних критеріїв".

4 Гармонізовані критерії європейських країн

Наш виклад "Гармонізованих критеріїв" грунтується на версії 1.2, опублікованої в червні 1991 року від імені відповідних органів чотирьох країн - Франції, Німеччини, Нідерландів і Великобританії.

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

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

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

конфіденційність, цілісність, доступність.

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

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

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

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

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

105

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

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

Під коректністю розуміється правильність реалізації функцій і механізмів безпеки. В Критеріях визначається сім можливих рівнів гарантированности коректності - від E0 до E6 (в порядку зростання). Рівень E0 означає відсутність гарантированности. При перевірці коректності аналізується весь життєвий цикл об’єкту оцінки - від проектування до експлуатації і супроводу.

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

Гармонізовані критерії європейських країн з’явилися для свого часу вельми передовим стандартом, вони створили передумови для появи "Загальних критеріїв".

5 Інтерпретація "Оранжевої книги" для мережних конфігурацій

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

Впершій частині вводиться мінімум нових понять. Найважливіше з них - мережна довірена

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

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

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

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

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

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

106

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

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

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

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

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

наявність засобів нейтралізації відмов (виявлення компонентів, що відмовили, оцінка наслідків, відновлення після відмов);

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

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

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

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

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

Список літератури

84 Столлингс Вильям. Криптография и защита сетей: принципы и практика /Пер. с англ – М.: Издательский дом «Вильямс», 2001.

85Иванов М.А. Криптографические методы защиты информации в компьютерных системах и сетях.

– М.: КУДИЦ-ОБРАЗ, 2001.

86Жельников В. Криптография от папируса до компьютера. – М.: ABF, 1996.

87Бабенко Л.К. Введение в специальность «Организация и технология защиты информации». – Таганрог: Изд-во ТРТУ, 1999. –54с.

88Брюхомицкий Ю.А. Введение в информационные системы. – Таганрог: Изд-во ТРТУ, 2001. – 151 с.

89Зегжда Д.П., Ивашко А.М. Как построить защищенную информационную систему Под научной редакцией Зегжды Д.П. и Платонова В.В. – СПб: Мир и семья-95,1997. – 312 с.

90Гайкович В.Ю., Ершов Д.В. «Основы безопасности информационных технологий»

91Котухов М.М., Марков А.С. Законодательно-правовое и организационно-техническое обеспечение информационной безопасности автоматизированных систем. – 1998. – 158 с.

92Информационно-безопасные системы. Анализ проблемы: Учеб. пособие Алешин Н. В, Коэлод В. Н., Нечаев Д. А., Смирнов А. С., Сычев М. П., Пальчун Б. П., Черноруцкий И. Г., Черносвитов А. В. Под ред. В. Н. Козлова. – СПб.: Издательство С.-Петербургского, гос. техн. университета, 1996. – 69 с.

93Громов В.И., Василева Г.А. «Энциклопедия компьютерной безопасности»

107

Інформаційна безпека

Управління ризиками

План

1 Основні поняття

2 Підготовчі етапи управління ризиками

3 Основні етапи управління ризиками

1 Основні поняття

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

Взагалі кажучи, управління ризиками, рівно як і вироблення власної політики безпеки, актуальне тільки для тих організацій, інформаційні системи яких и/или оброблювані дані можна вважати нестандартними. Звичайну організацію цілком влаштує типовий набір захисних заходів, вибраний на основі уявлення про типові ризики або взагалі без жодного аналізу ризиків (особливо це вірно з формальної точки зору, в світлі проаналізованого нами раніше російського законодавства в області ІБ). Можна провести аналогію між індивідуальним будівництвом і отриманням квартири в районі масової забудови. В першому випадку необхідно прийняти безліч рішень, оформити велику кількість паперів, в другому достатньо визначитися лише з декількома параметрами. Більш детально даний аспект розглянутий в статті Сергія Симонова "Аналіз ризиків, управління ризиками" (Jet Info, 1999, 1).

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

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

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

(пері)оценка (вимірювання) ризиків;

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

ліквідація ризику (наприклад, за рахунок усунення причини);

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

ухвалення ризику (і вироблення плану дії у відповідних умовах);

переадресація ризику (наприклад, шляхом висновку угоди страховки). Процес управління ризиками можна розділити на наступні етапи:

1.Вибір аналізованих об’єктів і рівня деталізації їх розгляду.

2.Вибір методології оцінки ризиків.

3.Ідентифікація активів.

4.Аналіз загроз і їх наслідків, виявлення вразливих місць в захисті.

5.Оцінка ризиків.

6.Вибір захисних заходів.

7.Реалізація і перевірка вибраних заходів.

8.Оцінка залишкового ризику.

Етапи 6 і 7 відносяться до вибору захисних засобів (нейтралізації ризиків), інші - до оцінки

ризиків.

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

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

108

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

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

На етапі закупівлі (розробки) знання ризиків допоможе вибрати відповідні архітектурні рішення, які грають ключову роль в забезпеченні безпеки.

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

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

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

2 Підготовчі етапи управління ризиками

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

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

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

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

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

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

Одним з головних результатів процесу ідентифікації активів є отримання детальної інформаційної структури організації і способів її (структури) використовування. Ці відомості доцільно нанести на карту ІС як грані відповідних об’єктів.

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

109

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

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

3 Основні етапи управління ризиками

Етапи, передуючі аналізу загроз, можна вважати підготовчими, оскільки, строго кажучи, вони напряму з ризиками не пов’язані. Ризик з’являється там, де є загрози.

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

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

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

Після ідентифікації загрози необхідно оцінити вірогідність її здійснення. Допустимо використовувати при цьому трибальну шкалу (низька (1), середня (2) і висока (3) вірогідність).

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

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

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

Після того, як накопичені початкові дані і оцінений ступінь невизначеності, можна переходити до обробки інформації, тобто власне до оцінки ризиків. Цілком допустимо застосувати такий простий метод, як множення вірогідності здійснення загрози на передбачуваний збиток. Якщо для вірогідності і збитку використовувати трибальну шкалу, то можливих творів буде шість: 1, 2, 3, 4, 6 і 9. Перші два результати можна віднести до низького ризику, третій і четвертий - до середнього, два останніх - до високого, після чого з’являється можливість знову привести їх до трибальної шкали. За цією шкалою і

110