Оценочные уровни доверия к информационной безопасности

Размещено на http://www.allbest.ru/

Содержание

1. Введение

2. Структура оценочного уровня доверия

2.1 Область применения

2.2 Основные принципы ГОСТ Р 15408-3-2002

2.3 Подход к доверию

2.4 Доверие через оценку

2.5 Структура ОУД

2.5.1 Имя ОУД

2.5.2 Цели

2.5.3 Замечания по применению

2.5.4 Компоненты доверия

2.6 Связь между требованиями и уровнями доверия

3. FDP_UCT защита конфиденциальности данных пользователя при передаче между ФБО

3.1 Характеристика семейства FDP_UCT

3.2 Характеристика политики управления

3.3 Характеристики политики безопасности

3.4 Требования класса FDP

3.5 Структура класса

3.5.1 Аудит: FDP_UCT

4. ADV_HLD Проект верхнего уровня

4.1 Свойства ADV_HLD

4.2 Проект верхнего уровня (ADV_HLD)

4.2.1 Цели

4.2.2 Ранжирование компонентов

4.2.3 Замечания по применению

4.2.4 Элементы ADV_HLD

4.3 ADV_HLD.1 Описательный проект верхнего уровня

Заключение

Библиографический список

Приложения

оценочный доверие конфиденциальность пользователь ражировка

1. Введение

Проблема обеспечения безопасности информационных технологий занимает все более значительное место в реализации компьютерных систем и сетей по мере того, как возрастает их роль в информатизации общества. Обеспечение безопасности информационных технологий (ИТ) представляет собой комплексную проблему, которая решается в направлениях совершенствования правового регулирования применения ИТ, совершенствования методов и средств их разработки, развития системы сертификации, обеспечения соответствующих организационно-технических условий эксплуатации. Ключевым аспектом решения проблемы безопасности ИТ является выработка системы требований, критериев и показателей для оценки уровня безопасности ИТ. Методологической основой исследования являются основополагающие стандарты (сокращенно ГОСТы), законы РФ. ГОСТ Р 15408 содержит общие критерии оценки безопасности информационных технологий. ГОСТ Р 15408-1 устанавливает общий подход к формированию требований к оценке безопасности (функциональные и доверия), основные конструкции (профиль защиты, задание по безопасности) представления требований безопасности в интересах потребителей, разработчиков и оценщиков продуктов и систем ИТ. Требования безопасности объекта оценки (ОО) по методологии Общих критериев определяются исходя из целей безопасности, которые, в свою очередь, основываются на анализе назначения ОО и условий среды его использования (угроз, предложений, политики безопасности). ГОСТ Р 15408-2 содержит универсальный систематизированный каталог функциональных требований безопасности и предусматривает возможность их детализации и расширения по определенным правилам. ГОСТ Р 15408-3 включается в себя систематизированный каталог требований доверия, определяющих меры, которые должны быть приняты на всех этапах жизненного цикла продукта или системы ИТ для обеспечения уверенности в том, что они удовлетворяют предъявленным к ним функциональным требованиям. В документе так же содержатся оценочные уровни доверия, определяющие шкалу требований, которые позволяют с возрастающей степенью полноты и строгости оценить проектную, тестовую и эксплуатационную документацию, правильность реализации функций безопасности ОО, уязвимости продукта или системы ИТ, стойкость механизмов защиты и сделать заключение об уровне доверия к безопасности объекта оценки.

2. Структура оценочного уровня доверия

2.1 Область применения

Настоящий стандарт определяет требования доверия к безопасности и включает в себя оценочные уровни доверия (ОУД), определяющие шкалу для измерения доверия, собственно компоненты доверия, из которых составлены уровни доверия, и критерии для оценки ПЗ и ЗБ.

2.2 Основные принципы ГОСТ Р 15408-3-2002

Основные принципы ГОСТ Р 15408-3-2002 состоят в том, что следует четко сформулировать угрозы безопасности и положения политики безопасности организации, а достаточность предложенных мер безопасности должна быть продемонстрирована. Более того, следует предпринять меры по уменьшению вероятности наличия уязвимостей, возможности их проявления (т.е. преднамеренного использования или непреднамеренной активизации), а также степени ущерба, который может явиться следствием проявления уязвимостей. Дополнительно следует предпринять меры для облегчения последующей идентификации уязвимостей, а также по их устранению, ослаблению и/или оповещению об их использовании или активизации.

