Компьютерные технологии и информатика

ITSEC

Лекция №4 04.03.12

Разработан в 91 году в германии, голландинии.

Конфиденциальность, целостность, недоступность.

Основное содержание гарантированность безопасности. Затрагивает 2 аспекта:Эффективность и корректность средств обеспечения безопасности. При проверке эффективности анализируется адекватность наборов функций безопасности угрозам объекту оценки, взаимная согласованность функций, простота использования, а также возможность использования слабых мест защиты. Кроме того понятие эффективности входит противостояние прямым атакам, мощность механизма. Малое, среднее и высокое. Мощность считается базовой, если противостоит случайным атакам. Средняя, если противостоит злоумышленникам с ограниченными ресурсами. Высокое, если механизм может преодолеть злоумышленником высокой квалификации, набор ресурсов и возможностей выходит за пределы практичности. Эффективность защиты неудовлетворительна, если выявляются слабые места в критически важных механизмах, и эти слабости не устраняются до окончания процесса оценки (E0- номер). Защищенность системы не может быть самого слабого элемента, поэтому в критериях гарантируется минимально допустимая мощность.

Под корректностью понимается правильность реализации. При проверке корректности анализируется весь жизненный цикл проекта, при корректировании…

Семь уровней гарантированности корректности от E0 до E6. E0 – отсутствие гарантированности, Е1 – Е6 выстроены по тщательности оценки. Е1 общая архитектура объекта, вся остальная уверенность является следствием функционального тестирования. Е3 привлекается исходные тексты программ и схемы аппаратуры. Е6 формальное описание функции безопасности, архитектуры и модели памяти безопасности.

Общая оценка системы складывается из минимальной мощности механизма безопасности и уровня гарантированности корректности. В целом распределение требований по уровням гарантированности в европейских критериях соответствует распределению классов безопасности оранжевой книги. Требования политики безопасности и их наличие в безопансости не являются критериями… Хотя чтобы облегчить формулировку цели/оценки, критерии содержат в описании примерно 10 классов функциональности. 5из них соответсвуют классам безопасности оранжевой книги.

F-c1, e1-c1

f-c2, e2-c2

.

.

f-b3,e5-b3

f-b3, e6

F-IN:повышенная требования к целостность данных и программ, что типично для систем управления базами данных/

F-AV: повышенные требования к доступности. Системы управления технологическими процессами. Повышенные требования к надежности оборудования, бесперебойных реализации критечески важных функций, и восстановление после отказа. Независимо от уровня загрузки, должно также гарантироваться время реакции на определенные события.

F-DI: Характеризуется повышенными требованиями к целостности передаваемых данных. Обеспечивается путем использования методов обнаружения исправления ошибок. Сам алгоритм обнаружения искажений не должен давать возможности несанкционированного модификации информации. Усиливаются требования по регистрации и учета ошибок при передаче данных..

F-DC: Повышенные требования к обеспечения конфиденциальности при обмене данными. Использование криптографических устройств. Ключи шифрования надежно защищены от несанкционированного доступа.

F-DX: Повышенные требования к обеспечению конфиденциальности и целостности в сетевых кофигурациях. Реализуется путем возможных шифрования передаваемых данных, и надежной индентификации как ошибки, так и несанкционированного изменения передаваемых данных и данных регистрации. В системе регистрации должны быть компоненты, регистрирующие данные пользователей, индентификация ошибок при обмене данными и установлении соединения.

ГОСТ ИСО МЭК 15408 «Общий критерий»

Сформулирован весь опыт использования предыдущих стандартов.

Впервые был выпущен в 96 году.

Общий критерий. Удовлетворить требования 3-х потребителей: конечный пользователи, разработчики, оценщики объекта оценки. Объект оценки – ПО или информационная система. К рассматриваемым аспектам безопасности относится Защита от НСД, модификации, или потери доступа к информации. При воздействии угро, являющихся результатом преднамерянных или непреднамерянных действий. Некоторые аспекты находятся вне рамок общих критерий. Например оценка административных мер безопасности. АМБ в общей среде объекта оценки рассматриваются только в той части, где они могут повлиять только идентифицируемым угрозам. Не рассматриваются оценки технических аспектов безопасности типа ПЭМИН. Формулируются только критерии оценок. Стандарт не содержит критерии для оценки криптографических методов ЗИ. Общий критерий предполагается использовать предпалагается как при задании требований, так и при их оценки на всех этапах жизненного цикла. Структурно стандарт представлен в виде совокупности:

