Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ТИБиМЗИ.doc
Скачиваний:
73
Добавлен:
21.11.2018
Размер:
2.34 Mб
Скачать

35. Гост р 15408:2002. Часть 3. Парадигма доверия в стандарте. Основные принципы стандарта. Значимость уязвимостей. Причины возникновения уязвимостей. Подход к доверию в стандарте. Роль оценки.

Парадигма доверия в стандарте

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

Основные принципы стандарта

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

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

Значимость уязвимостей

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

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

Причины уязвимостей

Уязвимости могут возникать из-за недостатков в:

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

б) проектировании — т.е. продукт или система ИТ не отвечают спецификации, и/или уязвимости являются следствием плохих стандартов проектирования или неправильных проектных решений;

в) эксплуатации — т.е. продукт или система ИТ разработаны в полном соответствии с корректными спецификациями, но уязвимости возникают как результат неадекватного управления при эксплуатации.

Доверие в стандарте

Доверие – основа для уверенности в том, что продукт или система ИТ отвечают целям безопасности. Доверие могло бы быть получено путем обращения к таким источникам как бездоказательное утверждение, предшествующий аналогичный опыт или специфический опыт. Однако настоящий стандарт обеспечивает доверие с использованием активного исследования. Активное исследование – это оценка продукта или системы ИТ для определения его свойств безопасности.

Доверие через оценку

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

а) анализ и проверку процессов и процедур;

б) проверку, что процессы и процедуры действительно применяются;

в) анализ соответствия между представлениями проекта ОО;

г) анализ соответствия каждого представления проекта ОО требованиям;

д) верификацию доказательств;

е) анализ руководств;

ж) анализ разработанных функциональных тестов и полученных результатов;

з) независимое функциональное тестирование;

и) анализ уязвимостей, включающий предположения о недостатках;

к) тестирование проникновения.

Шкала оценки доверия в стандарте

Повышение уровня усилий может быть основано на:

а) области охвата — т.е. усилие тем значительнее, чем больше рассматриваемая часть продукта или системы ИТ;

б) глубине — т.е. усилие тем значительнее, чем детальнее рассматриваемый уровень подробностей проекта и реализации;

в) строгости — т.е. усилие значительнее, потому что применяется более структурированный и формальный подход.