2.3 Подход к доверию

Основная концепция ГОСТ Р 15408 - обеспечение доверия, основанное на оценке (активном исследовании) продукта или системы ИТ, которым предполагается доверять. Оценка была традиционным способом обеспечения доверия и являлась основой предшествующих критериев оценки. Для согласования с существующими подходами в ГОСТ Р 15408 принят тот же самый основной принцип. ГОСТ Р 15408 предполагает, что проверку правильности документации и разработанного продукта или системы ИТ будут проводить опытные оценщики, уделяя особое внимание области, глубине и строгости оценки. ГОСТ Р 15408 не отрицает и при этом не комментирует относительные достоинства других способов получения доверия. Продолжаются исследования альтернативных путей достижения доверия. Если в результате этих исследований будут выявлены другие отработанные альтернативные подходы, то они могут в дальнейшем быть включены в ГОСТ Р 15408, который структурно организован так, что предусматривает такую возможность.

2.4 Доверие через оценку

Оценка является традиционным способом достижения доверия, и она положена в основу ГОСТ Р 15408. Методы оценки могут, в частности, включать в себя:

· анализ и проверку процессов и процедур;

· проверку, что процессы и процедуры действительно применяются;

· анализ соответствия между представлениями проекта ОО;

· анализ соответствия каждого представления проекта ОО требованиям;

· верификацию доказательств;

· анализ руководств;

· анализ разработанных функциональных тестов и полученных результатов;

· независимое функциональное тестирование;

· анализ уязвимостей, включающий предположения о недостатках;

· тестирование проникновения.

2.5 Структура ОУД

Рисунок 2.3 иллюстрирует ОУД и их структуру, определенную в настоящем стандарте. Компоненты доверия, содержание которых показано на рисунке, включены в ОУД посредством ссылок на компоненты, приведенные в настоящем стандарте.

Структура ОУД

2.5.1 Имя ОУД

Каждому ОУД присвоено уникальное имя. Имя представляет описательную информацию о предназначении ОУД. Представлена также уникальная краткая форма имени ОУД. Она является основным средством ссылки на ОУД.

2.5.2 Цели

В подразделе целей ОУД приведено назначение ОУД.

2.5.3 Замечания по применению

Подраздел замечаний по применению ОУД содержит информацию, представляющую интерес для пользователей ОУД (например, для разработчиков ПЗ и ЗБ, проектировщиков ОО, планирующих использование этого ОУД, оценщиков). Представление неформально и включает в себя, например, предупреждения об ограничениях использования или областях, требующих особого внимания.

2.5.4 Компоненты доверия

Для каждого ОУД выбран набор компонентов доверия.

Более высокий уровень доверия, чем предоставляемый данным ОУД, может быть достигнут:

1. включением дополнительных компонентов доверия из других семейств доверия;

2. заменой компонента доверия иерархичным компонентом из этого же семейства доверия.

2.6 Связь между требованиями и уровнями доверия

Рисунок 2.4 иллюстрирует связь между требованиями и уровнями доверия, определенными в настоящем стандарте. Компоненты доверия состоят из элементов, но последние не могут по отдельности быть включены в уровни доверия. Стрелка на рисунке отображает ссылку в ОУД на компонент доверия внутри класса, где он определен.



Связь требований и уровня доверия

3. FDP_UCT защита конфиденциальности данных пользователя при передаче между ФБО

3.1 Характеристика семейства FDP_UCT

Семейство FDP_UCT определяет требования по обеспечению конфиденциальности данных пользователя при их передаче по внешнему каналу между ОО и другим доверенным продуктом ИТ. Конфиденциальность осуществляется путем предотвращения несанкционированного раскрытия данных при их передаче между двумя оконечными точками. Оконечными точками могут быть ФБО или пользователь. Это семейство предоставляет требование защиты данных пользователя при передаче. Семейство FPT_ITC, напротив, имеет дело с данными ФБО. Цель компонента FDP_UCT.1 "Базовая конфиденциальность обмена данными" состоит в предоставлении защиты от раскрытия данных пользователя во время их передачи. В FDP_UCT.1.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления доступом и/или информационными потоками, которые будут осуществляться при обмене данными пользователя. Указанные политики будут осуществляться для принятия решений о том, кто и какими данными может обмениваться.

