02. Международные стандарты по оценке информационной безопасности

2.1. Роль стандартов в сфере ИБ

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

Цель стандарта - обеспечение:
- необходимого уровня качества товаров и услуг;
- единых характеристик товаров и услуг.

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

В зависимости от статуса стандарты делятся на:
- международные - принятые международной организацией по стандартизации;
- региональные - принятые региональной организацией по стандартизации;
- национальные - принятые национальным органом стандартизации;
- ведомственные - принятые органом стандартизации определенного ведомства.

В зависимости от специфики объекта стандартизации установлены следующие виды стандартов:

- основополагающий стандарт - имеет широкую сферу распространения или содержащий общие положения для определенной области (организационно-методические, общетехнические и терминологические);

- стандарт на методы (методики) испытания (измерения, анализа, контроля) - устанавливает методы испытания, например, использование статистических методов и порядок проведения испытаний;

- стандарт на продукцию - устанавливает требования, которым должно удовлетворять изделие (группа изделий), чтобы обеспечить свою соответствие назначению;

- стандарт на процесс - устанавливает требования, которым должен удовлетворять процесс, чтобы обеспечить свое соответствие назначению;

- стандарт на услугу - устанавливает требования, которым должна удовлетворить услуга, чтобы обеспечить свое соответствие назначению;

- стандарт на совместимость - устанавливает требования к совместимости продукции, услуг или систем при их одновременном использовании;

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

Стандартизация в области ИБ необходима для выработки единства:
- требований по ИБ;
- подходов к решению проблем ИБ;

- качественных показателей для оценки ИБ.

Основными областями стандартизации ИБ являются:
- управление ИБ;
- аудит ИБ;
- методы обеспечения ИБ;
- криптография и др.

Потребители (заказчики) продуктов информационных технологий без стандартов не смогут сформулировать свои требования по ИБ производителям ИС (нужны какие-то критерии, показатели, единицы измерения ИБ и т.д.).

Производители продукции ИТ и средств защиты (программных, технических) нуждаются в стандартах для того, чтобы можно было бы объективно оценить свою продукцию с точки зрения обеспечения ИБ, то есть СЕРТИФИЦИРОВАТЬ ее. Им также необходим стандартный набор требований для того, чтобы ограничить фантазию заказчика и заставить выбирать конкретные требования из этого набора.

Стандарты нужны экспертам по ИБ и специалистам по сертификации как инструмент для оценки уровня ИБ, обеспечиваемого конкретными механизмами и средствами защиты информации (техническими, программными и т.д.) либо комплексами таких средств.

Международные организации по стандартизации, входящие в структуру ООН:

- ISO (International Organization for Standardization - Международная организация по стандартизации) - серии стандартов ISO;

- IEC (International Electrotechnical Commission - Международная электротехническая комиссия) - серии стандартов IEC;

- ITU-T (International Telecommunication Union - Telecommunications - Международный союз по телекоммуникации) - стандарты серии X (сети передачи данных, взаимосвязь открытых систем и безопасность).

В настоящее время существует довольно много стандартов, а также других нормативных и руководящих документов в области ИБ. Все их рассмотреть в рамках данного курса не представляется возможным. Поэтому мы будем рассматривать только базовые стандарты в области ИБ, которыми руководствуются при создании, сертификации и эксплуатации СУИБ.

Эти стандарты можно разбить на две группы.

1 группа - оценочные стандарты. Они предназначены для оценки и классификации ИС и средств защиты информации по требованиям безопасности. Ими руководствуются для того, чтобы ответить на вопрос: соответствует ли ИС и средства защиты требованиям ИБ?

Наименование стандарта

Год

Страна

Обозн.

1

Критерии оценки доверенной компьютерной системы (Trusted Computer System Evaluation Criteria, TCSEC)

1985

США

Оранжевая книга

2

Критерии оценки безопасности информационных технологий (Information Technology Security Evaluation Criteria, ITSEC)

1991

Франция, Германия, Великобритания, Нидерланды

Белая книга

3

Федеральные критерии безопасности информационной технологии (Federal Criteria for Information Technology Security)

1993

США

 

4

Канадские критерии оценки доверенного компьютерного продукта (Canadian Trusted Computer Product Evaluation Criteria)

1993

Канада

 

5

Общие критерии безопасности информационной технологии (Common Criteria for Information Technology Security Evaluation, CCITSE)

1996

США, Канада, Франция, Великобритания, Нидерланды

Общие критерии

6

