Принят и введен в действие
Постановлением Госстандарта РФ
от 11 июня 2002 г. N 237-ст
ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ
УРОВНИ ЦЕЛОСТНОСТИ СИСТЕМ И ПРОГРАММНЫХ СРЕДСТВ
Information technology.
System and software integrity levels
ГОСТ Р ИСО/МЭК 15026-2002
Группа П85
ОКС 35.080;
ОКСТУ 5001
Дата введения
1 июля 2003 года
Предисловие
1. Разработан и внесен Всероссийским научно-исследовательским институтом стандартизации (ВНИИстандарт) Госстандарта России.
2. Принят и введен в действие Постановлением Госстандарта России от 11 июня 2002 г. N 237-ст.
3. Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК 15026-98 "Информационная технология. Уровни целостности систем и программных средств".
4. Введен впервые.
1. Область применения
Настоящий стандарт определяет концепцию уровней целостности программных средств и требования к целостности программных средств. Стандарт содержит основные положения, связанные с уровнями целостности, определяет процессы для установления уровней целостности и требований к целостности программных средств, а также устанавливает требования к каждому соответствующему процессу. Стандарт не предопределяет конкретный набор уровней целостности или требования к целостности конкретного программного средства. Данные наборы должны быть установлены либо для программного средства на уровне проектирования, либо для конкретного прикладного сектора и (или) страны. Стандарт применим только для программных средств. Уровень целостности системы и уровни целостности непрограммных компонентов в настоящем стандарте использованы только для определения уровней целостности компонентов программных средств.
Настоящий стандарт предназначен для применения разработчиками, пользователями, поставщиками и экспертами программных продуктов и систем, содержащих программные средства, а также для административной и технической поддержки данных продуктов и систем.
Уровень целостности программного средства не определяет диапазон значений конкретного свойства программного средства, необходимый для удержания системного риска в допустимых границах. Для программного средства, выполняющего функцию амортизации, подобным свойством является надежность, с которой программное средство должно выполнять функцию амортизации. Для программного средства, отказ которого может привести к угрозе для системы, таким свойством является ограничение частоты или вероятности подобного отказа.
Требованиями к целостности программного средства являются требования, удовлетворяемые в процессе программной инженерии, используемом для разработки программного средства, которым должны соответствовать программные продукты, и (или) требования, четко определяющие качество функционирования программного средства во времени, обеспечивающие степень его соответствия заданному уровню целостности.
Настоящий стандарт не устанавливает способ интеграции определения уровня целостности в общие процессы жизненного цикла программной инженерии.
2. Нормативные ссылки
В настоящем стандарте использованы ссылки на следующие стандарты:
ГОСТ Р ИСО/МЭК 12207-99. Информационная технология. Процессы жизненного цикла программных средств
ИСО/МЭК 2382-1-93 <*>. Информационная технология. Словарь. Часть 1: Основополагающие термины
ИСО/МЭК 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): отказ, в ряде случаев связанный с конкретным способом его устранения путем изменения проекта или производственного процесса, процедур эксплуатации, документирования или других сопутствующих факторов.
3.20. Уровень целостности системы (system integrity level): уровень целостности, заданный для системы.
3.21. Угроза (threat): состояние системы или ее окружения, которое может привести к неблагоприятному эффекту при одном или нескольких размерах риска.
4. Символы и сокращения
Отсутствуют символы, используемые в настоящем стандарте.
5. Основы уровней целостности программных средств
5.1. Использование настоящего стандарта
Концепция независимого субъекта, отвечающего за обеспечение целостности, является основополагающей при применении настоящего стандарта. Ответственным за обеспечение целостности является лицо или организация, отвечающая за проведение сертификации на соответствие требованиям целостности. Решения, принятые по согласованию между ответственным проектантом и ответственным за обеспечение целостности, должны быть документально оформлены. Решения, подлежащие согласованию, должны охватывать определение соответствующих размеров риска, используемых конкретных уровней целостности, конкретного критерия оценки каждого уровня, степени эффективности использования определенных архитектурных особенностей проекта и требований к программному средству, возникающих вследствие установления конкретного уровня целостности.
Процессы, описанные в настоящем стандарте, представлены независимо от общих процессов системной инженерии, но настоящий стандарт не препятствует включению этих процессов в процессы системной инженерии. Кроме того, для соответствия настоящему стандарту при реализации этих процессов необходимо, чтобы все требования к ним были удовлетворены.
Подраздел 5.2 содержит обзор этих процессов с точки зрения установления уровней целостности и требований к целостности программного средства. Разделы 6, 7 и 8 описывают данные процессы более детально и определяют требования, налагаемые на эти процессы.
5.2. Обзор
На рисунке 1 представлен обзор процессов, необходимых для установления уровней целостности системы и программного средства и требований к целостности программного средства. В таблице 1 перечислены исходные данные и выходные результаты для каждого из трех основных процессов установления уровня целостности системы, установления уровня целостности программного средства и установления требований к целостности программного средства.
АНАЛИЗ РИСКА ОБЩАЯ СИСТЕМНАЯ
ИНЖЕНЕРИЯ
Новые угрозы -----------------¬ Описание ---------------¬
---------------->¦--------------¬ ¦ системы ¦ ¦
¦ ¦¦ Определение ¦ ¦<--------------+ ¦
¦ ¦¦ угрозы ¦ ¦ ¦ ¦
¦ ¦L------T------- ¦ ¦ ¦
¦ ¦-------+------¬ ¦ Размеры риска ¦ ¦
¦ ---------------+¦ Анализ ¦ ¦<--------------+-------------¬¦
¦ ¦ ¦¦ частоты ¦ ¦ ¦¦ Системная ¦¦
¦ ¦ ¦L------T------- ¦ ¦¦ инженерия ¦¦
¦ ¦ ¦-------+-------¬¦ ¦L-------------¦
¦ ¦ ¦¦Анализ после- ¦¦ ¦ ¦
¦ ¦ ¦¦довательности ¦¦ Возможности ¦ ¦
Для просмотра документа целиком скачайте его >>>