В FDP_UCT.1.1 автору ПЗ/ЗБ следует определить, применяется этот элемент к механизму отправления или получения данных пользователя. Класс FDP содержит семейства, определяющие требования к функциям безопасности OO и политикам функций безопасности OO, связанным с защитой данных пользователя. Он разбит на четыре группы семейств, перечисленные ниже и применяемые к данным пользователя в пределах OO при их импорте, экспорте и хранении, а также к атрибутам безопасности, прямо связанным с данными пользователя. Этот класс отличается от FIA и FPT тем, что определяет компоненты для защиты данных пользователя, тогда как FIA определяет компоненты для защиты атрибутов, ассоциированных с пользователем, а FPT - для защиты информации ФБО.

Этот класс не содержит явного требования "мандатного управления доступом" (Mandatory Access Controls - MAC) или традиционного "дискреционного управления доступом" (Discretionary Access Controls - DAC); тем не менее такие требования могут быть выражены с использованием компонентов этого класса.

Класс FDP не касается явно конфиденциальности, целостности или доступности, чаше всего сочетающихся в политике и механизмах. Тем не менее в ПЗ/ЗБ политику безопасности ОО необходимо адекватно распространить на эти три цели.

Заключительным аспектом этого класса является то, что он специфицирует управление доступом в терминах "операций". "Операция" определяется как специфический тип доступа к конкретному объекту. В зависимости от уровня абстракции описания автором ПЗ/ЗБ этих операций, они могут определяться как "чтение" и/или "запись" или как более сложные операции, например "обновление базы данных".

3.2 Характеристика политики управления

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

3.3 Характеристика политики безопасности

Политика безопасности ОО может содержать несколько политик функций безопасности (ПФБ), каждая из которых будет идентифицирована компонентами двух ориентированных на политики семейств FDP_ACC и FDP_IFC. Эти политики будут, как правило, учитывать аспекты конфиденциальности, целостности и доступности так, как это потребуется для удовлетворения требований к ОО. Следует побеспокоиться, чтобы на каждый объект обязательно распространялась по меньшей мере одна ПФБ и чтобы при реализации различных ПФБ не возникали конфликты.

3.4 Требования класса FDP

Требования класса FDP определены в терминах функций безопасности (ФБ), которые реализуют ПФБ. Поскольку ОО может одновременно следовать нескольким ПФБ, автору ПЗ/ЗБ необходимо дать каждой из ПФБ название, на которое можно ссылаться в других семействах. Это название будет затем использоваться в каждом компоненте, выбранном для определения части требований для соответствующей функции. Это позволяет автору легко указать область действия, например охватываемые объекты и операции, уполномоченные пользователи и т.д.

Как правило, каждое отображение компонента может использоваться только для одной ПФБ. Поэтому, если ПФБ специфицирована в компоненте, то она будет применена во всех элементах этого компонента. Эти компоненты могут отображаться в ПЗ/ЗБ несколько раз, если желательно учесть несколько политик.

Ключом к выбору компонентов из этого семейства является наличие полностью определенной политики безопасности ОО, обеспечивающей правильный выбор компонентов из семейств FDP_ACC и FDP_IFC. В FDP_ACC и FDP_IFC присваивают имя соответственно каждой политике управления доступом или информационными потоками. Кроме того, эти компоненты определяют субъекты, объекты и операции, входящие в область действия соответствующей функции безопасности. Предполагается, что имена этих политик будут использоваться повсеместно в тех функциональных компонентах, которые имеют операцию, запрашивающую назначение или выбор "ПФБ управления доступом" и/или "ПФБ управления информационными потоками". Правила, которые определяют функциональные возможности именованных ПФБ управления доступом или информационными потоками, будут установлены в семействах FDP_ACF и FDP_IFF соответственно.

3.5 Структура класса

Декомпозиция класса FDP на составляющие его компоненты приведена на рисунке

Защита данных пользователя



Защита данных пользователя

3.3.1 Аудит: FDP_UCT.1

1. Минимальный: идентификатор любого пользователя или субъекта, использующего механизмы обмена данными. Базовый: идентификатор неуполномоченного пользователя или субъекта, предпринимающего попытку использовать механизмы обмена данными.

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

4. ADV_HLD Проект верхнего уровня

4.1 Свойства ADV_HLD

