Багаторівнева безпека

Операційне середовище MLS часто потребує високонадійної системи обробки інформації, яка часто побудована на операційній системі MLS (ОС), але не обов’язково. Більшість функціональних можливостей MLS може підтримуватися системою, яка повністю складається з ненадійних комп’ютерів, хоча для цього потрібні кілька незалежних комп’ютерів, пов’язаних за допомогою каналів, що відповідають вимогам безпеки (див. розділ B.6.2 Інтерпретації довірених мереж, NCSC-TG-005). Прикладом апаратного забезпечення MLS є асиметрична ізоляція[1]. Якщо один комп’ютер використовується в режимі MLS, то цей комп’ютер повинен використовувати надійну операційну систему (ОС). Оскільки вся інформація в середовищі MLS є фізично доступною для ОС, повинні існувати сильні логічні засоби контролю, щоб забезпечити суворий контроль доступу до інформації. Зазвичай це передбачає обов’язковий контроль доступу, який використовує мітки безпеки, такі як наприклад модель Бела–ЛаПадули.

Клієнти, які встановлюють надійні операційні системи, зазвичай вимагають, щоб продукт завершив офіційну оцінку безпеки комп’ютера. Оцінка є суворішою для більш широкого діапазону безпеки, який є найнижчим і найвищим рівнями класифікації, які може обробляти система. Критерії оцінки надійної комп’ютерної системи (TCSEC) були першими критеріями оцінки, розробленими для оцінки MLS в комп’ютерних системах. Відповідно до цих критеріїв існувало чітке уніфіковане зіставлення між вимогами безпеки та широтою діапазону безпеки MLS[2]. Історично невелика кількість реалізацій було сертифіковано для обробки MLS з діапазоном безпеки від Несекретно через Цілком таємно. Серед них були Honeywell SCOMP, USAF SACDIN, NSA Blacker і Boeing MLS LAN, всі під TCSEC, 1980-х років і на основі Intel 80386 . Наразі продукти MLS оцінюються за Загальними критеріями . Наприкінці 2008 року перша операційна система (докладніше нижче) була сертифікована на високий рівень гарантії оцінки: Evaluation Assurance Level (EAL) - EAL 6+ / High Robustness, під егідою урядової програми США, яка вимагає багаторівневої безпеки в умовах високої загрози. середовище. Хоча цей рівень впевненості має багато подібності зі старою Orange Book A1 (наприклад, формальні методи), функціональні вимоги зосереджені на принциповій ізоляції та політиці потоку інформації, а не на політиці вищого рівня, як-от Bell-La Padula. Оскільки Загальні критерії відокремлювали поєднання впевненості (EAL) і функціональності (Профіль захисту), чітке уніфіковане відображення між вимогами безпеки та можливостями діапазону безпеки MLS, задокументовані в CSC-STD-004-85, було значною мірою втрачено, коли Загальні критерії замінили Серія Веселка .

Вільно доступні операційні системи з деякими функціями, які підтримують MLS, включають Linux з увімкненою функцією Security-Enhanced Linux і FreeBSD. [3] Раніше вважалося, що оцінка безпеки є проблемою для цих безкоштовних реалізацій MLS з трьох причин:

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

Незважаючи на такі припущення, Red Hat Enterprise Linux 5 був сертифікований відповідно до LSPP, RBACPP та CAPP на EAL4+ у червні 2007 року [4] Він використовує Security-Enhanced Linux для впровадження MLS і був першою сертифікацією Common Criteria для забезпечення властивостей безпеки TOE з Security-Enhanced Linux.

Стратегії сертифікації постачальників можуть ввести в оману неспеціалістів. Звичайна стратегія використовує надмірну увагу неспеціалістів на рівні EAL із надмірною сертифікацією, як-от сертифікація профілю захисту EAL 3 (наприклад, CAPP) [5] на підвищених рівнях, наприклад EAL 4 або EAL 5. Іншим є додавання та сертифікація функцій підтримки MLS (таких як профіль захисту контролю доступу на основі ролей (RBACPP) і позначений профіль захисту безпеки (LSPP)) до ядра, яке не оцінюється як профіль захисту, що підтримує MLS. Ці типи функцій є службами, які працюють на ядрі і залежать від ядра, щоб захистити їх від пошкодження та підривної діяльності. Якщо ядро не оцінено як профіль захисту, що підтримує MLS, функціям MLS не можна довіряти, незалежно від того, наскільки вражаюче виглядає демонстрація. Особливо варто відзначити, що CAPP спеціально не є профілем MLS, оскільки він спеціально виключає можливості самозахисту, критичні для MLS.

