Оценка характеристик безопасности в рамках процесса оценки качества программных средств в соответствии с международными стандартами ISO/IEC

11:13 / 16 сентября, 2005

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

Автор: Полаженко Сергей, ведущий проекта «Тестирование безопасности»

Введение

Требования к качеству программных средств (ПС) всё время повышаются, программы должны быть не только надёжными, удобными для работы, простыми для изучения и т.д. — пользователь хочет иметь гарантии того, что он может доверять программе свои данные. Это означает, что реализация требований безопасности при разработке ПС является одной из составных частей общей проблемы обеспечения их качества. Так, например, последний пакет обновлений для операционной системы Windows XP продемонстрировал то, что обеспечение безопасности становится приоритетным направлением компании Microsoft.

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

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

Одним из подходов для оценки атрибутов безопасности разрабатываемого ПС является оценка соответствующих атрибутов качества, связанных с безопасностью, определённых в серии международных стандартов ISO/ IEC 9126 «Software engineering — Product quality» и ISO/ IEC 14598 «Software engineering — Product evaluation».

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

Кратко опишем подход к оценке качества, определённый стандартами.

Примечание: В статье большинство переводов англоязычных терминов взято в редакции ранее опубликованной работы Липаева В.В. Стандартизация характеристик и оценивания качества программных средств. — Приложение к журналу «Информационные технологии», 2001, № 4

[ Содержание ]

Модель характеристик качества

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

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

Рисунок 1. — Качество в жизненном цикле ПС

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

Рисунок 2. — Различные подходы к качеству ПС и соответствующим метрикам качества.

[ Содержание ]

Характеристики качества

Модель внутренних и внешних характеристик качества ПС состоит из шести групп базовых показателей, каждая из которых детализирована несколькими нормативными субхарактеристиками:

функциональная пригодность;
1. пригодностью для применения;
2. корректностью (правильностью, точностью);
3. способностью к взаимодействию;
4. защищенностью;
надежность;
1. уровнем завершенности (отсутствия ошибок);
2. устойчивостью к дефектам;
3. восстанавливаемостью;
4. доступностью;
5. готовностью;
эффективность;
1. временной эффективностью;
2. используемостью ресурсов;
применимость;
1. понятностью;
2. простотой использования;
3. изучаемостью;
4. привлекательностью;
сопровождаемость;
1. удобством для анализа;
2. изменяемостью;
3. стабильностью;
4. тестируемостью;
переносимость;
1. адаптируемостью;
2. простотой установки (инсталляции);
3. сосуществованием (соответствием);
4. замещаемостью.

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

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

системная эффективность применения программного продукта (ПП) по назначению;
продуктивность ;
безопасность;
удовлетворение требований и затрат пользователей в соответствии с целями применения ПС.

[ Содержание ]

Безопасность и качество

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

Характеристика как внутреннего, так и внешнего качества «защищённость» используется в стандартах в значении: способность ПП защищать информацию и данные так, чтобы неавторизованные субъекты или процессы не смогли читать или модифицировать их, а авторизованным пользователям и процессам не было отказано в доступе к ним. В стандартах подчеркивается, что данное требование также относится и к данным, которые находятся в процессе пересылки.

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

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

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

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

Таблица – Метрики субхарактеристик внешнего и внутреннего качества «защищённость» и качества в использовании «безопасность»:

Метрика	Формула	Примечания из стандарта
1. Внешние метрики безопасности: 1.1 протоколирование доступа;	Х = А / В; А = число «фактов доступа пользователя к системе и данным», зафиксированных в протоколе системы; В = число «фактов доступа пользователя к системе и данным», которые были произведены во время оценки;	1. рекомендуется использовать «тесты на проникновения» для эмуляции атак на систему; 2. под записью протокола «факт доступа пользователя к системе и данным» может подразумеваться запись «факт обнаружения вируса» для обеспечения антивирусной безопасности системы; 3. метрика носит экспериментальный характер;
1.2 контролируемость доступа;	Х = А / В; А = число обнаруженных видов несанкционированного доступа; В = число видов несанкционированного доступа в спецификации;	1. необходимо проверить способность системы определять факты несанкционированного доступа при неправильном применении функций системы; 2. рекомендуется использовать «тесты на проникновения» для эмуляции атак на систему; 3. метрика носит экспериментальный характер;
1.3 предотвращение повреждения данных;	а) Х = 1 – А / N; A = число фактов существенного повреждения данных; N = число видов тестов, при помощи которых пытались спровоцировать факт повреждения данных; b) Y = 1 – B / N; B = число фактов незначительного повреждения данных; c) Х = A / T или B / T; T = время выполнения операции;	1. необходимо проверить корректность работы системы при неправильном применении её функций; 2. необходимо построить классификацию эффекта от событий повреждения данных; 3. для вычисления внешних метрик следует использовать информацию, доступную извне системы. Порядок подсчёта событий здесь отличается от порядка подсчёта событий при оценке аналогичных внутренних данных; 4. рекомендуется использовать «тесты на проникновения» для эмуляции атак на систему; 5. метрика носит экспериментальный характер; 6. Резервирование данных – один из наиболее эффективных способов предотвращения фактов повреждения данных, однако, резервирование данных относится к метрике «надёжность».
2. внутренние метрики безопасности: 2.1 протоколирование доступа;	Х = А / В; А = число типов доступа, которые были зарегистрированы корректно, как определено в спецификации; В = число типов доступа, которые должны регистрироваться по спецификации;
2.2 контроль доступа;	Х = А / В; А = число требований контроля доступа, реализованных корректно, в соответствии со спецификацией; В = число требований контроля доступа в спецификации;
2.4 предотвращение повреждения данных;	Х = А / В; А = число реализованных механизмов защиты от повреждения данных; В = число механизмов, требуемых по спецификации;	необходимо учитывать уровни безопасности при использовании этой метрики;
2.5 криптографическая защита данных;	Х = А / В; А = число реализованных механизмов; В = число требуемых механизмов по спецификации;	криптографическая защита данных может касаться, например, данных в открытых базах данных или общедоступных данных.
3. метрики безопасности качества в использовании: 3.1 безопасность пользователей и их здоровья;	Х = 1 – А / В; А = число пользователей, сообщивших о наличии проблем; В = число пользователей;	Проблемы со здоровьем могут включать: травмы от многократно повторяющихся мышечных напряжений, утомление, головная боль и т.д.;
3.2 безопасность людей, задействованных в использовании системы;	Х = 1 – А / В; А = число людей, подверженных риску; В = число людей, задействованных в использовании продукта;
3.3 экономический ущерб;	Х = 1 – А / В; А = число событий экономического ущерба; В = общее число использования системы;	также можно учитывать ситуации, где был риск экономического ущерба;
3.4 повреждение прочего ПО;	Х = 1 – А / В; А = число событий повреждения прочего ПО; В = общее число использования системы;	также можно учитывать ситуации, где был риск повреждения прочего ПО; метрика также может быть вычислена как Х = суммарная стоимость повреждённого ПО / время использования.

