1. Основны уровней целостности программных средств
1.1. Использование стандарта
1.1.1. Основополагающей при применении стандарта, является концепция независимого субъекта, отвечающее за обеспечение целостности (при совершении какой либо операции данные не будут изменены);
1.1.1.1. Пример: в программе accsess связанное поле обеспечивается возможность автоматической проверки целостности данных ,для обеспечения защиты от случайного удаления или изменения связанных данных.
1.1.2. Ответственный за обеспечение целостности является лицо или организация , отвечающее за проведение сертификации на соответствием требованиям целостности ;
1.1.3. Решения, принятые по согласованию между ответственнымиц за обеспечение целостности, должны быть документально оформлены;
1.1.4. Решения подлежащие согласованию, должны охватывать определения:
1.1.4.1. Соответствующих размеров риска;
1.1.4.1.1. От минимальных ошибок системы, до полной её не работы;
1.1.4.2. Используемых конкретных уровней целостности;
1.1.4.2.1. Маленький, средний, большой
1.1.4.3. Конкретного критерия оценки каждого уровня;
1.1.4.3.1. У одного уровня свои права, у другого свои (пример: выполнение Windows от имени администратора (высокий) от уровня пользователя (средний))
1.1.4.4. Степени эффективности использования определения архитектурных особенностей проекта и требований к программному средству;
1.1.4.4.1. Какие цели мы ставим перед собой перед внедрением какой-либо программной системы?
1.1.4.4.2. Чего мы хотим достичь, внедряя новые технологии?
1.1.4.4.3. Поддержат ли требования программного средства ?
1.2. Обзор процессов, для установления уровней целостности системы и программной системы
1.2.1. Выполнение анализа риска за счёт:
1.2.1.1. Получение достаточной информации о системе;
1.2.1.1.1. Марка, Внутренние составляющие, мощность и т.д.
1.2.1.2. Информация о среде системы;
1.2.1.2.1. В какой области используют ? (Например: личность и ее ближайшее окружение из родственников, знакомых и коллег)
1.2.1.3. Размеры риска допустимые для системы ;
1.2.1.3.1. От мелких шибок, до полной не работы;
1.2.2. Результаты анализа риска должны:
1.2.2.1. Охватывать все размеры риска в части безопасности, экономики и защиты;
1.2.2.2. Быть согласованы с ответственным за обеспечение целостности;
1.2.3. Анализ системной архитектуры
1.2.3.1. Возможность выявления новых рисков, не выявленные при прошлом анализе;
1.2.3.1.1. Повторное проведение анализа риска
1.2.3.1.2. Контроль за рсками
1.2.3.2. Уровень целостности программного средства является показатель, отражающий степень надёжности функции;
1.2.3.2.1. Отказ которых может привести к снижению возможностей программного средства
2. Область применения
2.1. Предназначен для использования
2.1.1. Разработчиками;
2.1.2. Пользователями;
2.1.3. Поставщиками;
2.1.4. Экспертами программных продуктов;
2.1.5. Административной и технической поддержки;
2.2. Предназначен для применения
2.2.1. Только для программных средств;
2.3. Требования
2.3.1. Должны быть удовлетворяемы в процессе программной инженерии (ПИ-это наука, которая изучает вопросы создания, сопровождения и внедрения программного обеспечения с заданным качеством, в заданные сроки и в рамках заранее определенного бюджета);
2.3.2. Должны чётко определять качество функционирования ПО во времени (Кто будет использовать данную программу ? Что в программе особенного ? и т.д.) ;
3. Для предотвращения используется резервирование;
3.1. Копирование данных;
4. Связь степени достоверности программного средства с уровнем его целостности
4.1. Ответственный за обеспечение целостности должен согласовать требования, подлежащие удовлетворению для достижения достоверности на каждом уровне целостности;
5. Определена возможность невыполнения функции амортизации при отказе подсистемы;
5.1. Не возможность возмещения потерь при отказе;
6. Определен набор подсистем, образующие систему;
6.1. Набор объектов , обеспечивающих некоторую функциональность, целостность системы;
7. Установление требований к целостности программного средства
7.1. Степень достоверности
7.1.1. Способы:
7.1.1.1. Применение методов, минимизирующих внесение ошибок;
7.1.1.2. Методы позволяющие с максимальной вероятностью обнаружить ошибки;
7.1.1.3. Демонстрация на конкретных примерах;
7.2. Методы обеспечения степени достоверности
7.2.1. Анализ (точность, полнота, проверяемость);
7.2.2. Проектирование (абстрагирование, проверяемость);
7.2.2.1. Точно описать и и дать понять как выявить;
7.2.3. Программирование (стандартизация языка, сопровождаемость);
7.2.3.1. Понятным языком для системы;
8. Установление уровня целостности программного средства
8.1. Это распределение уровня целостности системы по подсистемам, содержащие программные средства;
8.2. Предпосылки при установлении уровня целостности
8.2.1. Для системы существует присвоенный ей номер;
8.2.2. Характеристики системы должны быть подробными для возможности установки роли подсистем и их интерфейсы;
8.2.3. Исходные данные охватывают:
8.2.3.1. Уровень целостности системы;
8.2.3.2. Перечень угроз;
8.2.3.3. Описание архитектуры системы;
8.2.3.3.1. Из чего состоит система;
8.2.4. Выходным результатом является уровень целостности программного средства;
8.2.4.1. Диапазон знаний, для удержания системного риска в допустимых границах;
8.3. Понижение уровня целостности
8.3.1. При определении возможности снизить уровень целостности системы должны быть выполнены этапы:
8.3.1.1. Определена возможность возникновения угрозы;
8.3.1.2. Определено наличие подсистем программных компонентов, отказ которых не может привести к угрозе, а их возможности не связаны с амортизацией системных событий;
8.4. Понижение уровня целостности, который может привести к угрозе
8.4.1. Для предотвращения общих отказов при резервировании, используют диверсификацию;
8.4.1.1. тем самым снижая риски ;
8.4.2. При использовании диверсификации, описания её сути должны быть согласованы между ответственными;
8.5. Понижение уровня целостности, который может привести к снижению возможностей функции амортизации
8.5.1. Используют методы анализа частоты отказа программного средства с целью установить степень снижения его надёжности по сравнению с надёжностью системы;
8.5.1.1. Как часто ПС даёт сбой, тем самым снижая свою надёжность;
9. Установление уровня целостности системы
9.1. Должен соответствовать допустимому уровню риска, связанному с программной системой;
9.2. Анализ риска;
9.2.1. Должен отвечать на вопросы:
9.2.1.1. Что может привести к неисправности? (Путём определения угрозы)
9.2.1.1.1. Определяется вместе с событиями, способствующие подвести к данной угрозе;
9.2.1.1.2. Угрозы не могут быть указаны заранее, для их определения указывают конкретную ситуацию;
9.2.1.2. Какова вероятность что это случится ? (путём анализа частоты тех или иных событий)
9.2.1.2.1. Анализ частоты используется для оценки вероятности события, выявленного при определении угрозы;
9.2.1.2.2. При анализе частоты, систему трактуют как "чёрный ящик", а архитектуру системы вообще не учитывают;
9.2.1.2.3. Анализ должен учитывать, что некоторые инициирующее события приведут к угрозе только в сочетании с другими событиями;
9.2.1.3. Какова последовательность этого ? (путём анализ а последовательности событий)
9.2.1.3.1. Используют для оценки опасности угрозы, вызванные тем или иными событиями;
9.2.1.4. В результате получаем риск, в котором должны проанализировать:
9.2.1.4.1. Описание риска;
9.2.1.4.2. Угрозы, связанные с данным риском;
9.2.1.4.3. События связанные с риском;
9.2.1.4.4. Частота возникновения риска;
9.3. Отценка риска;
9.3.1. Ответственные за обеспечение целостности, выдают заключение о допустимости каждого риска, выявленного в процессе анализа;
9.3.1.1. Какие риски вообще могут появится в ходе работы программного обеспечения, и по какому поводу
9.4. Присвоение уровня целостности системы;
9.4.1. Назначают в соответствии с наивысшим классом риска, присвоенным любым угрозам, связанным с системой;
9.4.2. Число уровней целостности должно соответствовать числу установленных классов риска (Высокий, Средний, Низкий, Обычный);