General Dynamics пропонує PitBull, надійну операційну систему MLS[6]. Наразі PitBull пропонується лише як розширена версія Red Hat Enterprise Linux, але попередні версії існували для Sun Microsystems Solaris, IBM AIX та SVR4 Unix. PitBull надає механізм безпеки Bell LaPadula, механізм цілісності Biba, заміну привілеїв для суперкористувача та багато інших функцій. PitBull має базу безпеки для продукту General Dynamics Trusted Network Environment (TNE) з 2009 року. TNE забезпечує багаторівневий обмін інформацією та доступ для користувачів у Міністерстві оборони та розвідувальних спільнотах, які працюють на різних рівнях класифікації. Це також основа для багаторівневої коаліції, розширеної системи збору та експлуатації інформації Battlefield [7] (BICES-X).

Sun Microsystems, тепер Oracle Corporation, пропонує Solaris Trusted Extensions як інтегровану функцію комерційних ОС Solaris і OpenSolaris . На додаток до профілю захисту контрольованого доступу (CAPP) і профілів захисту доступу на основі ролей (RBAC), довірені розширення також були сертифіковані в EAL4 на маркований профіль захисту безпеки (LSPP). [8] Ціль безпеки включає як настільні, так і мережеві функції. LSPP передбачає, що користувачі не мають права замінювати політику маркування, яка застосовується ядром і X Window System (сервер X11). Оцінка не включає аналіз прихованого каналу . Оскільки ці сертифікати залежать від CAPP, жодні сертифікати Common Criteria не свідчать про те, що цей продукт є надійним для MLS.

BAE Systems пропонує з «високою впевненістю» комерційну систему XTS-400, яка підтримує MLS. Попередні продукти (включаючи XTS-300) були оцінені на рівні TCSEC B3, який підтримує MLS. XTS-400 був оцінений за загальними критеріями на EAL5+ щодо профілів захисту CAPP та LSPP. CAPP і LSPP обидва є профілями захисту EAL3, які за своєю суттю не підтримують MLS, але ціль безпеки [9] для оцінки цього продукту за загальними критеріями містить розширений набір функцій безпеки, які забезпечують можливість MLS.

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

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

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

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

Більшості обходу можна уникнути. Уникнення обходу часто виникає, коли архітектори системи проектують систему, перш ніж правильно розглянути питання безпеки, а потім намагаються застосувати безпеку як додаткові функції. У цій ситуації обхід є єдиним легким способом змусити систему працювати. Запропоновано і схвалено деякі псевдобезпечні схеми, які досліджують вміст обхідних даних у марній спробі встановити, що обхідні дані не містять секретів. Це неможливо без довіри до чогось щодо даних, таких як їх формат, що суперечить припущенню, що джерело не є довіреним для збереження будь-яких характеристик вихідних даних. Гарантований «безпечний обхід» є міфом, так само як так звана охорона високої впевненості (HAG), яка прозоро реалізує обхід. Ризик, який вони представляють, давно визнаний; існуючі рішення в кінцевому рахунку є процедурними, а не технічними. Немає способу з упевненістю дізнатися, скільки секретної інформації береться з наших систем шляхом використання обходу.

Зменшується кількість експертів COMPUSEC , а термін MLS був перевантажений. Неспеціалісти розробляють безпечні обчислювальні системи і роблять висновок, що MLS не існує. Ці два види використання: MLS як середовище обробки проти MLS як можливість. Впевненість, що MLS не існує, ґрунтується на переконанні, що не існує продуктів, сертифікованих для роботи в середовищі або в режимі MLS, і, отже, MLS як можливості не існує. Одне не означає іншого. Багато систем працюють у середовищі, що містить дані, які мають неоднакові рівні безпеки і, отже, є MLS за теоремою про проміжне значення комп’ютерної безпеки (CS-IVT). [10] Наслідки цієї плутанини глибші. Операційні системи, бази даних і мережі MLS, сертифіковані АНБ, існували в робочому режимі з 1970-х років, і продукти MLS продовжують створювати, продавати та впроваджувати.

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