Критерии оценки безопасности информационной технологии (Evaluation Criteria for Information Technology Security)

1999

ISO/IEC

15408

2 группа - так называемые спецификации. Они регламентируют различные вопросы реализации и использования методов и средств защиты информации. Ими руководствуются для того, чтобы ответить на вопрос: Как обеспечить ИБ, какие подходы, методы и средства необходимо для этого использовать?

Наименование стандарта

Год

Страна

Обозн.

1

Архитектура безопасности для взаимодействия открытых систем (Security architecture for Open Systems Interconnection)

1991

ITU-Т

Х.800

2

Свод практических правил УИБ (Code of Practice for Information Security Management)

1995

Великобритания

BS 7799

3

Свод практических правил УИБ

2000

ISO/IEC

17799

4

СУИБ. Свод норм и правил УИБ

2005

ISO/IEC

27002

5

СУИБ. Требования

2005

ISO/IEC

27001

Далее мы рассмотрим более подробно вышеназванные стандарты.

2.2. «Оранжевая книга» (TCSEC)

История стандартизации ИБ началась в январе 1981 года созданием Центра компьютерной безопасности Министерства обороны США, перед которым была поставлена задача определения пригодности предлагаемых различными разработчиками компьютерных систем. Позднее, в сентябре 1985 года, этот центр был переименован в Национальный центр компьютерной безопасности США (англ. National Computer Security Center, NCSC).

В 1983 году центром был разработан стандарт «Критерии оценки доверенных компьютерных систем» (англ. Trusted Computer System Evaluation Criteria, TCSEC), по цвету своей обложки более известный как «Оранжевая книга», который стал первым в истории общедоступным оценочным стандартом ИБ.

Разработка и публикация «Оранжевой книги» стали важнейшей вехой в становлении теории ИБ. Такие базовые понятия, как «политика безопасности», «монитор безопасности обращений» или «администратор безопасности» впервые в открытой литературе появились именно в «Оранжевой книге».  Согласно «Оранжевой книге» доверенная система должна обеспечить одновременную обработку информации разной степени секретности группой пользователей без нарушения прав доступа.

Доверенность систем оценивается по двум основным критериям:

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

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

2. Гарантированность - мера доверия, которая может быть оказана архитектуре и реализации ИС.

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

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

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

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

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

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

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

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

Согласно «Оранжевой книге» политика безопасности должна включать в себя:
- произвольное и принудительное управление доступом;
- метки безопасности;
- безопасность повторного использования объектов.

Произвольное управление доступом основано на учете личности субъекта или группы, в которую субъект входит. Произвольность управления состоит в том, что некоторое лицо (обычно владелец объекта) может по своему усмотрению предоставлять другим субъектам или отбирать у них права доступа к объекту.

Принудительное управление доступом основано на сопоставлении меток безопасности субъекта и объекта. Метка субъекта описывает его благонадежность, метка объекта - степень конфиденциальности содержащейся в нем информации.

Согласно «Оранжевой книге» метки безопасности состоят из двух частей - уровня секретности и списка категорий. Уровни секретности образуют упорядоченное множество, категории - неупорядоченное. Назначение последних - описать предметную область, к которой относятся данные.

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

Субъект может записывать информацию в объект, если метка безопасностио объекта доминирует над меткой субъекта. В частности, «конфиденциальный» субъект может записывать данные в секретные файлы, но не может - в несекретные (разумеется, должны также выполняться ограничения на набор категорий).

Описанный способ управления доступом потому и называется принудительным, поскольку он не зависит от воли субъектов (даже системных администраторов). После того, как зафиксированы метки безопасности субъектов и объектов, оказываются зафиксированными и права доступа.

Безопасность повторного использования объектов - свойство управления доступом, предохраняющее от извлечения (случайного или преднамеренного) конфиденциальной информации из «мусора». Такая безопасность должна гарантироваться для областей оперативной памяти (в частности, для буферов с образами экрана, расшифрованными паролями и т.п.), для дисковых блоков и носителей в целом.

Если понимать политику безопасности узко, т.е. как правила разграничения доступа, то механизм подотчетности является дополнением подобной политики. Цель подотчетности - в каждый момент времени знать, кто работает в ИС и что делает.

Средства подотчетности ИС делятся на 3 категории:
- идентификация и аутентификация;
- предоставление доверенного пути;
- анализ регистрационной информации.

Кроме того, «Оранжевая книга» определяет 4 уровня доверенности (безопасности) ИС - D, C, B и A (по возрастанию от D к A). Уровень D предназначен для систем, признанных неудовлетворительными. С учетом нашей 5-балльной шкалы оценки, получим следующие уровни безопасности с оценкой: 2(D), 3(C), 4(B), 5(A).