Семейство ADV_HLD содержит требования к проекту верхнего уровня, описывающего структуру функций безопасности ОО в терминах подсистем. Проект должен идентифицировать все необходимые базовые аппаратные, программно-аппаратные и/или программные средства с представлением функций, обеспечиваемых поддержкой реализуемых этими средствами механизмов защиты, а также все интерфейсы подсистем, выделяя те из них, которые предполагаются видимыми извне. Каждый интерфейс необходимо снабдить описанием назначения и методов использования (то же касается и функциональных спецификаций - это означает демонстрацию соответствия функциональным требованиям и позволяет организовать тестирование.) Следует выделить подсистемы, осуществляющие политику безопасности. Наконец, проект верхнего уровня должен содержать обоснование того, что выбранные механизмы достаточны для реализации функций безопасности.

4.2 Проект верхнего уровня (ADV_HLD)

4.2.1 Цели

Проект верхнего уровня ОО представляет описание ФБО в терминах основных структурных частей (т.е. подсистем) и связывает эти части с функциями, которые они выполняют. Требования к проекту верхнего уровня предназначены для обеспечения доверия, что ОО имеет архитектуру, приемлемую для реализации функциональных требований безопасности ОО.

Проект верхнего уровня уточняет функциональную спецификацию, преобразуя ее в подсистемы. Для каждой подсистемы ФБО проект верхнего уровня описывает ее назначение, а также идентифицирует функции безопасности, включаемые в подсистему. В проекте верхнего уровня также определяются взаимосвязи всех подсистем. Эти взаимосвязи будут представлены как внешние интерфейсы соответственно по данным, управлению и т.д.

4.2.2 Ранжирование компонентов

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

4.2.3 Замечания по применению

Разработчик, как ожидается, опишет проект ФБО в терминах подсистем. Термин "подсистема" используют здесь для выражения идеи декомпозиции ФБО на относительно небольшое число частей. Даже если разработчику фактически не требуется иметь "подсистемы", ожидается, что он представит подобный уровень декомпозиции. Например, проект может быть декомпозирован путем использования "уровней", "доменов" или "серверов".

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

Выражение "подсистема, осуществляющая ПБО" относится к подсистеме, которая прямо или косвенно содействует осуществлению ПБО.

4.2.4 Элементы ADV_HLD

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

ADV_HLD.3.8C содержит требование полного представления интерфейсов подсистем. Этим будет обеспечена необходимая детализация для поддержки как полного тестирования ОО (с использованием компонентов из ATE_DPT), так и оценки уязвимостей.

Применительно к уровню формализации проекта верхнего уровня неформальный, полуформальный и формальный проекты рассматривают как иерархичные, по сути. Так, элементы требований ADV_HLD.1.1C и ADV_HLD.2.1C могут быть удовлетворены ис-пользованием полуформального или формального проекта верхнего уровня, а элементы требований ADV_HLD.3.1С и ADV_HLD.4.1C - использованием формального проекта верхнего уровня.

4.3 ADV_HLD.1 Описательный проект верхнего уровня

Зависимости

ADV_FSP.1 Неформальная функциональная спецификация

ADV_RCR.1 Неформальная демонстрация соответствия

Элементы действий разработчика

ADV_HLD.1.1D Разработчик должен представить проект верхнего уровня ФБО.

Элементы содержания и представления свидетельств

ADV_HLD.1.1C Представление проекта верхнего уровня должно быть неформальным.

ADV_HLD.1.2C Проект верхнего уровня должен быть внутренне непротиворечивым.

ADV_HLD.1.3C Проект верхнего уровня должен содержать описание структуры ФБО в терминах подсистем.

ADV_HLD.1.4C Проект верхнего уровня должен содержать описание функциональных возможностей безопасности, предоставленных каждой подсистемой ФБО.

ADV_HLD.1.5C Проект верхнего уровня должен идентифицировать все базовые аппаратные, программно-аппаратные и/или программные средства, требуемые для реализации ФБО, с представлением функций, обеспечиваемых поддержкой механизмов защиты, реализуемых этими средствами.

ADV_HLD.1.6C Проект верхнего уровня должен идентифицировать все интерфейсы для подсистем ФБО.

ADV_HLD.1.7C Проект верхнего уровня должен идентифицировать, какие из интерфейсов подсистем ФБО являются видимыми извне.

Элементы действий оценщика

ADV_HLD.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADV_HLD.1.2E Оценщик должен сделать независимое заключение, что проект верхнего уровня - точное и полное отображение функциональных требований безопасности ОО.