[ Содержание ]

Методология оценки характеристик

Методологии оценивания характеристик качества готовых ПП на различных этапах жизненного цикла посвящен международный стандарт ISO / IEC 14598-1-6:1998-2001 «Software engineering — Product evaluation» (Оценивание программного продукта ), состоящий из шести частей:

Часть 1. 1999. Общий обзор.

Часть 2. 2000. Планирование и управление.

Часть 3. 2000. Процесс для разработчиков.

Часть 4. 1999. Процесс для приобретателей.

Часть 5. 1998. Процесс для оценщиков (испытателей).

Часть 6. 2001. Документирование оценки модулей.

Рисунок 3. — Взаимосвязь стандартов ISO/IEC 9126 и 14598

Методология оценки характеристик безопасности ПП в соответствии со стандартом ISO/ IEC 14598 в общем виде будет представлять следующее:

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

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

[ Содержание ]

Заключение

Ниже перечислены основные преимущества и недостатки рассматриваемого подхода.

Преимущества:

подход обращает внимание участников разработки ПО на необходимость учёта требований реализации безопасного ПО;
возможность применения для оценки качества как для разработанного ПО, так и для ПО, находящегося в процессе разработки;
подход представляет базу для разработки собственной методики оценки качества характеристик безопасности разрабатываемого ПО, и использования её для взаимодействия с заказчиками и оценщиками;
возможность планировать и контролировать значения метрик безопасности в случае реализации ПО в ограниченные сроки или при ограниченном бюджете проекта;
ряд метрик в стандартах необходимо вычислять экспериментальным путём (использование «тестов на проникновение»), что обычно не практикуется в случае обычного функционального тестирования ПО, где происходит тестирование функций в соответствии со спецификацией;
интеграция со всем процессом разработки ПО в соответствии с их жизненным циклом ( ISO/ IEC 12207), а также родственными стандартами ISO 9000-9001, которые уже сейчас активно применяются в странах СНГ;

Недостатки:

не учтена специфика разрабатываемого ПО (угрозы действующие на функции ПО, величины рисков этих угроз, величины возможных ущербов);
стандартный набор метрик не может в полной мере характеризовать качество безопасности разрабатываемого ПО и требуется расширение набора;
подход применяется для оценки качества безопасности ПО, но не даёт гарантий безопасности, однако может давать хороший материал для анализа, в случае проведения оценки защищённости в соответствии с ISO/ IEC 15408 («Общие критерии»). С другой стороны, в случае, если наряду с данным подходом применяется также и ISO/ IEC 15408 (имеется профиль защиты или задание на обеспечение безопасности ПО или системы, в состав которой входит данное ПО), то подход на базе «Общих критериев» может предоставить возможность для более точного определения необходимых метрик безопасности и более гибкого контроля их значений.

Следует отметить, что предыдущие версии такого стандарта как ISO/ IEC 9126:1991 уже приняты в качестве национальных в ряде стран СНГ, так например, РБ — СТБ ИСО/МЭК 9126-2003 «Информационные технологии. Оценка программной продукции. Характеристики качества и руководства по их применению»; РФ — ГОСТ Р ИСО/МЭК 9126-93) — «Информационная технология. Оценка программного продукта. Характеристики качества и руководство по их применению», что говорит о высокой заинтересованности национальных нормотворческих органов в поддержке подходов, рекомендуемых стандартами ISO/ IEC.

[ Содержание ]