По мере перехода от уровня C к A к надежности систем предъявляются все более жесткие требования. Уровни C и B подразделяются на классы (C1, C2, B1, B2, B3) с постепенным возрастанием надежности. Таким образом, «Оранжевая книга» определяет 6 классов безопасности: C1, C2, B1, B2, B3, A1.

Требуемый уровень безопасности ИС возрастает от группы D к группе А, а в пределах одной группы - с увеличением номера класса. Каждый класс характеризуется определённым фиксированным набором требований к подсистеме обеспечения ИБ, реализованной в ИС.

1. Группа С - Discretionary Protection (избирательная защита) - объединяет ИС, обеспечивающие набор средств защиты, применяемых пользователем, включая средства общего контроля и учета субъектов и их действий.

Эта группа имеет два класса:

1) класс С1 - Discretionary Security Protection (избирательная защита безопасности) - объединяет ИС с разделением пользователей и данных;

2) класс С2 - Controlled Access Protection (защита контролируемого доступа) - объединяет ИС, обеспечивающие более тонкие средства защиты по сравнению с ИС класса С1, делающие пользователей индивидуально различимыми в их действиях посредством процедур контроля входа и контроля за событиями, затрагивающими безопасность ИС и изоляцию данных.

2. Группа В - Mandatory Protection (полномочная защита) - имеет три класса:

1) класс В1 - Labeled Security Protection (меточная защита безопасности) - объединяет ИС, удовлетворяющие всем требованиям класса С2, дополнительно реализующие заранее определенную модель безопасности, поддерживающие метки субъектов и объектов, полный контроль доступа. Вся выдаваемая информация регистрируется, все выявленные при тестировании недостатки должны быть устранены;

2) класс В2 - Structured Protection (структурированная защита) - объединяет ИС, в которых реализована четко определенная и задокументированная формализованная модель обеспечения безопасности, а меточный механизм разделения и контроля доступа, реализованный в системах класса В1, распространен на всех пользователей, все данные и все виды доступа. По сравнению с классом В1 ужесточены требования по идентификации пользователей, контролю за исполнением команд управления, усилена поддержка администратора и операторов системы. Должны быть проанализированы и перекрыты все возможности обхода защиты. ИС класса В2 считаются «относительно неуязвимыми» для несанкционированного доступа;

3) класс В3 - Security Domains (области безопасности) - объединяет ИС, имеющие специальные комплексы безопасности. В ИС этого класса должен быть механизм регистрации всех видов доступа любого субъекта к любому объекту. Должна быть полностью исключена возможность несанкционированного доступа. Система безопасности должна иметь небольшой объем и приемлемую сложность для того, чтобы пользователь мог в любой момент протестировать механизм безопасности. ИС этого класса должны иметь средства поддержки администратора безопасности; механизм контроля должен быть распространен вплоть до сигнализации о всех событиях, затрагивающих безопасность; должны быть средства восстановления системы. ИС этого класса считаются устойчивыми к несанкционированному доступу.

3. Группа А - Verified Protection (проверяемая защита) - объединяет ИС, характерные тем, что для проверки реализованных в системе средств защиты обрабатываемой или хранимой информации применяются формальные методы. Обязательным требованием является полная документированность всех аспектов проектирования, разработки и исполнения ИС.

Выделен единственный класс А1 - Verified Desing (проверяемая разработка) - объединяющий системы, функционально эквивалентные системам класса В3 и не требующие каких-либо дополнительных средств. Отличительной чертой ИС этого класса является анализ формальных спецификаций проекта системы и технологии исполнения, дающий в результате высокую степень гарантированности корректного исполнения ИС. Кроме этого, системы должны иметь мощные средства управления конфигурацией и средства поддержки администратора безопасности.

Основное содержание требований по классам безопасности приведено в таблице.

Требования

Классы

С1

C2

B1

B2

B3

A1

1. Требования к политике безопасности

1.1. Произвольное управление доступом

+

+

=

=

+

=

1.2. Повторное использование объектов

+

=

=

=

=

1.3. Метки безопасности

+

+

=

=

1.4. Целостность меток безопасности

+

+

=

=

1.5. Принудительное управление доступом

+

+

=

=

2. Требования к подотчетности

2.1. Идентификация и аутентификация

+

+

+

=

=

=

2.2. Предоставление надежного пути

+

+