• MLS як середовище безпеки або режим безпеки : спільнота, чиї користувачі мають різні дозволи безпеки, може сприймати MLS як можливість обміну даними: користувачі можуть ділитися інформацією з одержувачами, чиє дозвіл дозволяє отримувати цю інформацію. Система працює в режимі MLS, коли вона має (або може мати) підключення до місця призначення, яке очищено до нижчого рівня безпеки, ніж будь-які дані, які містить система MLS. Це формалізовано в CS-IVT. Визначення режиму безпеки системи повністю залежить від середовища безпеки системи; класифікація даних, які вона містить, дозвіл тих, хто може отримати прямий або непрямий доступ до системи або її виходів чи сигналів, а також підключення та порти системи до інших систем. Режим безпеки не залежить від можливостей, хоча система не повинна працювати в режимі, для якого вона не заслуговує довіри.
• MLS як можливість : розробники продуктів або систем, призначених для обміну даними MLS, як правило, погано сприймають це з точки зору можливості застосування обмежень обміну даними або політики безпеки, як-от механізми, які застосовують модель Белла-ЛаПадули . Система підтримує MLS, якщо можна продемонструвати, що вона надійно реалізує політику безпеки.

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

Незалежні рівні безпеки (MILS) — це архітектура, яка розглядає компонент розділення домену MLS. Зауважте, що UCDMO (керівник уряду США з міждоменних і багаторівневих систем) створив термін міждоменний доступ як категорію у своїй базовій лінії систем, акредитованих Міністерством оборони та розвідувальної спільноти, і цю категорію можна розглядати як по суті аналогію MILS.

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

Підхід MILS дотримується стратегії, що характеризується старішим терміном, MSL ( кілька одинарних рівнів ), який ізолює кожен рівень інформації у своєму власному однорівневому середовищі ( System High ).

Жорстка комунікація та ізоляція процесу, які пропонує MILS, можуть бути кориснішими для програмних додатків надзвичайно високої надійності, ніж MLS. MILS, зокрема, не розглядає ієрархічну структуру, яка втілена поняттям рівнів безпеки. Для цього потрібно додати спеціальні програми імпорту/експорту між доменами, кожен з яких має бути належним чином акредитований. Таким чином, MILS можна було б краще назвати кількома незалежними доменами безпеки (емуляція MLS на MILS вимагала б аналогічного набору акредитованих додатків для додатків MLS). Відмовляючись від нестандартної взаємодії між рівнями, що відповідає ієрархічним відносинам Белла-Ла Падули, MILS спочатку (майже оманливо) простий у реалізації, але потребує нетривіальних додаткових програм імпорту/експорту для досягнення багатства та гнучкості, очікуваних від практичні програми MLS.

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

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

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

У 2009 році на симпозіумі NSA Information Assurance UCDMO провів доріжку, спеціально присвячену MLS, на якій виділила кілька акредитованих (у виробництві) та нових систем MLS. Особливу увагу було приділено на використання MLS в SELinux. [11]

Існує кілька баз даних, які класифікуються як системи MLS. Oracle має продукт під назвою Oracle Label Security (OLS), який реалізує обов’язковий контроль доступу – зазвичай шляхом додавання стовпця «мітка» до кожної таблиці в базі даних Oracle [12]. OLS розгортається в INSCOM армії США як основа розвідувальної бази даних з усіх джерел, що охоплює мережі JWICS і SIPRNet. Існує проект створення міченої версії PostgreSQL, а також є старіші реалізації міченої бази даних, наприклад Trusted Rubix . Ці системи баз даних MLS забезпечують уніфіковану внутрішню систему для вмісту, що охоплює декілька міток, але вони не вирішують проблему, пов’язану з тим, що користувачі обробляють вміст на кількох рівнях безпеки в одній системі, одночасно забезпечуючи обов’язковий контроль доступу.

Існує також кілька програм для кінцевих користувачів MLS. Інша функція MLS, яка зараз є базовою у UCDMO, називається MLChat, і це чат-сервер, який працює на операційній системі XTS-400 — його створила Дослідницька лабораторія ВМС США . Враховуючи, що вміст від користувачів із різних доменів проходить через сервер MLChat, для захисту секретного вмісту використовується сканування брудних слів, і точилися дебати щодо того, чи це справді система MLS чи більше форма захисту даних міждоменного передачі . . Обов'язковий контроль доступу підтримується комбінацією XTS-400 і механізмів, що стосуються конкретної програми.

Joint Cross Domain eXchange (JCDX) є ще одним прикладом можливостей MLS, які зараз в UCDMO базовий рівень. JCDX є єдиною системою управління, управління, зв’язку, комп’ютерів та розвідки (C4I), акредитованою Міністерством оборони (DoD), Агентством оборонної розвідки (DIA), яка забезпечує розвідку та попереджувальну підтримку на театрі та передовій. розгорнуті тактичні командири. Архітектура JCDX всебічно інтегрована із захищеною операційною системою високого рівня захисту четвертого рівня (PL4), яка використовує маркування даних для поширення інформації майже в реальному часі про діяльність сил і потенційних терористичних загроз у світовому океані та навколо нього. Він встановлений у Сполучених Штатах Америки та країнах-партнерах Альянсу, де він здатний надавати дані від абсолютно секретного/SCI до рівня секретного доступу, і все це на одній платформі.