ADV_HLD.2 Детализация вопросов безопасности в проекте верхнего уровня

Зависимости

ADV_FSP.1 Неформальная функциональная спецификация

ADV_RCR.1 Неформальная демонстрация соответствия

Элементы действий разработчика

ADV_HLD.2.1D Разработчик должен представить проект верхнего уровня ФБО.

Элементы содержания и представления свидетельств

ADV_HLD.2.1C Представление проекта верхнего уровня должно быть неформальным.

ADV_HLD.2.2C Проект верхнего уровня должен быть внутренне непротиворечивым.

ADV_HLD.2.3C Проект верхнего уровня должен содержать описание структуры ФБО в терминах подсистем.

ADV_HLD.2.4C Проект верхнего уровня должен содержать описание функциональных возможностей безопасности, предоставленных каждой подсистемой ФБО.

ADV_HLD.2.5C Проект верхнего уровня должен идентифицировать все базовые аппаратные, программно-аппаратные и/или программные средства, требуемые для реализации ФБО, с представлением функций, обеспечиваемых поддержкой механизмов защиты, реализуемых этими средствами.

ADV_HLD.2.6C Проект верхнего уровня должен идентифицировать все интерфейсы для подсистем ФБО.

ADV_HLD.2.7C Проект верхнего уровня должен идентифицировать, какие из интерфейсов подсистем ФБО являются видимыми извне.

ADV_HLD.2.8C Проект верхнего уровня должен содержать описание назначения и методов использования всех интерфейсов подсистем ФБО, обеспечивая, где это необходимо, детализацию результатов, нештатных ситуаций и сообщений об ошибках.

ADV_HLD.2.9C Проект верхнего уровня должен содержать описание разделения ОО на подсистемы, осуществляющие ПБО, и прочие.

Элементы действий оценщика

ADV_HLD.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADV_HLD.2.2E Оценщик должен сделать независимое заключение, что проект верхнего уровня - точное и полное отображение функциональных требований безопасности ОО.

ADV_HLD.3 Полуформальный проект верхнего уровня

Зависимости

ADV_FSP.3 Полуформальная функциональная спецификация

ADV_RCR.2 Полуформальная демонстрация соответствия

Элементы действий разработчика

ADV_HLD.3.1D Разработчик должен представить проект верхнего уровня ФБО.

Элементы содержания и представления свидетельств

ADV_HLD.3.1C Представление проекта верхнего уровня должно быть полуформальным.

ADV_HLD.3.2C Проект верхнего уровня должен быть внутренне непротиворечивым.

ADV_HLD.3.3C Проект верхнего уровня должен содержать описание структуры ФБО в терминах подсистем.

ADV_HLD.3.4C Проект верхнего уровня должен содержать описание функциональных возможностей безопасности, предоставленных каждой подсистемой ФБО.

ADV_HLD.3.5C Проект верхнего уровня должен идентифицировать все базовые аппаратные, программно-аппаратные и/или программные средства, требуемые для реализации ФБО, с представлением функций, обеспечиваемых поддержкой механизмов защиты, реализуемых этими средствами.

ADV_HLD.3.6C Проект верхнего уровня должен идентифицировать все интерфейсы для подсистем ФБО.

ADV_HLD.3.7C Проект верхнего уровня должен идентифицировать, какие из интерфейсов подсистем ФБО являются видимыми извне.

ADV_HLD.3.8C Проект верхнего уровня должен содержать описание назначения и методов использования всех интерфейсов подсистем ФБО, обеспечивая полную детализацию всех результатов, нештатных ситуаций и сообщений об ошибках.

ADV_HLD.3.9C Проект верхнего уровня должен содержать описание разделения ОО на подсистемы, осуществляющие ПБО, и прочие.

Элементы действий оценщика

ADV_HLD.3.1Е Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADV_HLD.3.2Е Оценщик должен сделать независимое заключение, что проект верхнего уровня - точное и полное отображение функциональных требований безопасности ОО.

ADV_HLD.4 Пояснения в полуформальном проекте верхнего уровня

Зависимости

ADV_FSP.3 Полуформальная функциональная спецификация

ADV_RCR.2 Полуформальная демонстрация соответствия

Элементы действий разработчика

ADV_HLD.4.1D Разработчик должен представить проект верхнего уровня ФБО.

Элементы содержания и представления свидетельств