=

2.3. Аудит

+

+

+

+

=

3. Требования к гарантированности

3.1. Операционная гарантированность

           

3.1.1. Архитектура системы

+

+

+

+

+

=

3.1.2. Целостность системы

+

=

=

=

=

=

3.1.3. Анализ тайных каналов передачи информации

+

+

+

3.1.4. Надежное администрирование

+

+

=

3.1.5. Надежное восстановление

+

=

3.2. Технологическая гарантированность

           

3.2.1. Тестирование

+

+

+

+

+

+

3.2.2. Верификация спецификаций архитектуры

+

+

+

+

3.2.3. Конфигурационное управление

+

=

+

3.2.4. Надежное распространение

+

4.Требования к документации

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

+

=

=

=

=

=

4.2. Руководство администратора по средствам безопасности

+

+

+

+

+

+

4.3. Тестовая документация

+

=

=

+

=

+

4.4. Описание архитектуры

+

=

+

+

+

+

Обозначения: «» - нет требований к данному классу;
                         «+» - новые или дополнительные требования;
                         «=» - требования совпадают с требованиями предыдущего класса.

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

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

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

2.3. Общие критерии - ISO/IEC 15408

В 1990 году рабочая группа WG3 подкомитета SC27 объединенного технического комитета JTC1 Международной организации по стандартизации (ISO) и Международной электротехнической комиссии (IEC) приступила к разработке «Критериев оценки безопасности информационной технологии» (англ. Evaluation Criteria for IT Security, ECITS).

Несколько позже, в 1993 году, правительственные организации 6 стран - Канады, США, Великобритании, Германии, Нидерландов и Франции - занялись составлением так называемых «Общих критериев оценки безопасности информационных технологий» (англ. Common Criteria for IT Security Evaluation, СCITSЕ). За этим документом исторически закрепилось более короткое название – Общие критерии (ОК). Официальный сайт ОК находится тут.

В 1996 году появилась первая версия ОК, которая была одобрена ISO/IEC. В результате совместных усилий всех заинтересованных сторон 1 декабря 1999 года был введен в действие международный стандарт ISO/IEC 15408-1999 «Критерии оценки безопасности информационной технологии».

В России стандарт был принят как национальный в 2002 году и введён в действие с 1 января 2004 года. Сейчас действует ГОСТ Р ИСО/МЭК 15408-2008 на базе ISO/IEC 15408-2005. Однако в Украине этот стандарт как национальный не принят до сих пор.

В данный момент действующей является версия 3.1 ОК (вариант 4), принятая в сентябре 2012 года, а последняя версия международного стандарта ISO/IEC 15408 принята в 2009 году.

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

Стандарт устанавливает основные понятия и принципы оценки безопасности ИТ, а также определяет общую модель оценки, которой посвящены различные части стандарта, предназначенного в целом для использования в качестве основы при оценке характеристик безопасности продуктов ИТ. Стандарт ISO/IEC 15408 состоит из трех частей.

Часть 1 «Введение и общая модель» устанавливает общий подход к формированию требований безопасности и оценке безопасности, на их основе разрабатываются основные конструкции (профиль защиты и задание по безопасности) представления требований безопасности в интересах потребителей, разработчиков и оценщиков продуктов и систем ИТ. Требования безопасности объекта оценки (далее - ОО) по методологии стандарта определяются, исходя из целей безопасности, которые основываются на анализе назначения ОО и условий среды его использования (угроз, предположений, политики безопасности).

Часть 2 «Функциональные требования безопасности» содержит универсальный каталог функциональных требований безопасности (далее - ФТБ) и предусматривает возможность их детализации и расширения по определенным правилам.

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

Обобщая вышесказанное, можно отметить, что каркас безопасности, за­ложенный частью 1 стандарта, заполняется содержимым из классов, семейств и компонентов в части 2, а часть 3 определяет, как оценить прочность всего «строения».

Основные идеи стандарта

Под ОО понимается набор программных, программно-аппаратных и/или аппаратных средств, возможно сопровождаемых руководствами. В оценке характеристик безопасности ОО заинтересованы в основном 3 группы пользователей: потребители, разработчики и оценщики. 

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

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

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

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

Многие активы представлены в виде информации, которая хранится, обрабатывается и передается продуктами ИТ таким образом, чтобы удовлетворить требования владельцев этой информации. Владельцы информации вправе требовать, чтобы доступность, распространение и модификация любой такой информации строго контролировались и активы были защищены от угроз контрмерами. Рисунок иллюстрирует высокоуровневые понятия безопасности и их взаимосвязь.

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

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

