ГОСТ 15026-2002 (Уровни целостности систем и программных средств)

Начать. Это бесплатно
или Регистрация c помощью Вашего email-адреса
Rocket clouds
ГОСТ 15026-2002 (Уровни целостности систем и программных средств) создатель Mind Map: ГОСТ 15026-2002  (Уровни целостности систем и программных средств)

1. Для предотвращения используется резервирование;

1.1. Копирование данных;

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

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

3. Определена возможность невыполнения функции амортизации при отказе подсистемы;

3.1. Не возможность возмещения потерь при отказе;

4. Определен набор подсистем, образующие систему;

4.1. Набор объектов , обеспечивающих некоторую функциональность, целостность системы;

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

5.1. Степень достоверности

5.1.1. Способы:

5.1.1.1. Применение методов, минимизирующих внесение ошибок;

5.1.1.2. Методы позволяющие с максимальной вероятностью обнаружить ошибки;

5.1.1.3. Демонстрация на конкретных примерах;

5.2. Методы обеспечения степени достоверности

5.2.1. Анализ (точность, полнота, проверяемость);

5.2.2. Проектирование (абстрагирование, проверяемость);

5.2.2.1. Точно описать и и дать понять как выявить;

5.2.3. Программирование (стандартизация языка, сопровождаемость);

5.2.3.1. Понятным языком для системы;

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

6.1. Это распределение уровня целостности системы по подсистемам, содержащие программные средства;

6.2. Предпосылки при установлении уровня целостности

6.2.1. Для системы существует присвоенный ей номер;

6.2.2. Характеристики системы должны быть подробными для возможности установки роли подсистем и их интерфейсы;

6.2.3. Исходные данные охватывают:

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

6.2.3.2. Перечень угроз;

6.2.3.3. Описание архитектуры системы;

6.2.3.3.1. Из чего состоит система;

6.2.4. Выходным результатом является уровень целостности программного средства;

6.2.4.1. Диапазон знаний, для удержания системного риска в допустимых границах;

6.3. Понижение уровня целостности

6.3.1. При определении возможности снизить уровень целостности системы должны быть выполнены этапы:

6.3.1.1. Определена возможность возникновения угрозы;

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

6.4. Понижение уровня целостности, который может привести к угрозе

6.4.1. Для предотвращения общих отказов при резервировании, используют диверсификацию;

6.4.1.1. тем самым снижая риски ;

6.4.2. При использовании диверсификации, описания её сути должны быть согласованы между ответственными;

6.5. Понижение уровня целостности, который может привести к снижению возможностей функции амортизации

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

6.5.1.1. Как часто ПС даёт сбой, тем самым снижая свою надёжность;

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

7.1. Должен соответствовать допустимому уровню риска, связанному с программной системой;

7.2. Анализ риска;

7.2.1. Должен отвечать на вопросы:

7.2.1.1. Что может привести к неисправности? (Путём определения угрозы)

7.2.1.1.1. Определяется вместе с событиями, способствующие подвести к данной угрозе;

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

7.2.1.2. Какова вероятность что это случится ? (путём анализа частоты тех или иных событий)

7.2.1.2.1. Анализ частоты используется для оценки вероятности события, выявленного при определении угрозы;

7.2.1.2.2. При анализе частоты, систему трактуют как "чёрный ящик", а архитектуру системы вообще не учитывают;

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

7.2.1.3. Какова последовательность этого ? (путём анализ а последовательности событий)

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

7.2.1.4. В результате получаем риск, в котором должны проанализировать:

7.2.1.4.1. Описание риска;

7.2.1.4.2. Угрозы, связанные с данным риском;

7.2.1.4.3. События связанные с риском;

7.2.1.4.4. Частота возникновения риска;

7.3. Отценка риска;

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

7.3.1.1. Какие риски вообще могут появится в ходе работы программного обеспечения, и по какому поводу

7.4. Присвоение уровня целостности системы;

7.4.1. Назначают в соответствии с наивысшим классом риска, присвоенным любым угрозам, связанным с системой;

7.4.2. Число уровней целостности должно соответствовать числу установленных классов риска (Высокий, Средний, Низкий, Обычный);

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

8.1. Использование стандарта

8.1.1. Основополагающей при применении стандарта, является концепция независимого субъекта, отвечающее за обеспечение целостности (при совершении какой либо операции данные не будут изменены);

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

8.1.2. Ответственный за обеспечение целостности является лицо или организация , отвечающее за проведение сертификации на соответствием требованиям целостности ;

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

8.1.4. Решения подлежащие согласованию, должны охватывать определения:

8.1.4.1. Соответствующих размеров риска;

8.1.4.1.1. От минимальных ошибок системы, до полной её не работы;

8.1.4.2. Используемых конкретных уровней целостности;

8.1.4.2.1. Маленький, средний, большой

8.1.4.3. Конкретного критерия оценки каждого уровня;

8.1.4.3.1. У одного уровня свои права, у другого свои (пример: выполнение Windows от имени администратора (высокий) от уровня пользователя (средний))

8.1.4.4. Степени эффективности использования определения архитектурных особенностей проекта и требований к программному средству;

8.1.4.4.1. Какие цели мы ставим перед собой перед внедрением какой-либо программной системы?

8.1.4.4.2. Чего мы хотим достичь, внедряя новые технологии?

8.1.4.4.3. Поддержат ли требования программного средства ?

8.2. Обзор процессов, для установления уровней целостности системы и программной системы

8.2.1. Выполнение анализа риска за счёт:

8.2.1.1. Получение достаточной информации о системе;

8.2.1.1.1. Марка, Внутренние составляющие, мощность и т.д.

8.2.1.2. Информация о среде системы;

8.2.1.2.1. В какой области используют ? (Например: личность и ее ближайшее окружение из родственников, знакомых и коллег)

8.2.1.3. Размеры риска допустимые для системы ;

8.2.1.3.1. От мелких шибок, до полной не работы;

8.2.2. Результаты анализа риска должны:

8.2.2.1. Охватывать все размеры риска в части безопасности, экономики и защиты;

8.2.2.2. Быть согласованы с ответственным за обеспечение целостности;

8.2.3. Анализ системной архитектуры

8.2.3.1. Возможность выявления новых рисков, не выявленные при прошлом анализе;

8.2.3.1.1. Повторное проведение анализа риска

8.2.3.1.2. Контроль за рсками

8.2.3.2. Уровень целостности программного средства является показатель, отражающий степень надёжности функции;

8.2.3.2.1. Отказ которых может привести к снижению возможностей программного средства

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

9.1. Предназначен для использования

9.1.1. Разработчиками;

9.1.2. Пользователями;

9.1.3. Поставщиками;

9.1.4. Экспертами программных продуктов;

9.1.5. Административной и технической поддержки;

9.2. Предназначен для применения

9.2.1. Только для программных средств;

9.3. Требования

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

9.3.2. Должны чётко определять качество функционирования ПО во времени (Кто будет использовать данную программу ? Что в программе особенного ? и т.д.) ;