1. Представление и общая модель. Определятеся концепция, принципы и цели оценки безопасности ИТ.

2. Требования к функции безопасности. Приводятся требоавания к функции безопансоти и определятся набор показателей для оценки функции в ИТ. Набор требований, сгруппироанный в семейства и классы.

3. Требования гарантии безопасности. Сгруппированные в семейства и классы и уровни гарантии оценки.

4. Приложения предопредененных профили защиты. Примеры профилей защиты, включающие функциональные требования и требования гарантии оценки.

Требования безопасности разделятеся на 2 категории функ. Требования и требования гарантированности.

Функ: те функции, которые обеспечивают его безопасноть. Бинификация, унификация, разделение доступа и протоколирование.

Требования гарантированности отображают качество объекта оценки, дающие основания для уверенности в том, что функции безопасности эффективны и корректны. Оценка гарантированности получается на основе изучения назначения, структуры и функционирования объекта. Требования гарантированности включает требования к организации процесса разработки, а также требования поиска, анализа и воздействия на т=потенциально уязвимые места. Требование Представленно в едином стиле и использует одну и туже терминологию и организацию. Термины класс используется для наибольшей маркировки требований безопасноти члены класса называется семействы. Выполнение определенной чаксти цели безопасности, и могут отличаться по степени жесткости.

Члены семейства называются компонентами. Компоненты построены из элементов, а элемент это самый нижний, неделимый уровень требований безопасности, на котором производится оценка

Между компонентами могут существовать зависимости, которые возникают при недостаточном выполнении целей безопасности и необходимо наличие другого компонента.

Компоненты могут быть конкретизированы для обеспечения выполнения определенной политики безопасности или противостояния определенной угрозе. Разрешенными действиями считаются выбор и назначение. Назначение позволяет заполнить спецификацию идентифицированного параметра при использовании компонентов. Может быть признаком или правилом, который конкретизирует требования к определенной величине или диапазону величин. Общий критерий определяет набор структур, которые объединяет компоненты требований безопасности. Промежуточную комбинацию требований называют паркетом. Пакет набор требований, который обеспечивают выполнение одного из идентифицированных поднабора целей безопасности. Требования гарантированности и функциональные пакеты. Предопределенные пакеты гарантированности. Профиль защиты это набор требований, который состоит из пакетов или компонентов функциональных требований и одного из уровней гарантии. Требования профиля защиты могут конкретизированы или дополнены в другой структуре заданий по безопасности. Задания безопасности определяют требования безопасности для конкретного объекта оценки.

FAU Требования к распознаванию, реакции и хранению и анализу информации, связанные с действиями, затрагивающими инфомарцию. Компонент GEN 1. 1.

FCO требования об индентификации сторон, участвующих в обмене данными.

FDP Требования к защите данных пользователей в рамках оценки объекта в процессе хранения, ввода и вывода. ICC ICF дискрационное разграничение доступа

FIA Индентификация и аутентификация пользователей.

FPR требования к защите от раскрытия, несанкционированного испльзования индентификаторов пользователей.

FPT Требования к целостности данных функции безопасности и самих функций.

FTP Функциональные требования к доверенному маршруту.

FRU Требования к готовности ресурса использованию пользователем.

FTA Требования к сеансам работы пользователя.

FMT Управление функциями безопасности

ACM управление конфигурациями. Контроль версии, в процессе разработки и модификации.

ADO Требования к процедурам доверенной доставки продукта.

ADV требования к разработке и документированию разработки

AGD Требования к документациям пользователя и администратора.

ATE Требования к тестированию.

AvA Требования к анализу уязвимостей.

7 уровней гарантии оценки от eal1-eal7. Увеличение строгости

Включение определенных требований гарантии. 4-й уровень нормальный.

Руководящие документы гостехкомиссий.

Фстек

ТЕСТОВЫЕ ЗАДАНИЯ

Составитель /В.А.Кирсанов/

«___»______________2012 г.

Тестовые задания обсуждены на заседании кафедры инженерно-технических дисциплин и сервиса «__» ________ 2012 г. протокол __

Заведующий кафедрой /А.М. Мухаметшин/

СОГЛАСОВАНО

Начальник отдела

менеджмента качества /Д.Н. Алюшева/

Дата добавления: 2015-04-25