ADV_HLD.4.1C Представление проекта верхнего уровня должно быть полуформальным.

ADV_HLD.4.2C Проект верхнего уровня должен быть внутренне непротиворечивым.

ADV_HLD.4.3C Проект верхнего уровня должен содержать описание структуры ФБО в терминах подсистем.

ADV_HLD.4.4C Проект верхнего уровня должен содержать описание функциональных возможностей безопасности, предоставленных каждой подсистемой ФБО.

ADV_HLD.4.5C Проект верхнего уровня должен идентифицировать все базовые аппаратные, программно-аппаратные и/или программные средства, требуемые для реализации ФБО, с представлением функций, обеспечиваемых поддержкой механизмов защиты, реализуемых этими средствами.

ADV_HLD.4.6C Проект верхнего уровня должен идентифицировать все интерфейсы для подсистем ФБО.

ADV_HLD.4.7C Проект верхнего уровня должен идентифицировать, какие из интерфейсов подсистем ФБО являются видимыми извне.

ADV_HLD.4.8C Проект верхнего уровня должен содержать описание назначения и методов использования всех интерфейсов подсистем ФБО, обеспечивая полную детализацию всех результатов, нештатных ситуаций и сообщений об ошибках.

ADV_HLD.4.9C Проект верхнего уровня должен содержать описание разделения ОО на подсистемы, осуществляющие ПБО, и прочие.

ADV_HLD.4.10C Проект верхнего уровня должен содержать строгое обоснование, что идентифицированный способ выполнения разделения, в том числе любых механизмов защиты, достаточен для обеспечения четкого и эффективного отделения функций, осуществляющих ПБО, от функций, не участвующих в осуществлении ПБО.

ADV_HLD.4.11C Проект верхнего уровня должен содержать строгое обоснование, что механизмы ФБО достаточны для реализации функций безопасности, идентифицированных в проекте верхнего уровня.

Элементы действий оценщика

ADV_HLD.4.1Е Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADV_HLD.4.2Е Оценщик должен сделать независимое заключение, что проект верхнего уровня - точное и полное отображение функциональных требований безопасности ОО.

ADV_HLD.5 Формальный проект верхнего уровня

Зависимости

ADV_FSP.4 Формальная функциональная спецификация

ADV_RCR.3 Формальная демонстрация соответствия

Элементы действий разработчика

ADV_HLD.5.1D Разработчик должен представить проект верхнего уровня ФБО.

Элементы содержания и представления свидетельств

ADV_HLD.5.1C Представление проекта верхнего уровня должно быть формальным.

ADV_HLD.5.2C Проект верхнего уровня должен быть внутренне непротиворечивым.

ADV_HLD.5.3C Проект верхнего уровня должен содержать описание структуры ФБО в терминах подсистем.

ADV_HLD.5.4C Проект верхнего уровня должен содержать описание функциональных возможностей безопасности, предоставленных каждой подсистемой ФБО.

ADV_HLD.5.5C Проект верхнего уровня должен идентифицировать все базовые аппаратные, программно-аппаратные и/или программные средства, требуемые для реализации ФБО, с представлением функций, обеспечиваемых поддержкой механизмов защиты, реализуемых этими средствами.

ADV_HLD.5.6C Проект верхнего уровня должен идентифицировать все интерфейсы для подсистем ФБО.

ADV_HLD.5.7C Проект верхнего уровня должен идентифицировать, какие из интерфейсов подсистем ФБО являются видимыми извне.

ADV_HLD.5.8C Проект верхнего уровня должен содержать описание назначения и методов использования всех интерфейсов подсистем ФБО, обеспечивая полную детализацию всех результатов, нештатных ситуаций и сообщений об ошибках.

ADV_HLD.5.9C Проект верхнего уровня должен содержать описание разделения ОО на подсистемы, осуществляющие ПБО, и прочие.

ADV_HLD.5.10C Проект верхнего уровня должен содержать строгое обоснование, что идентифицированный способ выполнения разделения, в том числе любых механизмов защиты, достаточен для обеспечения четкого и эффективного отделения функций, осуществляющих ПБО, от функций, не участвующих в осуществлении ПБО.

ADV_HLD.5.11C Проект верхнего уровня должен содержать строгое обоснование, что механизмы ФБО достаточны для реализации функций безопасности, идентифицированных в проекте верхнего уровня.

Элементы действий оценщика

