Статус документа
Статус документа

ГОСТ Р ИСО/МЭК 15026-2002 Информационная технология (ИТ). Уровни целостности систем и программных средств

     5.2 Обзор


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

Рисунок 1 - Процесс установления и применения уровня целостности программного средства



Таблица 1 - Исходные данные и выходные результаты

Процесс

Исходные данные

Выходные результаты

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

Соответствующие размеры риска

Описание системы

Описание среды

Архитектура системы (при ее наличии)

Риск

Угрозы

Допустимая частота или вероятность появления угрозы

Инициирующие события

Частота или вероятность инициирующего события

Уровень целостности системы

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

Уровень целостности системы

Архитектура подсистемы или программного средства

Перечень угроз и для каждой угрозы:

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

- инициирующие события, которые могут привести к угрозе;

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

Уровень целостности подсистемы или программного средства

Архитектурные особенности, связанные с понижением уровня целостности

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

Уровень целостности подсистемы или программного средства

Требования к целостности программного средства



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

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

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

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

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

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

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

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

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