Информационная технология

УРОВНИ ЦЕЛОСТНОСТИ СИСТЕМ И ПРОГРАММНЫХ СРЕДСТВ

И манне официальное

ГОССТАНДАРТ РОС СИИ Москва

Предисловие

1    РАЗРАБОТАН И ВНЕСЕН Всероссийским научно-исследовательским институтом стандартизации (ВНИИстанларт) Госстандарта России

2    ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от II июня 2002 г. № 237-ст

3    Настоящий стандарт содержит полный а>тснтичный текст международного стандарта ИСО/МЭК 15026—98 «Информационная технология. Уровни целостности систем и программных средств»

4    ВВЕДЕН ВПЕРВЫЕ

© ИПК Издательство стандартов. 2002

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

ГОСТ I» ИСО/МЭК 15026-2002

Содержание

1    Область применения……………………………………………….. I

2    Нормативные ссылки………………………………………………. I

3    Определения…………………………………………………….. 2

4    Символы и сокращении……………………………………………… 3

5    Основы уровней целостности программных средств………………………….. 3

5.1    Использование настоящего стандарта………………………………… 3

5.2    Обзор……………………………………………………… 3

6    Установление уровня целостности системы………………………………… 6

6.1    Анализ риска………………………………………………… 6

6.2    Оценка риска………………………………………………… 7

6.3    Присвоение уровня целостности системы……………………………… 7

7    Установление уровня целостности программного средства……………………… 8

7.1    Предпосылки при установлении уровня целостности программного средства……… 8

7.2    Понижение уровня целостности программного средства……………………. 8

7.3    Понижение уровня целостности для программных средств, отказ которых может привести к угрозе…………………………………………………….. 9

7.4    Понижение уровня целостности для программных средств, отказ которых может привести к снижению возможностей функций амортизации………………………… 9

8    Установление требований к целостности программного средства………………….10

8.1    Степень достоверности…………………………………………..10

8.2    Методы обеспечения степени достоверности программного средства……………10

8.3    Связь степени достоверности программного средства с уровнем его целостности……II

III

ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационная технология

УРОВНИ ЦЕЛОСТНОСТИ СИСТЕМ И ПРОГРАММНЫХ СРЕДСТВ

Information technology.

System and software integrity levels

/Чата аммония 2003—07—01

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

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

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

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

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

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

2    Нормативные ссылки

В настоящем стандарте использованы ссылки на следующие стандарты:

ГОСТ Р ИСО/МЭК 12207—99 Информационная технология. Процессы жизненного цикла программных средств

ИСО/МЭК 2382-1—93“ Информационная технология. Словарь. Часть I: Основополагающие термины

О Оригиналы международных стандартов:

–    ИСО (ИСО/МЭК) — но ВНИИ КМ Госстандарта России;

–    МЭК — во ВНИИстанларт Госстандарта России.

И панне офиниалынч’

ИСО/МЭК 2382-20—95″ Информационная технология. Словарь. Часть 20: Разработка систем

ИСО 8402—94″ Управление качеством и обеспечение качества. Словарь

МЭК 50-191—93″ Международный электротехнический словарь. Глава 191: Надежность и качество услуги

МЭК 300-3-9—95″ Управление надежностью. Часть 3: Прикладное руководство. Раздел 9: Анализ риска технологических систем

3 Определения

В настоящем стандарте применяют определения, приведенные в ИСО/МЭК 2382-1. ИСО/МЭК 2382-20. ИСО 8402 и МЭК 50-191. а также следующие термины с соответствующими определениями.

3.1    компонент (component): Элемент внутри системы, имеющий дискретную структуру (например. компоновочный или программный модуль), рассматриваемый на конкретном уровне анализа.

3.2    степень достоверности (degree of confidence): Степень уверенности в соответствии программного средства установленным требованиям.

3.3    ответственный проектант (design authority): Лицо или организация, которая отвечает за создание проекта системы.

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

3.5    локализация отказа (fault isolation): Способность подсистемы предупреждать отказ в рамках данной подсистемы без вызова последующих отказов в других подсистемах.

3.6    функция (function): Аспект определенного поведения системы.

3.7    ининиируиннсс событие (initiating event): Событие, которое может привести к угрозе.

3.8    ответственный за обеспечение целостности (integrity assurance authority): Независимое лицо или организация, отвечающая за аттестацию на соответствие требованиям целостности.

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

3.10    объект (item): Элемент, такой как часть, компонент, подсистема, оборудование иди система, который может быть рассмотрен отдельно. Элемент может содержать технические и программные средства иди и то и другое.

3.11    функция ачортизайми (mitigating function): Функция, которая, в случае успешной реализации. должна предотвратить возникновение инициирующего события конкретной угрозы.

3.12    риск (risk): Функция вероятности возникновения заданной угрозы и потенциально неблагоприятных последствий возникновения этой угрозы.

3.13    размер риска < risk dimension): Перспектива, с точки зрения которой будет проведена оценка риска для системы (например, безопасность, экономика, зашита).

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

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

3.16    уровень целостности программного средства (software integrity level): Уровень целостности программного объекта (элемента).

3.17    подсистема (subsystem): Любая система, входящая в другую (большую) систему.

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

