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 - примусове управління доступом;

• рівень А - верифицируемая безпека.

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

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