ГОСТ Р ИСО/МЭК 15026-2002 уменьшение риска, обнаруживают новые угрозы по сравнению с присвоенными уровнями целостности системы и программного средства или проект системы не обеспечивает допустимого риска.
Уровень целостности программного средства используют при установлении контроля за риском для программных компонентов путем определения требований к программному средству и процессу программной инженерии, обеспечивающих заданную степень достоверности программного средства, связанную с ролью данных требований по отношению к системному риску. Эти требования называют «требованиями к целостности программного средства».
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). При наличии архитектуры системы эта
6