Головна

політики безпеки

  1.  I § ??1. Поняття державної інформаційної політики
  2.  VII. ДОСЛІДЖЕННЯ, РОЗРОБКА ПОЛІТИКИ І КООРДИНАЦІЯ
  3.  А. Аналіз зовнішньої політики
  4.  Автоматизована система пожежовибухобезпеки
  5.  Адміністративна відповідальність за порушення вимог пожежної безпеки
  6.  Адміністративна відповідальність за порушення вимог промислової безпеки
  7.  Алгоритми геополітики і стратегії таємних воєн світової закуліси

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

На підставі сформульованих припущень безпеки, при обліку загроз і політик формулюються мети безпеки для ГО, спрямовані на забезпечення протистояння загрозам і виконання положень політики безпеки.

Для досягнення поставлених цілей до ГО та його середовищі пред'являються вимоги безпеки. Друга і третя частини «Загальних критеріїв» є каталоги вимог безпеки наступних типів:

· функціональні вимоги (Частина 2) - відповідають активному аспекту захисту і пред'являються до функцій безпеки ОО і реалізують їх механізмів.

· вимоги довіри (Частина 3) - пред'являються до технології та процесу розробки, експлуатації та оцінки ОО і покликані гарантувати адекватність реалізації механізмів безпеки.

При формулюванні вимог до ОО можуть бути розроблені два документа:

1. Профіль захисту - Не залежить від конкретної реалізації сукупність вимог інформаційних технологій для деякої категорії ГО. Профіль захисту (ПЗ) Неприв'язані до конкретного ГО і являє собою узагальнений стандартний набір функціональних вимог і вимог довіри для певного класу продуктів або систем. Наприклад, може бути розроблений профіль захисту на міжмережевий екран корпоративного рівня або на білінгову систему.

Саме каталог затверджених профілів захисту повинен послужити заміною традиційних керівних документів Держтехкомісії Росії.

2. Завдання з безпеки - Документ, що містить вимоги безпеки для конкретного ГО і специфікує функції безпеки і заходи довіри, пропоновані об'єктом оцінки для виконання встановлених вимог. У завданні з безпеки (ЗБ) може бути заявлено відповідність одному або декільком профілям захисту.

ЗБ можна розглядати як технічне завдання на підсистему забезпечення інформаційної безпеки для ГО.

Завдання з безпеки служить основою для проведення оцінки ОО з метою демонстрації відповідності його вимогам безпеки.

Неважко бачити, що в порівнянні з традиційними стандартами «Загальні критерії» представляють собою принципово більш гнучкий і універсальний інструмент. Однак стандарт не претендує на всеосяжну універсальність і, зокрема, має такі обмеження:

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

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

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

4. Процедури використання результатів оцінки при атестації продуктів і систем перебувають поза області дії ОК.

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

Структура і зміст профілю захисту

Структура профілю захисту наведена на рис. 3.4.3.

Мал. 3.4.3. Структура профілю захисту

введення ПЗ повинно містити інформацію управління документообігом і оглядову інформацію, необхідні для роботи з реєстром ПЗ:

· ідентифікація ПЗповинна забезпечити маркування та описову інформацію, необхідні, Щоб ідентифікувати, каталогізувати, реєструвати ПЗ і посилатися на нього;

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

опис ГО має на меті кращого розуміння його вимог безпеки і дає уявлення про тип продукту та основних характерних особливостях ІТ стосовно ГО. Опис ГО надає контекст для оцінки. Інформація, що міститься в описі ГО, буде використана в процесі оцінки для виявлення суперечностей. Оскільки ПЗ зазвичай не посилається на конкретну реалізацію, то характерні особливості ГО можуть бути представлені у вигляді припущень.

виклад безпекового середовища ГО має містити опис аспектів безпеки середовища, в якій передбачається використовувати ГО, і очікуваний спосіб його застосування. Це виклад має включати:

1. Опис припущень, Що містить аспекти безпеки середовища, в якій ГО буде використовуватися або передбачається до використання. Воно повинно включати в себе:

· Інформацію щодо передбачуваного використання ГО, включаючи такі аспекти, як передбачувана область застосування, потенційна значимість активів і можливі обмеження використання;

· Інформацію щодо середовища застосування ГО, включаючи аспекти фізичного оточення, персоналу та зовнішніх зв'язків.

2. Опис загроз, Що включає всі ті загрози активам, проти яких потрібно захист засобами ГО або його середовища. Зауважимо, що необхідно наводити не всі загрози, які можуть зустрітися в середовищі, а тільки ті з них, які впливають на безпечну експлуатацію ГО. Якщо цілі безпеки ОО слідують тільки з політики безпеки організації і припущень, то опис загроз може бути опущено.

