Главная страница
Навигация по странице:

  • РОЗДІЛ 3 АНАЛІЗ ВИМОГ ДО ЗАСОБІВ КЗІ, ЩО ВИКЛАДЕНІ В НОРМАТИВНИХ ДОКУМЕНТАХ РОСІЙСЬКОЇ ФЕДЕРАЦІЇ

  • 3.1 Система нормативної документації Російської Федерації в області захисту інформації від несанкціонованого доступу

  • 3.2 Класифікація рівнів захищеності від НСД до інформації У нормативному документі [3] встановлюється сім класів захищеності

  • Вимоги до показників захищеності

  • Найменування показника

  • 19 мон ГЮІ 2015. 1. 9 Вимоги та їх реалізація при побудування засобів криптографічного захисту інформації


    Скачать 227.06 Kb.
    Название1. 9 Вимоги та їх реалізація при побудування засобів криптографічного захисту інформації
    Дата11.01.2022
    Размер227.06 Kb.
    Формат файлаdocx
    Имя файла19 мон ГЮІ 2015.docx
    ТипДокументы
    #328148
    страница25 из 29
    1   ...   21   22   23   24   25   26   27   28   29

    Висновки за 2 розділ





    1. Версія 2012-08-15 Міжнародний стандарт ISO/IEC 19790, є суттєво переробленою версією міжнародного версії 2005-03-30. В ньому передбачено чотири наростаючі, якісні рівні вимог безпеки, що призначені для покриття широкого спектру потенційних застосувань і середовищ. Причому криптографічні методи та механізми однакові для всіх чотирьох рівнів безпеки. Вимоги безпеки стандарту охоплюють галузі специфікації криптографічних модулів; інтерфейси криптографічних модулів; ролі, послуги і автентифікація; безпека програмного / програмно-апаратного забезпечення; експлуатаційне середовище, фізична безпека; неінвазивна безпека; управління чутливими параметрами безпеки; самотестування; гарантії життєвого циклу, а також відбиття інших атак.

    2. Вимоги відносно криптографічного захисту можуть бути різними в залежності від застосувань. Рівень безпеки повинні визначати організації, знаючи свої інформаційні ресурси, їх конфіденційність та потенційні втрати. Засоби контролю рівня безпеки, як правило, можуть включати: фізичні  та експлуатаційні засоби; програмні розробки; резервне  планування і планування надзвичайних обставин; засоби управління інформацією та даними. Але рівні безпеки залежать від ефективності адміністрування, відповідних політик і процедур захисту в межах середовища експлуатації.

    3. Кожна з версій версії міжнародного стандарту ISO/IEC 19790 2005-03-30 та ISO/IEC 19790 2012-08- 15 містять достатньо повний перелік визначень та понять. Але, на наш погляд, більш детальною та повною є версія ISO/IEC 19790 2012-08- 15. На її основі запропоновано визначень для національного нормативного документу, що розробляється, вибрані 41 визначення та поняття є достатніми для національного нормативного документу.

    4. Міжнародний стандарт ISO/IEC 19790, версія 2012-08-15 встановлює вимоги, що спрямовані на підтримання безпеки, що забезпечується криптографічним модулем, але відповідність стандарту не є достатньою умовою, щоб гарантувати, що конкретний модуль є безпечним, або що безпека, забезпечувана модулем, є достатньою і прийнятною для власника інформації, яка захищається.

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

    6. На 4 рівні безпеки необхідно виконувати вимогу багатофакторної автентифікації оператора. Як мінімум, це вимагає двох з трьох наступних атрибутів:

    • щось, що ви знаєте, наприклад, секретний пароль,

    • щось, чим ви володєте, наприклад, фізичний ключ або токен,

    • фізичні властивості, наприклад, біометрика.

    1. Вимоги до безпеки охоплюють області, що пов'язані з розробкою і випуском криптографічних модулів. До таких областей відносяться специфікації криптографічних модулів; інтерфейси криптографічних модулів; ролі, послуги і автентифікація; безпека програмного/програмно-апаратного забезпечення; експлуатаційне середовище, фізична безпека; неінвазивна безпеки; управління чутливими параметрами безпеки; самотестування; гарантії життєвого циклу, а також відбиття інших атак. У таблиці 2.2.1 наведені вимоги безпеки в кожній з цих областей. Криптографічний модуль повинен бути протестований на відповідність вимогам по кожній області, розглянутій в цьому розділі. Крім того, криптографічний модуль повинен бути незалежно оцінений по кожній області. Також, на додаток до отримання незалежної оцінки по кожній з областей безпеки, криптографічний модуль також повинен отримати загальну оцінку безпеки. Загальна оцінка безпеки буде відображати найменшу з незалежних оцінок, отриманих по областях.

    2. Криптографічна границя повинна складається з чітко визначеного периметру (тобто набору апаратних, програмних або програмно-апаратних компонентів), що встановлює границю усіх компонентів криптографічного модуля. Вимоги стандарту повинні поширюватися на всі алгоритми, функції безпеки, процеси і компоненти в межах криптографічної границі модуля. Криптографічна границя повинна, як мінімум, охоплювати всі алгоритми, пов’язані з безпекою, функції безпеки, процеси і компоненти криптографічного модуля.

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

    4. Криптографічний модуль повинен обмежувати всі логічні інформаційні потоки тільки до тих фізичних точок доступу і логічних інтерфейсів, які визначені як точки входу і виходу з криптографічної границі модуля. Логічні інтерфейси криптографічного модуля повинні бути відокремлені один від одного, хоча вони можуть спільно використовувати один фізичний порт або можуть бути розподілені по одному або декільком фізичним портам. Прикладний програмний інтерфейс (API) програмного компонента криптографічного модуля може бути визначений як один або декілька логічних інтерфейсів.

    5. Довірений канал – це зв'язок, встановлений між криптографічним модулем і відправником або одержувачем для безпечного повідомлення незахищених CSP у вигляді відкритого тексту, ключових компонентів і даних автентифікації. Довірений канал захищає від підслуховування, а також фізичного або логічного вторгнення небажаних операторів / об'єктів, процесів або інших пристроїв, між визначеними портами введення та виведення модуля, уздовж лінії зв'язку, та передбаченою кінцевою точкою відправника або отримувача.

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

    7. Експлуатаційне середовище криптографічного модуля пов’язане з управлінням програмним, програмно-апаратним та апаратним забезпеченням, що необхідне для роботи модуля. Експлуатаційне середовище програмних, , програмно-апаратних та гібридних модулів включає в себе, як мінімум, компоненти модуля, обчислювальну платформу та операційну систему, яка керує або дозволяє виконання програмного або програмно-апаратного забезпечення на обчислювальній платформі.

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

    9. Тестування на помилок, що викликані середовищем (EFT) повинне поєднувати аналіз, моделювання і тестування криптографічного модуля для надання обґрунтованих гарантій, що умови середовища (випадкові або навмисно створені), що виходять за межі нормального робочого діапазону температур і напруг модуля, не скомпрометують безпеку модуля. EFT повинне показувати, що якщо температура або напруга виходять за межі нормального робочого діапазону модуля спричиняючи збій, то безпека криптографічного модуля ні в якому разі не буде порушена.

    10. Критичні (чутливі параметри безпеки (SSP) складаються з критичних параметрів безпеки (CSP) і відкритих параметрів безпеки (PSP). Вимоги безпеки до управління SSP охоплюють весь життєвий цикл SSP, що використовуються модулем. Управління SSP охоплює генератори випадкових біт (RBG), генерацію SSP, встановлення SSP, введення / виведення SSP, зберігання SSP та обнуління незахищених SSP. В якості зашифрованих повинні розглядатись CSP, які зашифровані з використанням затвердженої функції безпеки. CSP, зашифровані або скриті з використанням незатверджених функцій безпеки в рамках даного міжнародного стандарту вважаються незахищеними, у вигляді відкритого тексту. CSP в межах модуля повинні бути захищені від несанкціонованого доступу, використання, розкриття, зміни і заміни. PSP в межах модуля повинні бути захищені від несанкціонованої зміни і заміни.

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

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

    13. Робота криптографічного модуля повинна визначатися за допомогою моделі кінцевих станів, представленої діаграмою переходу станів, таблицею переходу станів і описами станів. FSM повинен бути достатньо детальною, щоб продемонструвати, що криптографічний модуль відповідає всім вимогам даного стандарту. FSM криптографічного модуля повинна включати, як мінімум, такі експлуатаційні і помилкові стани

    14. Проект призначений для забезпечення гарантій того, що функціональні специфікації криптографічного модуля відповідають передбаченій функціональності, описаній в політиці безпеки. Криптографічні модулі повинні бути спроектовані таким чином, щоб дозволити тестування всіх послуг, пов’язаних з безпекою

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

    16. Усі особи, що використовують криптографічний модуль, мають мати належні керівництва і процедури адміністрування та використання модуля в затвердженому режимі експлуатації. Керівна документація, як правило, складається з керівництва адміністратора і не‑адміністратора.

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

    РОЗДІЛ 3

    АНАЛІЗ ВИМОГ ДО ЗАСОБІВ КЗІ, ЩО ВИКЛАДЕНІ В НОРМАТИВНИХ ДОКУМЕНТАХ РОСІЙСЬКОЇ ФЕДЕРАЦІЇ

    Система нормативної документації Російської Федерації в галузі інформаційної безпеки, що викладена в [1-8], з достатньою повнотою відображає загальну систему поглядів на проблему захисту інформації від НСД, зокрема і у засобах КЗІ.

    У даному розділі проводиться аналіз нормативної документації Російської Федерації в області захисту інформації від НСД. Особлива увага приділяється нормативним документам, що встановлюють показники захищеності від НСД і регламентують порядок організації розробки, виготовлення і експлуатації програмних і технічних засобів захисту, зокрема і у засобах КЗІ.

    3.1 Система нормативної документації Російської Федерації в області захисту інформації від несанкціонованого доступу

    Проведений аналіз відкритих джерел показав, що основними нормативними документами, прийнятими в Російській Федерації в області захисту інформації від несанкціонованого доступу (НСД) є [1-8]. Приведена сукупність нормативних документів з достатньою повнотою відображає загальну систему поглядів, що склалася в Російській Федерації в області захисту інформації від НСД.

    Зокрема, концепція захисту засобів обчислювальної техніки (ЗОТ) і автоматизованих систем (АС) від НСД до інформації [1] висвітлює систему поглядів та основних принципів щодо вирішення проблеми захисту інформації від НСД. Ця концепція є методологічною базою нормативно-технічних і методичних документів, направлених на вирішення наступних завдань:

    - вироблення вимог по захисту ЗОТ і АС від НСД до інформації;

    - створення захищених від НСД до інформації ЗОТ і АС;

    - сертифікація захищених ЗОТ і АС.

    У той же час концепція передбачає існування двох самостійних і, отже, відмінних напрямів в вирішенні проблеми захисту інформації від НСД: напрям, пов'язаний з ЗОТ, і напрям, пов'язаний з АС. Відмінність двох напрямів породжена тим, що ЗОТ розробляються і поставляються на ринок лише як елементи, з яких надалі будуються функціонально орієнтовані АС, і тому, не вирішуючи прикладних завдань, ЗОТ не містять призначеної для користувача інформації. При цьому захищеність ЗОТ розуміється як потенційна захищеність, тобто властивість запобігати або істотно утрудняти НСД до інформації надалі при використанні ЗОТ в АС.

    У керівному документі «Захист від несанкціонованого доступу до інформації. Терміни і визначення» встановлюються терміни і визначення понять в області захисту ЗОТ і АС від НСД [2]. Зокрема, під НСД розуміється доступ до інформації, що порушує правила розмежування доступу з використанням штатних засобів, наданих ЗОТ або АС [2].

    Нормативний документ [3] встановлює класифікацію ЗОТ по рівням захищеності від НСД до інформації на базі переліку показників захищеності і сукупності вимог, що описують їх.

    У [4] встановлюється класифікація АС, що підлягають захисту від НСД до інформації, і вимоги по захисту інформації в АС різних класів.

    Керівний документ [5] встановлює порядок досліджень і розробок в області:

    • захисту інформації, що обробляється АС різного рівня і призначення, від НСД;

    • створення ЗОТ загального і спеціального призначення, захищених від витоку, спотворення або знищення інформації за рахунок НСД, зокрема програмних і технічних засобів захисту інформації від НСД;

    • створення програмних і технічних засобів захисту інформації від НСД у складі систем захисту секретної інформації в створюваних АС.

    Фактично, цей нормативний документ визначає всі загальні питання із розробки, виготовлення і експлуатації програмних і технічних засобів захисту інформації, в тому числі і засобів КЗІ від НСД, оскільки регламентує наступні такі питання:

    • організаційну структуру і порядок проведення робіт по захисту інформації від НСД і взаємодії при цьому на державному рівні;

    • систему державних нормативних актів, стандартів, керівних документів і вимог з цієї проблеми;

    • порядок розробки і приймання захищених ЗОТ, зокрема програмних і технічних (зокрема, криптографічних) засобів і систем захисту інформації від НСД;

    • порядок приймання вказаних засобів і систем перед здачею в експлуатацію в складі АС, порядок їх експлуатації і контролю за працездатністю цих засобів і систем в процесі експлуатації.

    У нормативному документі [6] встановлюється класифікація міжмережевих екранів по рівню захищеності від НСД до інформації на базі переліку показників захищеності і сукупності вимог, що описують їх.

    Керівний документ [7] розповсюджується на електронні контрольно-касові машини і автоматизовані касові системи, які здійснюють обробку інформації, що підлягає контролю податковими органами.

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

    Таким чином, в системі відкритих нормативних документів Російської Федерації в області захисту інформації від НСД окремі положенні джерел [3, 5] безпосередньо відносяться до формування вимог до засобів КЗІ від НСД. Зокрема, в [3] встановлюються рівні захищеності від НСД до інформації, вводяться конкретні вимоги по окремих показників захищеності. В [5] регламентовано порядок організації розробки, виготовлення і експлуатації засобів КЗІ від НСД. Проаналізуємо змістовну частину цих документів на предмет використання певних положень в області захисту КЗЗ від НСД в Україні.

    3.2 Класифікація рівнів захищеності від НСД до інформації

    У нормативному документі [3] встановлюється сім класів захищеності від НСД до інформації. Найнижчий клас - сьомий, найвищий - перший.

    Класи підрозділяються на чотири групи, що відрізняються якісним рівнем захисту:

    • перша група містить тільки один сьомий клас;

    • друга група характеризується дискреційним захистом і містить шостий і п'ятий класи;

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

    • четверта група характеризується верифікованим захистом і містить тільки перший клас.

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

    Застосування в комплекті СВТ засобів криптографічного захисту інформації по ГОСТ 28147-89 може бути використано для підвищення гарантій якості захисту.

    Вимоги до показників захищеності

    Перелік показників по класах захищеності ЗОТ приведені в таблиці 3.1.

    Таблиця 3.1 - Перелік показників по класах захищеності від НСД

    Найменування показника
    1. Клас захищеності





    6

    5

    4

    3

    2

    1

    Дискреційний принцип контролю доступу

    +

    +

    +

    =

    +

    =

    Мандатний принцип контролю доступу

    -

    -

    +

    =

    =

    =

    Очищення пам'яті

    -

    +

    +

    +

    =

    =

    Ізоляція модулів

    -

    -

    +

    =

    +

    =

    Маркування документів

    -

    -

    +

    =

    =

    =

    Захист введення і виводу на відчужуваний фізичний носій інформації

    -

    -

    +

    =

    =

    =

    Зіставлення користувача з пристроєм

    -

    -

    +

    =

    =

    =

    Ідентифікація і автентифікація

    +

    =

    +

    =

    =

    =

    Гарантії проектування

    -

    +

    +

    +

    +

    +

    Реєстрація

    -

    +

    +

    +

    =

    =

    Взаємодія користувача з КЗЗ

    -

    -

    -

    +

    =

    =

    Надійне відновлення

    -

    -

    -

    +

    =

    =

    Цілісність КЗЗ

    -

    +

    +

    +

    =

    =

    Контроль модифікації

    -

    -

    -

    -

    +

    =

    Контроль дистрибуції

    -

    -

    -

    -

    +

    =

    Гарантії архітектури

    -

    -

    -

    -

    -

    +

    Тестування

    +

    +

    +

    +

    +

    +

    Керівництво для користувача

    +

    =

    =

    =

    =

    =

    Керівництво по КЗЗ

    +

    +

    =

    +

    +

    =

    Тестова документація

    +

    +

    +

    +

    +

    =

    Конструкторська (проектна) документація

    +

    +

    +

    +

    +

    +
    1   ...   21   22   23   24   25   26   27   28   29


    написать администратору сайта