24
честве альтернативы методы обеспечения доверия можно выбирать — комбинировать для обеспечения этапа концепции с учетом определения целей безопасности с необходимым уточнением.
Для ДР целями безопасности могут быть:
- для отдельного продукта — политика безопасности;
- для серийного продукта — общие цели безопасности, принятые в целевом коллективе пользователей.
- Существующие методы
Некоторые существующие методы обеспечения доверия для ДР в общих чертах приведены в приложении А.2. Другие методы обеспечения доверия можно выбрать в соответствии с ИСО/МЭКТО 15443-2.
Методы, приведенные в приложении А.2 настоящего стандарта, приведены в соответствии с ИСО/МЭК 15408, ИСО/МЭК 19790, ИСО/МЭК 21827, ИСО/МЭК 27001 и ИСО 9000. Основные аспекты этих методов приведены в приложении В настоящего стандарта.
- Основные аспекты
При высоких требованиях доверия к безопасности необходимо оценивать стойкость и корректность функций безопасности. В этом случае выбранный метод обеспечения доверия должен содержать (ссылаться на них или дополняться ими) процедуры оценки, обеспечивающие стойкость и корректность функций безопасности.
- Верификация стойкости
Верификация стойкости является обеспечением противостояния таких критических механизмов, как шифрование, хэширование, алгоритмы паролей противодействия атакам, в особенности грубым атакам.
- Верификация корректности
Целью верификации корректности является обеспечение правильности выполнения этапов процесса разработки от функциональных требований до эксплуатации системы. Следовательно, верификация корректности относится к оценке согласования нижнего уровня проектирования (включая внедрение) с более высокими уровнями. Эти действия не связаны с угрозами или целями безопасности, а только с должным проведением разработки. Они тесно связаны с верификацией качества или функцией обеспечения доверия к качеству.
Верификация корректности является процессом подтверждения соответствия системы спецификации и проекта нижнего уровня, и соответствия спецификации более высоким уровням проекта. Эта верификация подразумевает проверку соответствия требований к системе спецификации, поскольку требования сформулированы способом, позволяющим проводить прямую проверку соответствия спецификации. Верификация корректности также включает в себя методику испытаний наряду с неформальным или формальным конструкторским анализом и средствами верификации. Строгость верификации корректности зависит от точного и однозначного представления различных уровней проектирования. Для формальных методов анализа и верификации при представлении проекта требуются более высокие уровни точности, что ограничивает число методов, которые могут использоваться для описания проекта. Проект не должен быть неопределенным, в особенности при высоких степенях (уровнях) уверенности в правильности системы.
- Доверие к интеграции (ДИ)
ДИ может применяться при интеграции нескольких продуктов, обычно многих продуктов различного происхождения и с разными результатами доверия, в систему.
Многие продукты представляют собой готовую и проверенную коммерческую продукцию с результатами доверия, но часто эти результаты не доступны по запросу пользователя. Следовательно, в большинстве случаев пользователю как последней инстанции обеспечения доверия к разворачиваемой системе приходится иметь дело со сложной ситуацией в отношении обеспечением доверия.
Интегратор коммерческой системы, разрабатывающий какую-либо систему, обычно поставляет и, следовательно, учитывает только часть развернутой системы, и следовательно, перед ним стоит менее сложная задача, если только он не отвечает за систему в целом.
Обычно для сложных ситуаций, связанных с интеграцией, требуются дополнительные продукты или меры безопасности, что может создать дефицит доверия. Дефицит доверия необходимо заполнить для того, чтобы достигнуть установленных целей безопасности.
Для получения необходимой уверенности может потребоваться валидация абстрактного или сложного (комплексного) результата доверия в действии.
Примечание — В ИСО/МЭК ТО 15443 не охвачены аспекты способности системы к компоновке и доверия к ней —даже если каждая подсистема в отдельности соответствует своим функциональным требованиям и требованиям безопасности, общая составная система может не функционировать должным образом и не быть безопасной. Аспект доверия к способности системы к компоновке может подвергаться дополнительному системному тесту и валидации.