Заглавная страница Избранные статьи Случайная статья Познавательные статьи Новые добавления Обратная связь FAQ Написать работу КАТЕГОРИИ: АрхеологияБиология Генетика География Информатика История Логика Маркетинг Математика Менеджмент Механика Педагогика Религия Социология Технологии Физика Философия Финансы Химия Экология ТОП 10 на сайте Приготовление дезинфицирующих растворов различной концентрацииТехника нижней прямой подачи мяча. Франко-прусская война (причины и последствия) Организация работы процедурного кабинета Смысловое и механическое запоминание, их место и роль в усвоении знаний Коммуникативные барьеры и пути их преодоления Обработка изделий медицинского назначения многократного применения Образцы текста публицистического стиля Четыре типа изменения баланса Задачи с ответами для Всероссийской олимпиады по праву Мы поможем в написании ваших работ! ЗНАЕТЕ ЛИ ВЫ?
Влияние общества на человека
Приготовление дезинфицирующих растворов различной концентрации Практические работы по географии для 6 класса Организация работы процедурного кабинета Изменения в неживой природе осенью Уборка процедурного кабинета Сольфеджио. Все правила по сольфеджио Балочные системы. Определение реакций опор и моментов защемления |
Причетність до прийому/передаванняСодержание книги
Поиск на нашем сайте
Клас ФВБ: причетність до прийому/передавання [с. FCO: Communication] включає наступні розділи ФВБ: ■ попередження відмови від факту передавання інформації; ■ попередження відмови від факту прийому інформації. Розділ ФВБ: попередження відмови від факту передавання інформації [Non-Repudiation of Origin (FCO_NRO)] включає ієрархічно залежні функціональні вимоги безпеки: ■ підтвердження факту передавання інформації за вимогою [selective proof of origin (FCO_NRO.l)]; ■ автоматичне підтвердження факту передавання інформації [enforced proof of origin (FCO_NRO.2)]. Розділ ФВБ: попередження відмови від факту прийому інформації [Non-Repudiation of Receipt (FCO_NRR)] включає ієрархічно залежні функціональні вимоги безпеки: ■ підтвердження факту одержання інформації за вимогою [selective proof of receipt (FCO_NRR.l)]; ■ автоматичне підтвердження факту одержання інформації [enforced proof of receipt (FCO_NRR.2)].
Пряма взаємодія Клас ФВБ: пряма взаємодія [с. FTP: Trusted Path/channels] включає наступні розділи ФВБ: ■ пряма взаємодія між засобами захисту; ■ пряма взаємодія між користувачами. Розділ ФВБ: пряма взаємодія між засобами захисту [Inter-TSF Trusted Channel (FTP_ITS)] включає вимогу безпеки: пряма взаємодія між компонентами і засобами захисту різних продуктів [inter-TSF trusted channel (FTP_ITS.l)]. Розділ ФВБ: пряма взаємодія між користувачами [TRusted Path (FTP_TRP)] включає вимогу безпеки: пряма взаємодія з користувачами для вказаного набору ситуацій або за бажанням користувача [trusted path (FTP_JTRP.l)].
Вимоги гарантій засобів захисту Загальна характеристика вимог гарантій безпеки Вимоги гарантій безпеки (ВГБ) [security assurance requirements] — це вимоги безпеки, які в "Загальних критеріях" являють собою характеристику ІТ-продукту, що показує, наскільки ефективно забезпечується заявлений рівень безпеки, а також ступінь коректності реалізації засобів захисту. Як і функціональні вимоги безпеки, ВГБ детально структурировав та регламентують усі етапи проектування, створення та експлуатації ІТ-продукту дуже детально. Структура вимог гарантій аналогічна функціональним вимогам. Клас ВГБ [assurance class] — верхній рівень формальної структури вимог гарантій безпеки. Містить наступні елементи: назву класу [class name]; ■ опис класу [class introduction]; ■ розділи вимог гарантій безпеки [assurance family]. Вимоги розподілені на 7 класів ВГБ (рис. 27): ■ керування проектом; ■ дистрибуція; ■ розробка; ■ документація; ■ процес розробки; ■ тестування; ■ аналіз захисту. Розділ ВГБ [assurance family] — складова частина класу ВГБ. Структура розділу містить наступні елементи: ■ назва та позначення розділу [family name]; ■ мета [objectives]; ■ ранжирування вимог [component levelling]; ■ опис застосування [application notes]; ■ вимоги [assurance component]. Кожний розділ має свою унікальну назву і семисимвольний ідентифікатор, який складається з трибуквеного ідентифікатора класу, знаку підкреслення і трибуквеного позначення розділу. Ранжирування стандартних вимог представлене у вигляді впорядкованих списків. Структура ВГБ складається з наступних елементів: ■ назва вимоги [component identification]; ■ мета [objectives]; ■ опис застосування [application notes]; ■ сполучені вимоги [dependencies]; ■ елементи вимоги [assurance element]. Вимоги гарантій використовуються в ході кваліфікаційного аналізу IT-продукту відповідного рівня гарантій.
Рис. 27. Структура вимог гарантій безпеки Класи вимог гарантій безпеки Керування проектом Клас ВГБ: керування проектом [class ACM: Configuration Management] включає наступні розділи ВГБ: ■ засоби керування проектом; ■ керування версіями; ■ конфігурація проекту. Розділ ВГБ: засоби керування проектом [Configuration Management AUTomation (ACM_AUT)] включає наступні вимоги гарантій безпеки: ■ застосування автоматизованих засобів керування проектом [partial configuration management automation (ACM_AUT.l)]; ■ повна автоматизації керування проектом і контролю версій [complete configuration management automation (ACM_AUT.2)]. Розділ ВГБ: керування версіями [Configuration Management CAPabili-ties (ACM_CAP)] включає наступні вимоги гарантій безпеки: ■ нумерація версій [version numbers (ACM_CAP.l)]; ■ ідентифікація компонентів [configuration items (ACM_CAP.2)]; ■ контроль цілісності версій [authorisation controls (АСМ_САР.З)]; ■ авторизація розробників при поновленні версій [generation support and acceptance procedures (ACM_CAP.4)]; ■ контроль цілісності й автентичності дистрибутива системи [advanced support (ACM_CAP.5)]. Розділ ВГБ: конфігурація проекту [Configuration Management SCoPe (ACM_SCP)] включає наступні вимоги гарантій безпеки: ■ основні компоненти проекту (алгоритми, вихідні тексти, тексти, документація) [TOE management automation coverage (ASM_SCP.l)]; ■ включення до складу конфігурації об'єкта виявлених помилок і уразливостей [problem tracking management automation coverage (ASM_SCP.2)]; ■ включення до складу конфігурації проекту інструментальних засобів розробки [development tools management automation coverage (ASM_SCP.3)].
Дистрибуція Клас ВГБ: дистрибуція [class ADO: Delivery and Operation] включає наступні розділи ВГБ: ■ постачання; ■ установка, настройка, запуск. Розділ ВГБ: постачання [DELivery (ADO_DEL)] включає наступні вимоги гарантій безпеки: ■ регламентована процедура постачання [delivery procedures (ADO_DEL.l)]; ■ виявлення спотворень у процесі постачання [detection of modification (ADODEL.2)]; ■ захист від спотворень у процесі постачання [prevention of modification (ADO_DEL.3)]. Розділ ВГБ: установка, настройка, запуск [Installation, Generation, and Start-up (ADOIGS)] включає наступні вимоги гарантій безпеки: ■ регламентовані процедури установки, настройки, запуску [installation, generation, and start-up procedures (ADO_IGS.l)]; ■ протоколювання процесу установки, настройки, запуску [generation log (ADOJGS.2)].
Розробка Клас ВГБ: розробка [class ADV: Development] включає наступні розділи ВГБ: ■ загальні функціональні специфікації; ■ архітектура захисту; ■ форма подання продукту на сертифікацію; ■ структура засобів захисту; ■ часткові специфікації засобів захисту; ■ відповідність описів різного рівня; ■ політика безпеки. Розділ ВГБ: загальні функціональні специфікації [Functional Specification (ADV_FSP)] включає наступні вимоги гарантій безпеки: ■ неформальні специфікації для засобів захисту [informal functional specification (ADV_FSP.l)j; ■ неформальні специфікації для усіх інтерфейсів засобів захисту [fully defined external interfaces (ADV_FSP.2)]; ■ напівформальні специфікації для засобів захисту [semiformal functional specification (ADV_FSP.3)]; ■ формальні специфікації для засобів захисту [formal functional specification (ADV_FSP.4)]. Розділ ВГБ: архітектура захисту [High-Level Design (ADV_HLD)] включає наступні вимоги гарантій безпеки: ■ опис архітектури захисту [descriptive high-level design (ADV_HLD.l)]; ■ відповідність архітектури захисту політиці безпеки [security enforcing high-level design (ADV_HLD).2]; ■ напівформальний опис архітектури захисту [semiformal high-level design (ADV_HLD.3)]; ■ відповідність напівформального опису архітектури захисту політиці безпеки [semiformal high-level explanation (ADV_HLD.4)]; ■ формальний опис архітектури захисту й доказ її відповідності політиці безпеки [formal high-level design (ADV_HLD.5)]. Розділ ВГБ: форма подання продукту на сертифікацію [IMPlementation representation (ADV_IMP)] включає наступні вимоги гарантій безпеки: ■ опис реалізації обмеженої підмножини засобів захисту [subset of the implementation of the TSF (ADV_JMP.l)]; ■ повний опис реалізації усіх засобів захисту [implementation of the TSF (ADV_JMP2)]; ■ структурований опис реалізації усіх засобів захисту [structured implementation of the TSF (ADV_JMP3)]. Розділ ВГБ: структура засобів захисту [TSF INTernals (ADV_INT)] включає наступні вимоги гарантій безпеки: ■ модульність [modularity (ADV_INT.1)]; ■ ієрархічність [reduction of complexity (ADV_INT.2)]; ■ мінімізація складності [minimization of complexity (ADV_INT.3)]. Розділ ВГБ: часткові специфікації засобів захисту [Low-Level Design (ADV_LLD)] включає наступні вимоги гарантій безпеки: ■ неформальні часткові специфікації засобів захисту [descriptive low-level design (ADV_LLD.l)]; ■ напівформальні часткові специфікації засобів захисту [semiformal low-level design (ADV_LLD.2)]; ■ формальні часткові специфікації засобів захисту [formal low-level design (ADV_LLD.3)]. Розділ ВГБ: відповідність описів різного рівня [Representation CorRespondente (ADV_RCR)] включає наступні вимоги гарантій безпеки: ■ неформальне підтвердження відповідності [informal correspondence demonstration (ADV_RCR.l)]; ■ напівформальне підтвердження відповідності [semiformal correspondence demonstration (ADV_RCR.2)]; ■ формальний доказ відповідності [formal correspondence demonstration (ADVRCR.3)]. Розділ ВГБ: політика безпеки [Security Policy Modeling (ADV_SPM)] включає наступні вимоги гарантій безпеки: ■ неформальний опис політики безпеки [informal TOE security policy model (ADV_SPM.l)]; ■ напівформальний опис політики безпеки [semiformal TOE security policy model (ADV_SPM.2)]; ■ формальна модель політики безпеки [formal TOE security policy model (ADV_SPM.3)].
Документація Клас ВГБ: документація [class AGD: Guidance Documents] включає наступні розділи ВГБ: ■ керівництво адміністратора; ■ керівництво користувача. Розділ ВГБ: керівництво адміністратора [ADMinistrator guidance (AGD_ADM)] включає вимогу гарантій безпеки: адміністрування засобів захисту [administrator guidance (AGD_ADM.l)]. Розділ ВГБ: керівництво користувача [USeR guidance (AGD_USR)] включає вимогу гарантій безпеки: використання засобів захисту [user guidance (AGD_JJSR.l)].
Процес розробки Клас ВГБ: процес розробки [class ALC: Life Cycle support] включає наступні розділи ВГБ: ■ безпека середовища розробки; ■ виправлення помилок і ліквідація уразливостей; ■ технологія розробки; ■ засоби розробки. Розділ ВГБ: безпека середовища розробки [Development Security (ALC_DVS)] включає наступні вимоги гарантій безпеки: ■ застосування заходів безпеки в ході розробки [identification of security measures (ALC_DVS.l)]; ■ підтвердження заходів безпеки в ході розробки [sufficiency of security measures (ALC_DVS.2)]. Розділ ВГБ: виправлення помилок і ліквідація уразливостей [FLaw Remediation (ALC_FLR)] включає наступні вимоги гарантій безпеки: ■ виправлення виявлених помилок і ліквідація уразливостей [basic flaw remediation (ALC_FLR.l)]; ■ регулярне виправлення помилок і ліквідація уразливостей [flaw reporting procedures (ALC_FLR.2)]; ■ гарантоване виправлення виявлених помилок і ліквідація виявлених уразливостей [systematic flaw remediation (ALC_FLR.2)]. Розділ ВГБ: технологія розробки [Life Cycle Definition (ALC_LCD)] включає наступні вимоги гарантій безпеки: ■ визначена розробником технологія розробки [developer defined life-cycle model (ALC_LCD.l)]; ■ стандартизована технологія розробки [standardised life-cycle model (ALC_LCD.2)]; ■ технологія розробки, яка дозволяє оцінювати продукт, що розроблюється [measurable life-cycle model (ALC_LCD.3)]. Розділ ВГБ: засоби розробки [Tools And Techniques (ALC_TAT)] включає наступні вимоги гарантій безпеки: ■ використання певного набору засобів розробки [well-defined development tools (ALC_JTAT.l)]; ■ використання основних засобів розробки, що відповідають певним стандартам [compliance with implementation standards (ALC_TAT.2)]; ■ використання тільки засобів розробки, що відповідають певним стандартам [compliance with implementation standards — all parts (ALC_JTAT.3)].
Тестування Клас ВГБ: тестування [class ATE: TEsts] включає наступні розділи ВГБ: ■ повнота тестування; ■ глибина тестування; ■ методика тестування; ■ незалежне тестування. Розділ ВГБ: повнота тестування [COVerage (ATECOV)] включає наступні вимоги гарантій безпеки: ■ обґрунтування повноти тестування [evidence of coverage (ATE_COV.l)]; ■ аналіз повноти тестування [analysis of coverage (ATE_COV.2)]; ■ строгий аналіз повноти тестування [rigorous analysis of coverage (ATE_COV.3)]. Розділ ВГБ: глибина тестування [DePTh (ATEDPT)] включає наступні вимоги гарантій безпеки: ■ архітектура [testing: high-level design (ALC_DPT.l)]; ■ функціональні специфікації [testing: low-level design (ALC_DPT.2)]; ■ реалізація [testing: implementation representation (ALC_DPT.3)]. Розділ ВГБ: методика тестування [FUNctional tests (ATE_FUN)] включає наступні вимоги гарантій безпеки: ■ функціональне тестування й протоколювання результатів тестів [functional testing (ALCFUN.l)]; ■ тестування у відповідності з певною методикою [ordered functional testing (ALC_FUN.2)]. Розділ ВГБ: незалежне тестування [INDependent testing (ATE_IND)] включає наступні вимоги гарантій безпеки: ■ готовність продукту до незалежного тестування [independent testing — conformance (ALC_IND.l)]; ■ вибіркове незалежне тестування [independent testing — sample (ALC_JND.2)]; ■ повне незалежне тестування [independent testing — complete (ALC_IND.3)].
Аналіз захисту Клас ВГБ: аналіз захисту [class AVA: Vulnerability Assessment] включає наступні розділи ВГБ: ■ аналіз прихованих каналів; ■ аналіз можливостей неправильного використання засобів захисту; ■ аналіз стійкості засобів захисту; ■ аналіз продукту на наявність уразливостей. Розділ ВГБ: аналіз прихованих каналів [Covert Channel Analysis (AVA_CCA)] включає наступні вимоги гарантій безпеки: ■ пошук і документування прихованих каналів [covert channel analysis (AVA_CCA.l)]; ■ пошук прихованих каналів на основі певних методик [systematic covert channel analysis (AVA_CCA.2)]; ■ вичерпний пошук прихованих каналів [exhaustive covert channel analysis (AVA_CCA.3)]. Розділ ВГБ: аналіз можливостей неправильного використання засобів захисту [MiSUse (AVA_MSU)] включає наступні вимоги гарантій безпеки: ■ аналіз керівництв з адміністрування [examination of guidance (AVA_MSU.l)]; ■ підтвердження повноти керівництв з адміністрування та безпеки їхнього застосування [validation of analysis (AVA_MSU.2)]; ■ незалежний аналіз можливостей неправильного використання засобів захисту [analysis and testing for insecure states (AVA_MSU.3)]. Розділ ВГБ: аналіз стійкості засобів захисту [Strength Of TOE security Functions (AVA_SOF)] включає вимогу гарантій безпеки: оцінка стійкості засобів захисту [strength of TOE security function evaluation (AVA_SOF.l)]. Розділ ВГБ: аналіз продукту на наявність уразливостей [VuLnerability Analysis (AVA_VLA)] включає наступні вимоги гарантій безпеки: ■ виявлення уразливостей розробником продукту [developer vulnerability analysis (AVA_VLA.l)]; ■ незалежний аналіз уразливостей [independent vulnerability analysis (AVA_VLA.2)]; ■ систематичний незалежний аналіз уразливостей на основі заданих методик [(AVA_VLA.3)]; ■ вичерпний аналіз уразливостей [moderately resistant (AVA_VLA.4)].
Рівні гарантій безпеки Визначення рівнів гарантій Рівні гарантій [Evaluation Assurance Level (EAL)] — в "Загальних критеріях" — це сім стандартизованих наборів вимог гарантій безпеки, що регламентують застосування різноманітних методів і технологій розробки, тестування, контролю та верифікації ІТ-продукту: ■ функціональне тестування; ■ структурне тестування; ■ методичне тестування та перевірка; ■ методична розробка, тестування та аналіз; ■ напівформальні методи розробки та тестування; ■ напівформальні методи верифікації розробки та тестування; ■ формальні методи верифікації розробки та тестування. Кожний з рівнів визначає ступінь відповідності ІТ-продукту кожній вимозі гарантій (гарантії зростають від першого рівня до сьомого). Назви рівнів відображають можливості засобів контролю і верифікації, що застосовуються в ході розробки та аналізу ІТ-продукту (рис. 28). Рис. 28. Рівні гарантій безпеки
Функціональне тестування Рівень функціонального тестування [EAL1 — functionally tested] — перший рівень гарантій для випадків, коли загрозам безпеці не надається великого значення. Пропонується використати його в тих ситуаціях, коли все, що необхідно, — це незалежна гарантія того, що до складу ІТ-продукту входять засоби захисту персональної або подібної інформації. Відповідає наступним вимогам гарантій безпеки: ■ у класі ВГБ: керування проектом, у розділі ВГБ: керування версіями — нумерація версій; ■ у класі ВГБ: дистрибуція, в розділі ВГБ: установка, настройка, запуск — регламентовані процедури установки, настройки, запуску; ■ у класі ВГБ: розробка: • у розділі ВГБ: загальні функціональні специфікації— неформальні специфікації для засобів захисту; • у розділі ВГБ: відповідність описів різного рівня — неформальне підтвердження відповідності. ■ у класі ВГБ: документація: • у розділі ВГБ: керівництво адміністратора — адміністрування засобів захисту; • у розділі ВГБ: керівництво користувача — використання засобів захисту. ■ у класі ВГБ: тестування, в розділі ВГБ: незалежне тестування — готовність продукту до незалежного тестування. Аналіз ІТ-продукту на відповідність даному рівню гарантій забезпечується дослідженням функцій захисту та перевіркою функціональних специфікацій, інтерфейсів та документації. Результати аналізу підтверджуються незалежним тестуванням засобів захисту ІТ-продукту на відповідність специфікаціям і документації. Сертифікація ІТ-продукту на даний рівень гарантій є підтвердженням відповідності властивостей ІТ-продукту його документації та специфікаціям, а також наявності працездатності захисту проти загроз безпеці.
Структурне тестування Рівень структурного тестування [EAL2 — structurally tested] — другий рівень гарантій, призначений для використання при обставинах, коли розробники або користувачі згодні задовольнитися низьким або помірним ступенем незалежного підтвердження гарантій рівня безпеки, який необхідно забезпечити. Особливо рекомендують застосування даного рівня для успадкованих систем, які вже знаходяться в експлуатації. Другий рівень гарантій відповідає наступним вимогам гарантій безпеки: ■ у класі ВГБ: керування проектом, у розділі ВГБ: керування версіями — ідентифікація компонентів; ■ у класі ВГБ: дистрибуція: • у розділі ВГБ: постачання — регламентована процедура поставки; • у розділі ВГБ: установка, настройка, запуск — регламентовані процедури установки, настройки, запуску; ■ у класі ВГБ: розробка: • у розділі ВГБ: загальні функціональні специфікації — неформальні специфікації засобів захисту; • у розділі ВГБ: архітектура захисту — опис архітектури захисту; • у розділі ВГБ: відповідність описів різного рівня — неформальне підтвердження відповідності; ■ у класі ВГБ: документація: • у розділі ВГБ: керівництво адміністратора — адміністрування засобів захисту; • у розділі ВГБ: керівництво користувача -— використання засобів захисту; ■ у класі ВГБ: тестування: • у розділі ВГБ: повнота тестування — обґрунтування повноти тестування; • у розділі ВГБ: методика тестування — функціональне тестування й протоколювання результатів тестів; • у розділі ВГБ: незалежне тестування — вибіркове незалежне тестування; ■ у класі ВГБ: оцінка захисту: • у розділі ВГБ: аналіз стійкості засобів захисту — оцінка стійкості засобів захисту; • у розділі ВГБ: аналіз продукту на наявність уразливостей — виявлення уразливостей розробником продукту. Розробка продукту відповідно до вимог даного рівня не вимагає від виробника ніяких додаткових витрат, порівняно з розробкою звичайних комерційних або промислових продуктів, окрім надання результатів тестування. Для другого рівня аналіз повинен проводитися не тільки по відношенню до функціональних специфікацій, інтерфейсів та документації, але й для архітектури захисту ІТ-продукту. Крім незалежного тестування засобів захисту ІТ-продукту, результати аналізу підтверджуються протоколами тестування функціональних специфікацій, наданих розробником, а також незалежним вибірковим контролем результатів цих випробувань та глибини проведеного тестування, і незалежним підтвердженням пошуку розробником явних уразливостей. Крім того, для цього рівня необхідна наявність документованого складу конфігурації продукту та доказ безпеки процедури постачання. Даний рівень розширює вимоги попереднього за рахунок включення в матеріали, що підтверджують аналіз результатів тестів, проведених розробником ІТ-продукту, необхідністю здійснення аналізу уразливостей та незалежного тестування з використанням більш детальних специфікацій.
|
||||
Последнее изменение этой страницы: 2016-08-15; просмотров: 638; Нарушение авторского права страницы; Мы поможем в написании вашей работы! infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 18.117.158.124 (0.008 с.) |