Стандарти безпеки

OSEK

ARINC-653

DO-178B

Стандарт DO-178B, створений Радіотехнічною комісією з аеронавтики (RTCA, Radio Technical Commission for Aeronautics) для розробки ПО бортових авіаційних систем. Перша його версія була прийнята в 1982 р., друга (DO-178A) - в 1985-му, потім DO-178B - в 1992 р. Готується прийняття нової версії, DO-178C. Стандартом передбачено п'ять рівнів серйозності відмови, і для кожного з них визначений набір вимог до програмного забезпечення, які повинні гарантувати працездатність всієї системи в цілому при виникненні відмов даного рівня серйозності

Даний стандарт визначає наступні рівні сертифікації:

• А (катастрофічний),
• В (небезпечний),
• С (істотний),
• D (несуттєвий)
• Е (не впливає).

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

Стандарт ARINC-653 (Avionics Application Software Standard Interface) розроблений компанією ARINC в 1997 р. Цей стандарт визначає універсальний програмний інтерфейс APEX (Application/Executive) між ОС авіаційного комп'ютера й прикладним ПО. Вимоги до інтерфейсу між прикладним ПО й сервісами операційної системи визначаються таким чином, щоб дозволити прикладному ПО контролювати диспетчеризацію, зв'язок і стан внутрішніх оброблюваних елементів. В 2003 р. прийнята нова редакція цього стандарту. ARINC-653 у якості одного з основних вимог для ОСРЧ в авіації вводить архітектуру ізольованих (partitioning) віртуальних машин.

Стандарт OSEK/VDX є комбінацією стандартів, які споконвічно розроблялися у двох окремих консорціумах, що згодом злилися. OSEK бере сво. назву від німецького акроніма консорціуму, до складу якого входили провідні німецькі виробники автомобілів - BMW, Bosch, Daimler Benz (тепер Daimler Chrysler), Opel, Siemens і Volkswagen, а також університет у Карлсруе (Німеччина). Проект VDX (Vehicle Distributed eXecutive) розвивався спільними зусиллями французьких компаній PSA і Renault. Команди OSEK і VDX злилися в 1994р.

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

Стандарт OSEK/VDX складається із трьох частин - стандарт для операційної системи (OS), комунікаційний стандарт (COM) і стандарт для мережного менеджера (NM). На додаток до цих стандартів визначається якась реалізаційна мова (OIL). Першим компонентом стандарту OSEK є стандарт для ОС, тому часто стандарт OSEK помилково сприймається як стандарт ОСРЧ. Хоча ОС і є більша порція даного стандарту, потужність його складається в інтеграції всіх його компонентів.

У зв'язку зі стандартами для ОСРЧ варто відзначити широко відомий стандарт критеріїв оцінки придатності комп'ютерних систем (Trusted Computer System Evaluation Criteria - TCSEC). Цей стандарт розроблений Міністерством оборони США й відомий також за назвою "Жовтогаряча книга" (Orange Book - через колір обкладинки).

У ряді інших країн були розроблені аналогічні критерії, на основі яких був створений міжнародний стандарт “Загальні критерії оцінки безпеки інформаційних технологій” (далі просто - Загальні критерії) (Common Criteria for IT Security Evaluation, ISO/IEC 15408).

В "Жовтогарячій книзі" перераховані сім рівнів захисту:

• А1 - верифікована розробка. Цей рівень вимагає, щоб захист секретної й іншої критичної інформації засобами керування безпекою гарантували методи формальної верифікації.
• В3 - домени безпеки. Цей рівень призначений для захисту систем від досвідчених програмістів.
• В2 - структурований захист. У систему із цим рівнем захисту не можна допустити проникнення хакерів.
• В1 - мандатний контроль доступу. Захист цього рівня, можливо, удасться перебороти досвідченому хакеру, але ніяк не рядовим користувачам.
• С2 - дискреційний контроль доступу. Рівень ІС2 забезпечує захист процедур входу, дозволяє робити контроль за подіями, що мають відношення до безпеки, а також ізолювати ресурси.
• С1 - вибірний захист. Цей рівень дає користувачам можливість захистити особисті дані або інформацію про проект, встановивши засоби керування доступом.
• D - мінімальний захист. Цей нижній рівень захисту залишений для систем, які проходили тестування, але не змогли задовольнити вимогам більше високого класу.

Що стосується Загальних критеріїв, то в них введені схожі вимоги забезпечення безпеки у вигляді оцінних рівнів (Evaluation Assurance Levels - EAL). Їх також сім:

• EAL7 - найвищий рівень припускає формальну верифікацію моделі об'єкта оцінки. Він застосовний до систем дуже високого ризику.
• EAL6 визначається, як напівформально верифікований і протестований. На рівні EAL6 реалізація повинна бути представлена в структурованому виді, аналіз відповідності поширюється на проект нижнього рівня, проводиться строгий аналіз покриття, аналіз і тестування небезпечних станів.
• EAL5 визначається, як напівформально спроектований і протестований. Він передбачає створення напівформальної функціональної специфікації й проекту високого рівня з демонстрацією відповідності між ними, формальної моделі політики безпеки, стандартизованої моделі життєвого циклу, а також проведення аналізу схованих каналів.
• EAL4 визначається, як методично спроектований, протестований і переглянутий. Він припускає наявність автоматизації керування конфігурацією, повної специфікації інтерфейсів, описового проекту нижнього рівня, підмножини реалізацій функцій безпеки, неформальної моделі політики безпеки, моделі життєвого циклу, аналіз валідації, незалежний аналіз вразливостей. Цілком ймовірно, це найвищий рівень, якого можна досягти на даному етапі розвитку технології програмування із прийнятними витратами.
• EAL3 визначається, як методично протестований і перевірений. На рівні EAL3 здійснюється більше повне, чим на рівні EAL2, тестування покриття функцій безпеки, а також контроль середовища розробки й керування конфігурацією об'єкта оцінки.
• EAL2 визначається, як структурно протестований. Він передбачає створення описового проекту верхнього рівня об'єкта оцінки, опис процедур інсталяції й поставки, методик адміністратора й користувача, функціональне й незалежне тестування, оцінку міцності функцій безпеки, аналіз вразливості розроблювачами.
• EAL1 визначається, як функціонально протестований. Він забезпечує аналіз функцій безпеки з використанням функціональної специфікації й специфікації інтерфейсів, що керує документації, а також незалежне тестування. На цьому рівні погрози не розглядаються як серйозні.

Відповідно до вимог Загальних критеріїв, продукти певного класу (наприклад, операційні системи) оцінюються на відповідність ряду функціональних критеріїв і критеріїв довіри - профілів захисту. Існують різні визначення профілів захисту відносно операційних систем, брандмауерів, смарт-карт і інших продуктів, які повинні відповідати певним вимогам в області безпеки. Наприклад, профіль захисту систем з розмежуванням доступу (Controlled Access Protection Profile) діє відносно операційних систем і покликаний замінити старий рівень захисту С2, що визначався відповідно до американського стандарту TCSEC. Відповідно до оцінних рівнів довіри сертифікація на відповідність більш високому рівню означає більш високий ступінь впевненості в тому, що система захисту продукту працює правильно й ефективно, і, відповідно до умов Загальних критеріїв, рівні 5-7 розраховані на тестування продуктів, створених із застосуванням спеціалізованих технологій безпеки.

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

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

Дата добавления: 2013-12-14