ГОСТ Р ИСО/МЭК 27034-1—2014
и) Р2 — средний риск приватности: Единственным влияющим на приватность видом действия в функции,
продукте или услуге является однократная передача анонимных данных, инициируемая пользователем
(например, пользователь щелкает по ссылке и переходит на веб-сайт):
Ш) РЗ — низкий риск приватности: В функции, продукте или услуге отсутствует вид действия, оказы
вающий влияние на приватность. Не передаются анонимные или персональные данные, не хранится в
машине персональная идентификационная информация, не меняются никакие установки от имени поль
зователя. не инсталлируются программные средства.
А.9.3 Проектирование
5) Требования проектирования: Оптимальное время влияния на надежную разработку проекта — началь
ные моменты его жизненного цикла. Крайне важно тщательно рассматривать вопросы безопасности и приватности
на этапе проектирования, так как решение проблем безопасности и приватности, осуществляемое на начальных
этапах жизненного цикла, будет гораздо менее затратным. Группы проекта должны воздерживаться от
практики «привязывания» к концу разработки проекта решение вопросов безопасности и приватности.
Кроме того, группам проекта крайне важно понимать различие между «безопасными свойствами» и «свой
ствами безопасности» — вполне возможна реализация свойств безопасности, которые, в сущности, небезопасны.
Безопасные свойства определяются как свойства, функциональные возможности которых правильно спроекти
рованы в отношении безопасности, включая строгую проверку правильности всех данных перед обработкой или
криптографически надежную реализацию библиотек для криптографических сервисов. Свойства безопасности
описывают функциональные возможности программы с включением безопасности (например, аутентификация по
Kerberos).
Функциональные спецификации проектирования могут потребоваться для описания свойств безопасности
или свойств приватности, которые будут непосредственно представлены пользователям, например, требование
аутентификации пользователей для доступа к определенным данным или согласия пользователя перед
использо ванием свойства с высоким риском приватности. В результате все спецификации проектирования
должны:
a) точно и полностью определять, как реализуются эти свойства:
b
) определять, как можно безопасно реализовать все функциональные возможности, разрешаемые дан
ными свойствами:
c) определять, как безопасным способом использовать эти свойства.
Исполнение требований проектирования содержит ряд необходимых действий, включающих (но не ограни
чивающихся) анализ проектирования безопасности, анализ проектирования приватности и спецификаций, а также
реализацию минимальных криптографических требований проектирования:*
6) Уменьшение видов атак: Уменьшение видов атак тесно связано с моделированием угроз, хотя оно рас
сматривает проблемы безопасности немного с иной точки зрения. Уменьшение видов атак представляет собой
средство снижения риска путем предоставления нарушителям меньшей возможности для нахождения слабого
места или уязвимости. Уменьшение видов атак соединяет использование многоуровневой защиты, отключение
или ограничение доступа к системным сервисам и применение при любых возможных обстоятельствах принципа
наименьших привилегий:
7) Моделирование угроз: Моделирование угроз — это обязательный процесс, выполняемый на этапе про
ектирования и позволяющий группам разработки в структурированно»/ виде рассматривать, документировать и
обсуждать последствия для безопасности при проектировании. Оно также предус»/атривает тщательное расс»/о-
трение проблем безопасности на уровне компонентов или приложений. Моделирование угроз является командной
работой, охватывающей руководителей проекта/програмг/ы. разработчиков и специалистов по тестированию, и
представляет основную задачу анализа безопасности, осуществляемую на этапе проектирования програ»/»/ных
средств.”
А.9.4 Реализация
8) Использование утвержденных инструментальных средств: Все группы разработки должны опреде
лять и публиковать список утвержденных инструментальных средств (и конкретные функциональные возможности
безопасности, такие как опции компилятора/компоновщика. предупреждающие сообщения и т. д.) для использова
ния в программных проектах.”Этот список должен согласовываться и утверждаться кураторе»/ по обеспечению
безопасности группы проекта. Как правило, группы разработки должны стараться использовать новейшую версию
утвержденных инструментальных средств, чтобы r/ожно было использовать новые функциональные возможности
безопасности;
9) Исключение ненадежных функций из числа используемых: Многие обычно используегиые функции и
интерфейсы прикладного програг/»/ирования (Application Programming Interface — API) не являются безопасными в
отношении существующей среды угроз. Группы проекта должны анализировать все функции и API. которые будут
использоваться совместно с проекта»/ разработки програм»/ных средств, и запрещать те из них. которые определе ны
как ненадежные.*14’ После определения списка запрещенных элементов группы проекта должны использовать
заголовочные файлы, обновленные ко»/пиляторы или инстру»/ентальные средства сканирования кода программы
для осуществления проверки кода (включая унаследованный код в соответствующих случаях) на предмет суще
ствования запрещенных функций и за»иены их более надежны»/»» альтернативны»/и варианта»/»»;
10) Статический анализ: Группы проекта должны осуществлять статический анализ исходного кода про-
гра»/»/ы. Статический анализ исходного кода програ»/»/ы обеспечивает масштабируемое решение для проверки
44