3. Опис політики безпеки організації, Яке ідентифікує і, при необхідності, що пояснює всі положення політики безпеки організації або правила, яким повинен підкорятися об'єкт оцінки. Якщо цілі безпеки слідують тільки з загроз і припущень безпеки, опис політики безпеки організації може бути опущено.

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

Цілі безпеки для ГО повинні бути чітко викладені і зіставлені з аспектами встановлених загроз, яким необхідно протистояти засобами ГО, або з політикою безпеки організації, якій повинен відповідати ГО.

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

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

при викладі вимог безпеки ОО повинні бути визначені функціональні вимоги і вимоги довіри, яким повинні задовольняти ГО і свідоцтва підтримки його оцінки для досягнення цілей безпеки ОО.

при викладі функціональних вимог безпеки ОО слід визначати функціональні вимоги до ГО, де це можливо, як функціональні компоненти, які обираються зі частиною 2 ОК. У разі необхідності, вимоги формулюються в явному вигляді, проте при їх викладі необхідно зберігати стилістику «Загальних критеріїв».

При виборі компонентів функціональних вимог з частини 2 ОК, над ними можуть бути здійснені наступні операції:

· ітерація, Що дозволяє неодноразово використовувати компонент при різному виконанні в ньому операцій;

· призначення, Що дозволяє уточняти параметр, який встановлюється при використанні компонента;

· вибір, Що дозволяє уточняти пункти, які вибираються з переліку, наведеного в компоненті;

· уточнення, Що дозволяє здійснювати додаткову деталізацію при використанні компонента.

Вимоги довіри до безпеки ОО зазвичай формулюються як один з наведених у частині 3 ОК оціночних рівнів довіри (Оуд) - стандартних наборів вимог довіри. При цьому допускається:

· посилювати обраний рівень довіри компонентами з інших Оуд;

· Явно формулювати вимоги довіри, що не містяться в частині 3 ОК.

необов'язкове виклад вимог безпеки для середовища ІТ має визначати вимоги безпеки ІТ, яким повинна відповідати середу ІТ цього ГО. Якщо безпеку ГО не залежить від середовища ІТ, то ця частина ПЗ може бути опущена.

Хоча вимоги безпеки середовища, що не відносяться до ІТ, часто бувають корисні на практиці, не потрібно, щоб вони були формальною частиною ПЗ, оскільки вони не пов'язані безпосередньо з реалізацією ГО.

розділ ПЗ Зауваження по застосуванню є необов'язковим і може містити додаткову інформацію, яка вважається доречною або корисної для створення, оцінки та використання ГО.

обгрунтування ПЗ підтримує твердження про те, що ПЗ є повною і взаємозалежної сукупністю вимог, і що відповідний йому ГО забезпечить ефективний набір контрзаходів безпеки ІТ в певному середовищі безпеки. обгрунтування повинно включати:

· логічне обгрунтування цілей безпеки, Яке демонструє, що викладені цілі безпеки зіставлені з усіма ідентифікованими аспектами середовища безпеки ОО і придатні для їх охоплення;

· логічне обгрунтування вимог безпеки, Яке демонструє, що сукупність вимог безпеки ОО і його середовища придатна для досягнення цілей безпеки і порівнянна з ними.

при викладі логічного обґрунтування вимог безпеки має бути продемонстровано наступне:

1. Поєднання окремих компонентів функціональних вимог і вимог довіри для ГО та його середовища ІТ в цілому несе викладеним цілям безпеки.

2. Даний набір вимог безпеки утворює єдине і внутрішньо несуперечливе ціле. Зокрема, повинні бути задоволені всі існуючі залежно між функціональними вимогами.

3. Вибір вимог безпеки строго обгрунтований. Кожне з перерахованих нижче умов має бути строго обгрунтовано:

· Вибір вимог, які не містяться в частинах 2 або 3 ОК;

· Вибір вимог довіри, які не включені в будь-якої Оуд;

· Випадки незадоволення залежностей.

4. Обраний для ПЗ рівень стійкості функцій і заявлена ??в явному вигляді стійкість функцій узгоджуються з цілями безпеки для ГО.

Структура і зміст завдання з безпеки

Структура завдання з безпеки приведена на рис. 3.4.4. В цілому структура ЗБ аналогічна ПЗ, всі зміни пов'язані з включенням інформації, що відноситься до специфіки реалізації конкретного ГО.

Мал. 3.4.4. Структура завдання з безпеки

В цілому ЗБ має бути оформлено як документ, максимально орієнтований на користувача - з мінімумом посилань на зовнішні матеріали.

розділ відповідність ОК повинен містити всі піддаються оцінці твердження про відповідність ГО Загальним критеріям. Такі твердження можуть звучати так:

