Требования адекватности

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

Таксономия требований адекватности "Единых критериев" представлена на рис. 3.16.

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

Уровень 1. Функциональное тестирование.

Уровень 2. Структурное тестирование.

Уровень 3. Методическое тестирование и проверка.

Уровень 4. Методическая разработка, тестирование и анализ.

Уровень 5. Полуформальные методы разработки и тестирование.

Уровень 6. Полуформальные методы верификации разработки и тестирование.

Уровень 7. Формальные методы верификации разработки и тестирование.

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

Уровень 1. Функциональное тестирование предназначено для тех случаев, когда угрозам безопасности не придается большого значения. Предлагается использовать его в тех ситуациях, когда все что требуется – это независимая гарантия того, что в состав продукта входят средства за щиты персональной или подобной информации, реализованные в соответствии с указанными требованиями.

Рис. 3.16. Таксономия требований адекватности «Единых критериев»

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

Результаты анализа подтверждаются независимым тестированием средств защиты ИТ–продукта на соответствие спецификациям и документации.

Сертификация ИТ–продукта на данный уровень адекватности является подтверждением соответствия свойств ИТ–продукта его документации и спецификациям, а также наличия работоспособной защиты против угроз безопасности.

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

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

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

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

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

Уровень 3. Методическое тестирование применяется тогда, когда потребителям или пользователям требуются умеренная степень независимого подтверждения свойств ИТ–продукта, а также полное и последовательноеисследование свойств продукта и контроль в процессе создания, но без проведения дорогостоящего обратного проектирования (reengineering).

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

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

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

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

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

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

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

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

Уровень 5. Полуформальные методы разработки и тестирование рекомендуется применять в том случае, когда разработчики или пользователи требуют высокой степени независимого подтверждения адекватности средств зашиты, а также строгого применения определенных технологий разработки ИТ–продукта, но без чрезмерных затрат.

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

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

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

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

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

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

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

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

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

Требования к процессу разработки расширяются необходимостью структурирования этого процесса и полной автоматизации управления конфигурацией проекта.

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

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

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

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

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

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

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

Разработчики "Единых критериев" продолжили подход "Федеральных критериев", направленный на отказ от единой шкалы безопасности, и усилили гибкость предложенных в них решений путем введения частично упорядоченных шкал, благодаря чему потребители и производители получили дополнительные возможности по выбору требований и их адаптации к свои прикладным задачам.

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

Таким образом, требования "Единых критериев" охватывают практически все аспекты безопасности ИТ–продуктов и технологии их создания, а также содержат все исходные материалы, необходимые потребителям и разработчикам для формирования Профилей и Проектов защиты.

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

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

С 2004 года в России введен ГОСТ Р МЭК/ИСО 15408, определяющий критерии оценки безопасности ИТ и являющийся адаптированным к Российским условиям аналогом стандарта ISO/IEC 15408 – единых критериев безопасности ИТ (ОК). Он является действующим наряду с ранее изданными РД ГосТехКомиссии, определяющими критерии оценки безопасности средств вычислительной техники и автоматизированных систем.