Програми MLS, які наразі не входять до базової лінії UCDMO, включають кілька програм від BlueSpace . BlueSpace має кілька програм MLS, включаючи клієнт електронної пошти MLS, пошукову програму MLS і систему MLS C2. BlueSpace використовує стратегію проміжного програмного забезпечення, щоб дозволити своїм додаткам бути нейтральними до платформи, організовуючи один інтерфейс користувача для кількох екземплярів ОС Windows ( віртуалізовані або віддалені термінальні сеанси ). Дослідницька лабораторія військово-морських сил США також впровадила багаторівневу структуру веб-додатків під назвою MLWeb, яка інтегрує фреймворк Ruby on Rails з багаторівневою базою даних на базі SQLite3 .

Одна з найбільших змін, яка сьогодні відбувається на арені багаторівневої безпеки, — це зближення MLS з віртуалізацією. Все більше надійних операційних систем відходить від маркування файлів і процесів і переходить до контейнерів UNIX або віртуальних машин. Приклади включають зони в Solaris 10 TX і гіпервізор з додатковими елементами в таких системах, як платформа Integrity Green Hill і XenClient XT від Citrix. Іншим прикладом є платформа високої надійності від NSA, яка реалізована в довіреному середовищі віртуалізації General Dynamics (TVE) — вона використовує SELinux у своїй основі і може підтримувати програми MLS, які охоплюють декілька доменів.

• Модель Белла-ЛаПадули
• Модель Biba, модель цілісності Biba
• Модель Кларка-Вілсона
• Дискреційний контроль доступу (DAC)
• Рівень гарантії оцінки (EAL)
• Модель Грема-Денінга
• Обов'язковий контроль доступу (MAC)
• Безпека кількох категорій (MCS)
• Багатофакторна аутентифікація
• Модель невтручання (безпеки).
• Контроль доступу на основі ролей (RBAC)
• Охоронні режими роботи
• Системний високий режим
• Модель Take-grant

1. Davidson, J.A. (9 грудня 1996). Asymmetric isolation. Computer Security Applications Conference. с. 44–54. ISBN 978-0-8186-7606-2. doi:10.1109/CSAC.1996.569668.
2. CSC-STD-004-85: Computer Security Requirements - Guidance For Applying The Department Of Defense Trusted Computer System Evaluation Criteria In Specific Environments (25 June 1985)
3. Multi-Level Security confidentiality policy in FreeBSD
4. Validated Product - Red Hat Enterprise Linux Version 5 running on IBM Hardware. National Information Assurance Partnership, Common Criteria Evaluation and Validation Scheme, United States. June 7, 2007.
5. Controlled Access Protection Profile (CAPP)
7. Corrin, Amber (8 серпня 2017). How BICES-X facilitates global intelligence. C4ISRNET (амер.). Процитовано 10 грудня 2018.
8. Solaris 10 Release 11/06 Trusted Extensions. Communications Security Establishment Canada. 11 червня 2008. Архів оригіналу за 17 червня 2011. Процитовано 26 червня 2010.
9. Security Target, Version 1.22 for XTS-400, Version 6.4.U4. National Information Assurance Partnership, Common Criteria Evaluation and Validation Scheme, United States. 1 червня 2008. Архів оригіналу за 23 липня 2011. Процитовано 11 серпня 2010.
10. David Elliott Bell: Looking Back at the Bell–LaPadula model (December 7, 2005)
11. For example: Petersen, Richard (2011). Fedora 14 Administration and Security. Surfing Turtle Press. с. 298. ISBN 9781936280223. Процитовано 13 вересня 2012. «The SELinux reference policy [...] Multi-level security (MLS) adds a more refined security access method. MLS adds a security level value to resources.»
12. Oracle.

• (він же TCSEC або «Помаранчева книга»).
• (він же TNI або «Червона книга»).
• .
• П. А. Лоскокко, С. Д. Смоллі, П. А. Мукельбауер, Р. К. Тейлор, С. Дж. Тернер і Дж. Ф. Фаррелл. Неминучість збою: помилкове припущення безпеки в сучасних обчислювальних середовищах . У матеріалах 21-ї національної конференції з безпеки інформаційних систем, сторінки 303–314, жовтень 1998 р. .

• Перший RTOS Integrity 178B сертифікований для підтримки MILS
• ЦІСНІСТЬ 178B продукт Сторінка
• Надійна операційна система PitBull