Файл: Опорный конспект.pdf

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

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

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

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

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

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

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

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

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

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