Далее в ЗБ контрмеры делятся на две группы:

- цели безопасности для ОО: они описывают контрмеры, корректность которых будет определяться при оценке;

- цели безопасности для среды функционирования: они описывают контрмеры, корректность которых не будет определяться при оценке.

В ЗБ для ОО, корректность контрмер ИТ которого будут оценивать в процессе оценки, требуется дальнейшая детализация целей безопасности для ОО в функциональных требованиях безопасности (далее - ФТБ).

Таким образом, в ЗБ демонстрируется, что:

- ФТБ удовлетворяют целям безопасности для ОО;

- цели безопасности для ОО и цели безопасности для среды функционирования противостоят угрозам;

- и ФТБ, и цели безопасности для среды функционирования противостоят угрозам.

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

Для определения корректности ОО могут выполняться различные виды деятельности, такие как:
- тестирование ОО;
- исследование различных проектных представлений ОО;
- исследование физической безопасности среды разработки ОО.

ЗБ обеспечивает структурированное описание этих видов деятельности для определения корректности в форме требований доверия к безопасности (далее - ТДБ). По стандарту признают два типа оценки: оценка ЗБ/ОО и оценка ПЗ.

Оценка ЗБ/ОО проходит в два этапа:
- оценка ЗБ: на этом этапе определяют достаточность ОО и среды функционирования;
- оценка ОО: на этом этапе определяют корректность ОО; как отмечалось ранее, оценка ОО не включает оценку корректности среды функционирования.

Результатом процесса оценки ОО будет:
- либо утверждение, что не все ТДБ удовлетворены, и поэтому не достигнут заданный уровень доверия к тому, что ОО удовлетворяет ФТБ, которые изложены в ЗБ;
- либо утверждение, что все ТДБ удовлетворены, и поэтому достигнут заданный уровень доверия к тому, что ОО удовлетворяет ФТБ, которые изложены в ЗБ.

Чтобы дать возможность заинтересованным группам или сообществам потребителей выразить свои требования безопасности и облегчить разработку ЗБ, стандарт предоставляет две специальные конструкции: пакеты и ПЗ. Пакет - это определенный набор требований безопасности.

Пакеты могут быть двух видов, содержащих:
- только ФТБ;
- только ТДБ.

В то время, как ЗБ всегда описывает конкретный ОО (например, межсетевой экран Х-2, версия 3.1), ПЗ предназначен для описания типа ОО (например, межсетевые экраны прикладного уровня). Поэтому один и тот же ПЗ можно использовать в качестве шаблона для множества различных ЗБ, которые будут использовать в различных оценках.

Обычно ЗБ описывает требования для ОО и его формирует разработчик ОО, в то время как ПЗ описывает общие требования для некоторого типа ОО.

Поэтому ПЗ обычно разрабатывается:

- сообществом пользователей, стремящихся прийти к консенсусу относительно требований для данного типа ОО;

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

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

ПЗ определяет допустимый тип соответствия ЗБ профилю защиты. То есть в ПЗ устанавливают, какие типы соответствия являются допустимыми для ЗБ, а именно:

- если в ПЗ установлено, что требуется «строгое соответствие», то ЗБ должно в строгой форме соответствовать ПЗ;

- если в ПЗ установлено, что требуется «демонстрируемое соответствие», то ЗБ должно либо строго соответствовать ПЗ, либо его соответствие ПЗ может быть продемонстрировано.

Ожидаемые результаты оценки ПЗ и ЗБ/ОО:
- оценки ПЗ позволяют создавать каталоги (реестры) оцененных ПЗ;
- оценка ЗБ дает промежуточные результаты, которые затем используются при оценке ОО;
- оценки ЗБ/ОО позволяют создавать каталоги (реестры) оцененных ОО.

Необходимо, чтобы оценка приводила к объективным и повторяемым результатам, на которые затем можно ссылаться как на свидетельство даже при отсутствии абсолютно объективной шкалы для представления результатов оценки безопасности ИТ. Наличие совокупности критериев оценки является необходимым предварительным условием для того, чтобы оценка приводила к значимому результату, предоставляя техническую основу для взаимного признания результатов оценки различными органами оценки.

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

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

----------------------------------------------------------------------------------------------------

Книга | Автор | Статьи | Фильмы | Фото | Ссылки | Отзывы

Контакт | Студентам | Ветеранам | Астрология | Карта сайта



Рейтинг@Mail.ru Яндекс.Метрика