· відповідність частини 2, Якщо в ЗБ при викладі функціональних вимог безпеки використовуються виключно компоненти з частини 2 ОК;

· розширення частини 2, Якщо в виклад функціональних вимог включені компоненти, відсутні в частині 2 ОК;

· відповідність частини 3, Якщо вимоги довіри представлені у вигляді Оуд з частини 3 ОК або пакета вимог довіри, що включає тільки компоненти довіри з частини 3 ОК;

· посилення частини 3, Якщо вимоги довіри представлені у вигляді Оуд або пакета вимог довіри і включають інші компоненти довіри з частини 3 ОК.

· розширення частини 3, Якщо вимоги довіри представлені у вигляді Оуд, доповненого вимогами довіри не з частини 3 ОК, або пакета вимог довіри, який включає вимоги довіри, що не містяться в частині 3 ОК або повністю складається з них.

· відповідність ПЗ - ГО відповідає ПЗ тільки в тому випадку, якщо він відповідає всім частинам цього ПЗ.

Коротка специфікація ГО повинна визначити відображення вимог безпеки для ГО. Ця специфікація повинна надати опис функцій безпеки і заходів довіри до ГО, які відповідають вимогам безпеки ОО.

Коротка специфікація повинна включати:

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

Функції безпеки ІТ повинні бути визначені неформальним чином на рівні деталізації, необхідному для розуміння їх призначення. Всі номери в ЗБ на механізми безпеки повинні бути співставлені з відповідними функціями безпеки так, щоб було видно, які механізми безпеки використовуються при реалізації кожної функції.

2. Виклад заходів довіри, Яке повинно специфікувати заходи довіри до ГО, заявлені для задоволення викладених вимог довіри. Заходи довіри повинні бути співставлені з вимогами таким чином, щоб було зрозуміло, які заходи в задоволенні яких вимог беруть участь

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

В твердження про відповідність ПЗ включаються матеріали, необхідні для підтвердження факту відповідності.

Якщо зроблено твердження про відповідність одному або декільком ПЗ, то виклад тверджень про відповідність має містити наступний матеріал для кожного ПЗ:

· Посилання на ПЗ, Що ідентифікує ПЗ, відповідність яким стверджується, плюс будь-які додаткові матеріали, які можуть бути необхідними відповідно до цим твердженням. Обгрунтоване твердження про відповідність має на увазі, що ГО відповідає всім вимогам ПЗ.

· конкретизацію ПЗ, Що ідентифікує ті вимоги безпеки ІТ, в яких виконуються операції, дозволені в ПЗ, або додатково уточнюються вимоги ПЗ.

· доповнення ПЗ, Яке ідентифікує цілі і вимоги безпеки ОО, які доповнюють цілі і вимоги ПЗ.

Випадок, коли в ЗБ затверджується про часткове відповідно ПЗ, не прийнятний для оцінки в рамках ОК.

Логічне обгрунтування короткої специфікації ГО показує, що функції безпеки і заходи довіри до ГО придатні, щоб відповідати вимогам безпеки ОО. Повинно бути продемонстровано наступне:

· Поєднання специфіковані для ГО функцій безпеки ІТ при спільному використанні задовольняє функціональним вимогам безпеки ГО;

· Справедливі зроблені твердження про стійкості функцій безпеки ОО або заяву, що в таких твердженнях немає необхідності;

· Суворо обґрунтоване твердження, що викладені заходи довіри відповідають вимогам довіри.

Рівень деталізації логічного обгрунтування повинен відповідати рівню деталізації визначення функцій безпеки.

Логічне обгрунтування тверджень про відповідність ПЗ пояснює будь-які відмінності між цілями і вимогами безпеки ЗБ і будь-якого ПЗ, відповідність яким затверджується. Ця частина ЗБ може бути опущена, якщо не зроблено тверджень про відповідність ПЗ, або якщо цілі і вимоги безпеки ЗБ і кожного ПЗ, відповідність яким стверджується, повністю збігаються.

 



 Вступ |  Функціональні вимоги безпеки

 Політика безпеки |  гарантії |  II. Група C - дискреционная захист. |  Керівні документи Держтехкомісії Росії |  Основні положення концепції захисту ЗОТ і АС від несанкціонованого доступу до інформації |  Засоби обчислювальної техніки. Захист від несанкціонованого доступу до інформації. |  Автоматизовані системи. Захист від несанкціонованого доступу до інформації. Класифікація АС і вимоги щодо захисту інформації |  Підсистема управління доступом |  Засоби обчислювальної техніки. Міжмережеві екрани. Захист від несанкціонованого доступу. |  Частина 1. Програмне забезпечення засобів захисту інформації. Класифікація за рівнем контролю відсутності декларованих можливостей |

© um.co.ua - учбові матеріали та реферати