- •Основні теоретичні поняття криптології План
- •Основні терміни, визначення та предмет науки «криптологія»
- •Криптоаналіз
- •1 Основні терміни, визначення та предмет науки «криптологія»
- •2 Криптоаналіз
- •Контрольні запитання
- •Список літератури
- •Шифри перестановки План
- •2 Таблиці для шифрування
- •2.1 Таблиці для шифрування. Проста перестановка
- •2.2 Таблиці для шифрування. Одиночна перестановка по ключу
- •2.3 Таблиці для шифрування. Подвійна перестановка
- •2.4 Застосування магічних квадратів
- •Список літератури
- •Шифри простої заміни План
- •1 Полібіанський квадрат
- •2 Система шифрування Цезаря
- •Криптоаналіз шифру Цезаря
- •3 Аффінна система підстановок Цезаря
- •4 Система Цезаря із ключовим словом
- •5 Таблиці Трисемуса
- •Криптографічний аналіз системи одноалфавітної заміни
- •6 Біграмний шифр Плейфейра
- •7 Криптосистема Хілла
- •8 Система омофонів
- •Додаток а
- •Список літератури
- •Шифри складної заміни План
- •1 Шифр Гронсфельда
- •Криптоаналіз шифру Гронсфельда
- •2 Система шифрування Віженера
- •3 Шифр “Подвійний квадрат Уітстона”
- •4 Одноразова система шифрування
- •5 Шифрування методом Вернама
- •6 Роторні машини
- •7 Шифрування методом гамірування
- •Список літератури
- •Блочні шифри План
- •1 Алгоритм des
- •1 Алгоритм des
- •Обчислення значень ключів
- •Аналіз ефективності алгоритму des
- •Список літератури
- •Асиметричні криптосистеми План
- •Керування ключами План
- •1 Алгоритм шифрування Діффі - Хеллмана
- •Керування ключами
- •1 Алгоритм шифрування Діффі - Хеллмана
- •Контрольні питання
- •Список літератури
- •Криптографічні протоколи План
- •Контрольні запитання
- •Список літератури
- •Ідентифікація та перевірка істинності План
- •Інформаційна безпека План
- •1.2 Основні складові інформаційної безпеки
- •1.3 Важливість і складність проблеми інформаційної безпеки
- •2 Розповсюдження об’єктно-орієнтованого підходу на інформаційну безпеку.
- •2.1 Про необхідність об’єктно-орієнтованого підходу до інформаційної безпеки
- •2.2 Основні поняття об’єктно-орієнтованого підходу
- •2.3 Вживання об’єктно-орієнтованого підходу до розгляду систем, що захищаються
- •2.4 Недоліки традиційного підходу до інформаційної безпеки з об’єктної точки зору
- •2.5 Основні визначення і критерії класифікації загроз
- •Контрольні запитання
- •Список літератури
- •Інформаційна безпека Найпоширеніші загрози План
- •1 Найпоширеніші загрози доступності
- •1 Найпоширеніші загрози доступності
- •2 Деякі приклади загроз доступності
- •3 Шкідливе програмне забезпечення
- •4 Основні загрози цілісності
- •5 Основні загрози конфіденційності
- •Список літератури
- •1.2 Механізми безпеки
- •1.3 Класи безпеки
- •2 Інформаційна безпека розподілених систем. Рекомендації X.800
- •2.1 Мережні сервіси безпеки
- •2.2 Мережні механізми безпеки
- •2.3 Адміністрування засобів безпеки
- •3 Стандарт iso/iec 15408 "Критерії оцінки безпеки інформаційних технологій"
- •3.1 Основні поняття
- •3.2 Функціональні вимоги
- •3.3 Вимоги довір’я безпеці
- •4 Гармонізовані критерії європейських країн
- •5 Інтерпретація "Оранжевої книги" для мережних конфігурацій
- •Список літератури
- •Інформаційна безпека Управління ризиками План
- •2 Підготовчі етапи управління ризиками
- •3 Основні етапи управління ризиками
- •Список літератури
1.3 Класи безпеки
"критерії ..." Міністерства оборони США відкрили шлях до ранжирування інформаційних систем по ступеню довір’я безпеки.
В "Оранжевій книзі" визначається чотири рівні довір’я - D, З, B і А. Рівень D призначений для систем, визнаних незадовільними. У міру переходу від рівня З до А до систем пред’являються все більш жорсткі вимоги. Рівні З і B підрозділяються на класи (C1, C2, B1, B2, B3) з поступовим зростанням ступеня довір’я.
Всього є шість класів безпеки - C1, C2, B1, B2, B3, A1. Щоб в результаті процедури сертифікації систему можна було віднести до деякого класу, її політика безпеки і рівень гарантованності повинні задовольняти заданим вимогам, з яких ми згадаємо лише найважливіші.
Клас C1:
-
довірена обчислювальна база повинна управляти доступом іменованих користувачів до іменованих об’єктів;
-
користувачі повинні ідентифікувати себе, перш ніж виконувати які-небудь інші дії, контрольовані довіреною обчислювальною базою. Для аутентифікації повинен використовуватися який-небудь захисний механізм, наприклад паролі. Аутентифікаційна інформація повинна бути захищена від несанкціонованого доступу;
-
довірена обчислювальна база повинна підтримувати область для власного виконання, захищену від зовнішніх дій (зокрема, від зміни команд і/або даних) і від спроб стеження за ходом роботи;
-
повинні бути в наявності апаратні і/або програмні засоби, що дозволяють періодично перевіряти коректність функціонування апаратних і мікропрограмних компонентів довіреної обчислювальної бази;
-
захисні механізми повинні бути протестовані на предмет відповідності їх поведінки системної документації. Тестування повинне підтвердити, що у неавторизованого користувача немає очевидних способів обійти або поруйнувати засоби захисту довіреної обчислювальної бази;
-
повинні бути описані підхід до безпеки, що використовується виробником, і вживання цього підходу при реалізації довіреної обчислювальної бази.
Клас C2 (на додаток до C1):
-
права доступу повинні гранулюватися з точністю до користувача. Всі об’єкти повинні піддаватися контролю доступу;
-
при виділенні береженого об’єкту з пулу ресурсів довіреної обчислювальної бази необхідно ліквідовувати всі сліди його використовування;
-
кожний користувач системи винен унікальним чином ідентифікуватися. Кожна реєстрована дія повинна асоціюватися з конкретним користувачем;
-
довірена обчислювальна база повинна створювати, підтримувати і захищати журнал реєстраційної інформації, що відноситься до доступу до об’єктів, контрольованих базою;
-
тестування повинне підтвердити відсутність очевидних недоліків в механізмах ізоляції ресурсів і захисту реєстраційної інформації.
Клас B1 (на додаток до C2):
-
довірена обчислювальна база повинна управляти мітками безпеки, асоційованими з кожним суб’єктом і береженим об’єктом;
-
довірена обчислювальна база повинна забезпечити реалізацію примусового управління доступом всіх суб’єктів до всіх бережених об’єктів;
-
довірена обчислювальна база повинна забезпечувати взаємну ізоляцію процесів шляхом розділення їх адресних просторів;
-
група фахівців, що повністю розуміють реалізацію довіреної обчислювальної бази, повинна піддати опис архітектури, початкові і об’єктні коди ретельному аналізу і тестуванню;
-
повинна існувати неформальна або формальна модель політики безпеки, підтримуваною довіреною обчислювальною базою.
Клас B2 (на додаток до B1):
-
забезпечуватися мітками повинні всі ресурси системи (наприклад, ПЗП), прямо або побічно доступні суб’єктам;
-
до довіреної обчислювальної бази повинен підтримуватися довірений комунікаційний шлях для користувача, що виконує операції початкової ідентифікації і аутентифікації;
-
повинна бути передбачена можливість реєстрації подій, пов’язаних з організацією таємних каналів обміну з пам’яттю;
-
довірена обчислювальна база повинна бути внутрішньо структурована на добре певні, відносно незалежні модулі;
-
системний архітектор повинен ретельно проаналізувати можливості організації таємних каналів обміну з пам’яттю і оцінити максимальну пропускну спроможність кожного виявленого каналу;
-
повинна бути продемонстрована відносна стійкість довіреної обчислювальної бази до спроб проникнення;
-
модель політики безпеки повинна бути формальною. Для довіреної обчислювальної бази повинні існувати описові специфікації верхнього рівня, точно і повно визначаючі її інтерфейс;
-
в процесі розробки і супроводу довіреної обчислювальної бази повинна використовуватися система конфігураційного управління, що забезпечує контроль змін в описових специфікаціях верхнього рівня, інших архітектурних даних, реалізаційній документації, початкових текстах, працюючій версії об’єктного коду, тестових даних і документації;
-
тести повинні підтверджувати дієвість заходів по зменшенню пропускної спроможності таємних каналів передачі інформації.
Клас B3 (на додаток до B2):
-
для довільного управління доступом повинні обов’язково використовуватися списки управління доступом з вказівкою дозволених режимів;
-
повинна бути передбачена можливість реєстрації появи або накопичення подій, несучих загрозу політиці безпеки системи. Адміністратор безпеки повинен негайно сповіщатися про спроби порушення політики безпеки, а система, у разі продовження спроб, повинна присікати їх якнайменше хворобливим способом;
-
довірена обчислювальна база повинна бути спроектована і структурована так, щоб використовувати повний і концептуально простий захисний механізм з точно певною семантикою;
-
процедура аналізу повинна бути виконана для тимчасових таємних каналів;
-
повинна бути специфікована роль адміністратора безпеки. Одержати права адміністратора безпеки можна тільки після виконання явних, протокольованих дій;
-
повинні існувати процедури и/или механізми, що дозволяють провести відновлення після збою або іншого порушення роботи без ослаблення захисту;
-
повинна бути продемонстрована стійкість довіреної обчислювальної бази до спроб проникнення.
Клас A1 (на додаток до B3):
-
тестування повинне продемонструвати, що реалізація довіреної обчислювальної бази відповідає формальним специфікаціям верхнього рівня;
-
крім описових, повинні бути представлені формальні специфікації верхнього рівня. Необхідно використовувати сучасні методи формальної специфікації і верифікації систем;
-
механізм конфігураційного управління повинен розповсюджуватися на весь життєвий цикл і всі компоненти системи, що мають відношення до забезпечення безпеки;
-
повинно бути описано відповідність між формальними специфікаціями верхнього рівня і початковими текстами.
Така класифікація, введена в "Оранжевій книзі". Коротко її можна сформулювати так:
-
рівень З - довільне управління доступом;
-
рівень B - примусове управління доступом;
-
рівень А - верифицируемая безпека.
Звичайно, на адресу "Критеріїв ..." можна виказати цілий ряд серйозних зауважень (таких, наприклад, як повне ігнорування проблем, що виникають в розподілених системах). Проте, слід підкреслити, що публікація "Оранжевої книги" без жодного перебільшення стала епохальною подією в області інформаційної безпеки. З’явився загальновизнаний понятійний базис, без якого навіть обговорення проблем ІБ було б скрутним.
Відзначимо, що величезний ідейний потенціал "Оранжевої книги" поки багато в чому залишається незатребуваним. Перш за все це торкається концепції технологічної гарантованності, що охоплює весь життєвий цикл системи - від вироблення специфікацій до фази експлуатації. При сучасній технології програмування результуюча система не містить інформації, присутньої в початкових специфікаціях, втрачається інформація про семантику програм. Важливість даної обставини ми плануємо продемонструвати далі, в лекції про управління доступом.