3.19    систематический отказ (systematic failure): Отказ, в ряде случаев связанный с конкретным способом его устранения путем изменения проекта иди производственного процесса, процедур эксплуатации, документирования иди других сопутствующих факторов.

” Оригиналы международных стандартов:

–    ИСО (ИСО/МЭК) – во ВНИИКИ Госстандарта России;

–    МЭК — но ВМИИстаиларг Госстандарта России.

2

ГОСТ Р ИСО/МЭК 15026-2002

3.20    уровень целостности системы (system integrity level): Уровень целостности, заданный язя системы.

3.21    угроза (threat): Состояние системы или се окружения, которое может привести к неблагоприятному эффекту при одном или нескольких размерах риска.

4 Символы и сокращения

Отсутствуют символы, используемые в настоящем стандарте.

5 Основы уровней целостности программных средств

5.1    Невольмжанис настоящего ciaiuapia

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

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

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

5.2    Об юр

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

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

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

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

3

ГОСТ I» ИСО/МЭК 15026-2002

Таблица I — Исходные данные и выходные ре iy.ii. га гы

Процесс Исходные данные Выходные результаты Установление уровня целостности системы Соответствующие размеры риска Описание системы Описание среды Архитектура системы (при се наличии) Риск Угрозы Допустимая частота иди вероятность появления угрозы Инициирующие события Частота или вероятность шш1ншрую1нсго события Уровень целостности системы Установление уровня целостности программного средства Уровень целостности системы Архитектура подсистемы или программного средства Перечень угроз и для каждой угрозы: –    допустимая частота или вероятность появления у грош; –    инициирующие события, которые могут привести к утрою; • ожидаемая частота или вероятность пояа1сння каждого ини1ширую1иего события Уровень целостности полсистсмы или программного средства Архитектурные особенности, связанные с понижением уровня целостности Установление требований к целостности программного средства Уровень целостности подсистемы иди программного средства Требования к целостности программного средства

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

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

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

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

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

5

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

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

6 Установление уровни целостности системы

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

a)    установление уровня риска при анализе риска системы. Анализ риска является процессом использования доступной ин«|юрмании для определения угроз и оценки риска, связанного с этими угрозами;

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

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

6.1    Анализ риска

Анализ риска должен быть выполнен для ответа на три основных вопроса:

–    что может привести к неисправности? (путем определения угрозы);

–    какова вероятность того, что это случится? (путем анализа частоты инициирующих событий):

–    каковы последовательности этого? (путем анализа последовательности инициирующих событий).

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

a)    описание риска в соответствующих терминах:

b)    угрозы, связанные с данным риском;

c)    конкретные инициирующие события, связанные с каждой угрозой;

d)    предполагаемая частота возникновения инициирующего события.

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

Соответствующим руководством при анализе риска является МЭК 300-3-9. Специфичные термины в части безопасности, использованные в МЭК 300-3-9. а именно «опасность (hazard)» и «ущерб (harm)» должны быть истолкованы соответственно как «угроза (threat)» и «вредное воздействие (adverse effect)».

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

6.1.1    Определение угрозы

Угрозы, связанные с системой, должны быть определены вместе с инициирующими событиями. могущими привести к этим угрозам. Угрозы связаны с системой, если отказ системы может привести к конкретной угрозе, эксплуатация системы в установленном режиме может привести к конкретной угрозе или выполнение системой функции амортизации связано с инициирующим событием в среде эксплуатации, которое может привести к угрозе. Угрозы нс могут быть указаны заранее, для этого должны быть использованы и документально оформлены методы их определения, охватывающие конкретную ситуацию (см. МЭК 300-3-9). При наличии архитектуры системы эта

ь

ГОСТ I» ИСО/МЭК 15026-2002

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

6.1.2    Анализ частоты

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

Каждая частота должна быть оценена с использованием статистических опытных данных, обобщенных на основе соответствующих методов, например анализа дерева отказов или дерева событий (см. МЭК 300-3-9). или оценена на основе экспертных заключений.

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

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

6.1.3    Анализ последовательности

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

6.1.4    Расчет риска

Риск, связанный с каждой угрозой, рассчитывают с использованием матрицы риска, связывающей частоту появления инициирующих событий с опасностью их последовательности. Матрица риска устанавливает классы риска, такие как высокий, средний, низкий или обычный, для каждой комбинации частоты и опасности. В таблице 2 приведен пример матрицы риска, взятый из МЭК 300-3-9.

Т а б л и и а 2 — Пример матрицы риска

Частота появления Характерная частота (в гол) Опасность последовательности Катастрофическая Главная Опасная Нси1ач!ттс.1Ы1ая Обычная > 1 Высокий Высокий Высокий Средний Веройгиая 1-10-‘ Высокий Высокий Средний Ни !кий Случайная 10 ‘ — К)-* Высокий Высокий Нижий Ни !КИН Маловероятная io-1-i о-4* Высокий Высокий Ни (кии Ни жиН Невероятная Ю-4—10-6 Высокий Средний Низкий Обычный Неправдоподобная < I06 Средний Средний Обычный Обычный

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

6.2    Оценка риска

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

6.3    Присвоение уровня целостности системы

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

7