ГОСТ Р ИСО/МЭК 27034-1—2014
А.9.1 Обучение
1) Требования обучения: Все члены групп разработки программных средств должны пройти соответствую
щее обучение, чтобы быть в курсе основ обеспечения безопасности и последних тенденций в сфере безопасности
и приватности. Лица с техническими рабочими ролями (разработчики, специалисты по тестированию, руководи
тели программ), непосредственно участвующие в разработке программ, должны ежегодно проходить, по крайней
мере, один курс обучения по безопасности. Базовое обучение по безопасности программных средств должно охва
тывать основополагающие концепции, такие как безопасное проектирование, моделирование угроз, определение
видов атак, безопасное кодирование, тестирование безопасности и приватности.’’’
А.9.2 Требования
2) Требования безопасности: Необходимость рассмотрения вопросов безопасности и приватности на ба
зовом уровне является основополагающим аспектом разработки систем. Оптимальным моментом определения
требований надежного проектирования программного средства является начальная стадия планирования его вер
сии. Это дает возможность занимающимся разработкой группам идентифицировать ключевые этапы и результаты,
а также позволяет осуществлять интеграцию безопасности и приватности таким образом, чтобы она сводила
к минимуму любые нарушения планов и временных графиков. Анализ требований безопасности и приватности
осу ществляется в начале проекта и состоит из различных обязательных действий, включая (как минимум):
определе ние применимости SDL: определение лиц, отвечающих за надзор за безопасностью и приватностью (см.
8.1.2.5 — Роли, обязанности и квалификация); определение минимальных требований безопасности;
специфицирование и развертывание системы отслеживания уязвимосгей/рабочих вопросов; "
3) Границы качества/порог ошибок: Границы качества/пороги ошибок используются для установления
минимально допустимых уровней качества обеспечения безопасности и приватности."1v" Определение этих кри
териев в самом начале проекта способствует пониманию рисков, связанных с проблемами безопасности, и дает
возможность группам проекта идентифицировать и исправлять ошибки во время разработки. Группа проекта
должна обсуждать границы качества для каждого этапа разработки, они должны быть утверждены куратором по
безопасности с разъяснениями, соответствующими проекту, и более строгими требованиями безопасности, опре
деленными куратором по обеспечению безопасности (в соответствующих случаях). Группа проекта должна также
продемонстрировать соответствие согласованным границам качества для соблюдения требований проверки при
окончательной проверке безопасности. Порог ошибок — это границы качества, относящиеся ко всему проекту
разработки программных средств. Он используется для определения границ серьезности ошибок, влияющих на
безопасность (например, нет известных ошибок в приложении с «критическим» показателем во время выпуска).
Порог ошибок никогда не должен снижаться, даже если приближается дата выпуска проекта.
П р и м е ч а н и е — Применяемая к безопасности концепция границ качества/порога ошибок близха к кон
цепции целевого уровня доверия, так как она также используется для установления минимальнодопустимых уров
ней безопасности и приватности:
4) Оценка риска безопасности и приватности: Оценка риска безопасности и приватности (Security and
privacy risk assessments — SRA) — это обязательные процессы идентификации функциональных аспектов про
граммных средств, которые могут требовать углубленной проверки. Учитывая, что характеристики программы и на
меченные функциональные возможности могут отличаться в разных проектах, разумно начинать с простых оценок
риска и расширять их по мере необходимости для соответствия масштабу проекта. Такие оценки должны включать
следующую информацию:
a) (безопасность) какие части проекта потребуют модели угроз (см. ASC 7 )4 ниже) перед выпуском?
b
) (безопасность) какие части проекта потребуют проверок проектирования безопасности перед выпу
ском?
c) (безопасность) какие части проекта (если таковые имеются) потребуют тестирования на проникнове
ние. проводимого взаимно согласованной группой, являющейся внешней по отношению к группе про
екта? Любые части проекта, требующие тестирования на проникновение, должны разрешить проблемы,
идентифицированные во время тестирования на проникновение, перед утверждением для выпуска:
d) (безопасность) любые требования дополнительного тестирования или анализа, сочтенные куратором
по обеспечению безопасности необходимыми для уменьшения рисков безопасности;
в) (безопасность) разъяснение конкретной сферы требований «случайное тестирование»2* (см.
ASC 12Я>. ниже);
0 (приватность) определение показателя влияния на приватность:у,‘ |Х
i) Р1 — высокий риск приватности: Функция, продукт или услуга хранят или передают PII4* . меняют
установки или ассоциации типа файла или инсталлируют программные средства;
См. перечисление 7) в А.9.3.
2> «Случайное тестирование» (fuzz testing) — тестирование, использующее случайный набор входных
данных.
3> См. перечисление 12) в А.9.5.
4> PII (Personally Identifiable Infonnation) — персональная идентификационная информация.
43