Наиболее мощным современным стандартом, отражающим требования и рекомендации по обеспечению безопасности систем, содержащих программные средства, является ISO 15408 :1999 — 1-3 Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий, состоящий из трех частей. Первая часть определяет концепцию всего стандарта, а вторая самая большая часть формализует методы и требования к информационной безопасности . Его третья часть полностью посвящена процессам обеспечения доверия — (качества) компонентов информационных систем (ИС), реализующих функции их безопасности. По существу рассматривается регламентирование технологии и процессов обеспечения жизненного цикла программных средств, создаваемых для обеспечения безопасности функционирования и применения систем. При этом акцент документа сосредоточен на информационной безопасности сложных программных средств ИС. Однако основные положения этой части стандарта практически полностью применимы к технологии и процессам создания ПС и обеспечению функциональной безопасности, в том числе для встроенных систем. Поэтому ниже в данном разделе многие положения этой части стандарта трактуются с позиции обеспечения функциональной безопасности, а термин — доверие применяется как понятие качество или уверенность выполнения требования безопасности .

Основная концепция ISO 15408-3 — обеспечение доверия, основанное на оценке качества (активном исследовании реализации функций) продукта или системы [1]. Нарушения безопасности ПС возникают вследствие преднамеренного использования или случайной активизации уязвимостей при применении систем и ПС по назначению. Рекомендуется ряд шагов для предотвращения уязвимостей, возникающих в продуктах и системах. Уязвимости могут возникать вследствие недостатков :

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

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

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

Доверие — основа для уверенности в том, что продукт или система отвечают целям и требованиям безопасности. Активное исследование доверия — это оценка процесса функционирования системы для определения его свойств безопасности. Методы оценки могут, в частности, включать в себя:

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

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

Рисунок 2.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Задание по безопасности (ЗБ) — совокупность требований и спецификаций, предназначенная для использования в качестве основы для оценки конкретного объекта. Цель оценки ЗБ — показать, что оно является полным, непротиворечивым, технически правильным и поэтому пригодно для использования в качестве основы при оценке уровня безопасности соответствующей системы. Если, после тщательного рассмотрения, окажется, что ни один из компонентов требований настоящего стандарта не применим непосредственно ко всем или к части требований безопасности системы, разработчик ЗБ может сформулировать другие требования, которые не ссылаются на этот стандарт. Использование таких требований должно быть строго обосновано.

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

Не все классы и семейства настоящего стандарта включены в каждый из перечисленных ниже оценочных уровней доверия. Эти семейства рекомендуется использовать для повышения уровней доверия в тех ПЗ и ЗБ, для которых они действительно полезны и необходимы. Определены семь иерархически упорядоченных оценочных уровней доверия для ранжирования при выборе доверия к безопасности объектов оценки. (Они, в некоторой степени, подобны пяти уровням зрелости технологий в стандарте ISO 15504 — см. [4]). Каждый последующий ОУД представляет более высокое доверие (гарантированное качество), чем любой из предыдущих (ср. примеры в Таб. 1 и Таб. 2). Связь уровней доверия с классами и семействами технологических процессов обеспечения ЖЦ безопасности систем и программных средств в стандарте иллюстрированы семью таблицами. В каждой из них выделены и отмечены обязательные (белые) и рекомендуемые (остальные) классы и семейства процессов, обеспечивающие определенный уровень доверия при создании и применении методов и средств соответствующей безопасности. Эти таблицы помогают выбирать технологии в соответствии с требованиями к безопасности системы и ПС с учетом доступных ресурсов.

Таблица 1.

Класс доверия 3

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

Управление конфигурацией	Средства контроля авторизации Охват УК объекта оценки
Поставка и эксплуатация	Процедуры поставки Процедуры установки, генерации и запуска
Разработка	Неформальная функциональная спецификация Детализация вопросов безопасности в проекте верхнего уровня Неформальная демонстрация соответствия
Руководства	Руководство администратора Руководство пользователя
Поддержка жизненного цикла	Идентификация мер безопасности
Тестирование	Анализ покрытия Тестирование: проект верхнего уровня Функциональное тестирование Выборочное независимое тестирование
Оценка уязвимостей	Экспертиза руководств Оценка стойкости функции безопасности Анализ уязвимостей разработчиком

Таблица 2.

Класс доверия 7

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

Управление конфигурацией	Полная автоматизация УК Расширенная поддержка Охват УК инструментальных средств разработки
Поставка и эксплуатация	Предотвращение модификации Процедуры установки, генерации и запуска
Разработка	Формальная функциональная спецификация Формальный проект верхнего уровня Структурированная реализация функциональной безопасности Минимизация сложности Полуформальный проект нижнего уровня Формальная демонстрация соответствия Формальная модель политики безопасности
Руководства	Руководство администратора Руководство пользователя
Поддержка жизненного цикла	Достаточность мер безопасности Измеримая модель жизненного цикла Соответствие всех частей объекта оценки стандартам реализации
Тестирование	Строгий анализ покрытия Тестирование на уровне реализации Упорядоченное функциональное тестирование Полное независимое тестирование
Оценка уязвимостей	Систематический анализ скрытых каналов Анализ и тестирование опасных состояний Оценка стойкости функции безопасности Высокостойкий

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

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

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

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

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

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

Оценочный уровень доверия 7 (ОУД7 — Таб. 2) — применим при разработке безопасных систем для использования в ситуациях чрезвычайно высокого риска и/или там, где высокая ценность активов или систем оправдывает максимальные затраты на их безопасность. Практическое применение уровня ограничено системами, которые строго ориентированы на реализацию полных функциональных возможностей безопасности, для которых возможен и целесообразен подробный формальный анализ. Уровень обеспечивает качество посредством использования всех представленных выше классов и семейств, а также процессов предшествующих уровней, структурированного процесса разработки, средств контроля среды разработки и всестороннего управления конфигурацией системы, включая полную автоматизацию, и свидетельства безопасных процедур поставки (см. Рис. 2). Этот уровень представляет значительное увеличение доверия, требует всестороннего анализа, использующего формальные представления и формальное соответствие, а также всестороннее независимое тестирование.

содержание       назад       вперед