ADV_HLD.5.1Е Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADV_HLD.5.2Е Оценщик должен сделать независимое заключение, что проект верхнего уровня - точное и полное отображение функциональных требований безопасности ОО.

Заключение

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

Как правило, "видимость" и "осязаемость" информационной безопасности в отсутствие некоторых специализированных мер приходят вместе с инцидентами в информационной сфере организации (инцидентами информационной безопасности), имеющими видимое влияние на основную или же управленческую деятельность последней. До тех пор пока инцидент не произошел, считается, что все нормально и нет необходимости затрачивать время и ресурсы на некую вспомогательную деятельность, результаты которой явно не ощутимы в повседневной жизни. И только в условиях активизации угроз, последствия которых могут быть в отдельных случаях катастрофическими для бизнеса организации, необходимость такой работы становится очевидной.

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

Для того, чтобы быть уверенным, что на предприятии не произойдёт утечка информации, потеря, утрата целостности либо несанкционированный доступ все программно-аппаратные средства должны быть сертифицированы. Каждому прошедшему проверку ИТ продукту присваивается должный уровень доверия. Исходя из этих данных, следует выбирать определённую модель построения защиты информации.

К примеру в приложении 1-2 приведён перечень средств защиты информации и уровень соответствия к ним. Приложении 3 сертификат соответствия №1501 операционной системы ALT Linux 4.0 Server Edition

Библиографический список

1.ГОСТ Р ИСО/МЭК 15408-3-2002. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Требования доверия к безопасности

2.Общие критерии оценки безопасности информационных технологий: Учеб. пособие/Под ред. М.Т.Кобзаря, А.А.Сидака. - М.: МГУЛ, 2001. - 81с.

Бетелин В.Б. и др. Профили защиты на основе "Общих критериев". Аналитический обзор//Инф. бюлл. Jet Info. - 2002. - N3 (118). - 32c.

3.Теоретические основы компьютерной безопасности: Учеб. пособие для ВУЗов / П.Н.Девянин, О.О.Михальский, Д.И.Правиков и др. - М.: Радио и связь, 2000. - 192 с.: ил.

4. Сидак Е.А. Общие критерии оценки безопасности информационных технологий: Учебное пособие. Перевод с английского. Под ред. М.Т. Кобзаря, А.А. Сидака. - М.: МГУЛ, 2001. - 81 с.

5. Справочная информация и сертификаты ПО - www.kation-msk.ru/ru/about/sertification

6. Электронная библиотека информационной безопасности - http://bib.pps.ru

7. Государственные стандарты - www.rgost.ru

Приложение 1

Приложение 2

Наименование	Разработчик	Оценочный уровень доверия	Заявитель сертификации	Статус
ОС Red Hat Enterprise Linux AS & WS version 4 Update 1	Корпорация IBM	4	ООО "ИБМ Восточная Европа/Азия", компания VDEL informftionstechnik & Consulting GmbH	N 925/1 от 30.11.04
Комплекс обмена сообщениями между системами и приложениями IBM WebSphere WQ v.6.0 (серия)	Корпорация IBM	2 для АС 1Г	ОАО "ЭлвисПлюс"	№ 1158 от 26.02.06
Базовая сеть передачи данных SDH1 ЗАО "Метроком" (1 экз.)	ЗАО "Метроком"	1+ (усиленный)	ЗАО "Метроком"	№ 1122 от 27.12.05
Система мониторинга и архивирования почтовых сообщений "Дозор-Джет", версия 3.0 (серия)	ЗАО "Инфосистемы Джет"	3+ (усиленный)	ЗАО "Инфосистемы Джет"	N 1037 от 05.07.05
Symantec Enterprise Firewall v. 7.0.4 (200 экз.)	Корпорация Symantec	4	Российское представительство компании Symantec Limited в Москве	N 908 от 17.05.04
CSP VPN Gate, версия 1.1 (50 экз)	ЗАО "С-Терра" СиЭсПи	3	ЗАО "С-Терра" СиЭсПи	N 941 от 29.07.04
Комплекс кодирования межсетевых потоков "Тропа-Джет", версия 2.5.0 (серия)	ЗАО "Инфосистемы Джет"	4+ (усиленный)	ЗАО "Инфосистемы Джет"	N 1036 от 05.07.05

Приложение 3

Приложение 4

Приложение 5

Размещено на Allbest.ru