ГОСТ Р ИСО/МЭК 27034-1—2014
безопасности кода и может использоваться для обеспечения уверенности в соблюдении политик безопасного про
граммирования, устанавливаемых руководителем группы по вопросам безопасности и куратором по обеспечению
безопасности. Для проведения тщательной проверки безопасности одного статического анализа кода обычно не
достаточно. отвечающая за безопасность группа и кураторы по обеспечению безопасности должны осознавать
сильные и слабые стороны инструментальных средств статического анализа и быть готовыми к дополнительным
задачам проверки кода другими инструментальными средствами или ручными проверками при необходимости.
Облегченный статический анализ происходит во время SDL в момент регистрации кода путем использования функ
ции /analyze Visual Studio/7Другие задачи статического анализа осуществляются по мере необходимости.
А.9.5 Верификация
11) Динамический анализ программы: Верификация программ во время прогона необходима для
обеспечения уверенности в том. что функциональные возможности программы действуют, как было спроектиро
вано. Динамический анализ программы должен специфицировать инструментальные средства для мониторинга
поведения приложения при повреждении памяти, проблемах с привилегиями пользователей и других критических
вопросах безопасности. Процесс SDL использует специальные инструментальные средства, такие как AppVerifier, а
также такие методы, как «случайное» тестирование, для достижения желаемых уровней охвата тестирования
безопасности/41
12) «Случайное» тестирование: «Случайное» тестирование используется, чтобы вызвать сбой програм
мы путем преднамеренного введения в приложение неправильных или случайных данных. SDL определяет, что
«случайное» тестированиедолжно проводиться на различных интерфейсах программы. Выполнение «случайных»
тестов основано на намеченном использовании приложения, а также на функциональных и технических специфи
кациях приложения. Куратор по обеспечению безопасности гложет требовать дополнительного «случайного» тести
рования или увеличения охвата и длительности тестирования на основе намеченного поведения приложения;xvil
13) Пересмотр модели угроз/видов атак: Существенное отклонение приложения от функциональных и
технических спецификаций, созданных на этапе определения требований и создания проекта разработки про
граммных средств, является обычной ситуацией. Поэтому важно повторное рассмотрение моделей угроз/видов
атак данного приложения, когда его «код сформирован». Этот пересмотр будет обеспечивать уверенность в том.
что любые изменения системы учтены, а новые векторы атак проверены и снижены:
14) Ручная проверка кода программы (дополнительная): Ручная проверка кода программы является до
полнительной задачей в SDL. Ручная проверка кода обычно осуществляется группой, отвечающей за безопасность
приложения, по рекомендации куратора по обеспечению безопасности. Хотя инструментальные средства анализа
могут выполнять значительную работу по обнаружению и маркированию уязвимостей, они не совершенны, поэто му
ручная проверка кода обычно сосредотачивается на «критических» компонентах приложения. Чаще всего она
используется там, где затрагиваются чувствительные данные, такие как PII. Она также используется для изучения
других критических компонентов, например, реализующих криптографию.
А.9.6 Выпуск
15) План реагирования на инциденты: Каждая версия программного продукта с учетом требований SDL
должна быть охвачена планом реагирования на инциденты.’’7" Программы, не содержащие известные уязвимости
на момент выпуска, также могут подвергаться новым угрозам, возникающим с течением времени. План реагирова ния
на инциденты должен как минимум включать следующее:
a) назначенную группу инженерной поддержки или. если группа слишком мала, чтобы обладать ресурса ми
инженерной поддержки, предусмотренных планом реагирования на инциденты трех — пятерых чле нов
инженерно-технического персонала, трех — пятерых членов персонала, занимающихся маркетингом и
связями с клиентами, и, по крайней мере, двух членов административного персонала, являющихся
первыми контактными лицами в случае чрезвычайной ситуации, связанной с безопасностью:
b
) круглосуточную телефонную связь с принимающим решения органом;
c) планы оказания услуг по безопасности для программ, предоставляемых другими группами в рамках
организации:
d) планы оказания услуг по безопасности для лицензионных программ сторонних производителей — они
включают имена файлов, версии, исходный код программы, контактную информацию третьей стороны и
договорное разрешение на внесение изменений (в соответствующих случаях):
16) Окончательная проверка безопасности: Окончательная проверка безопасности (Final Security Re
view — FSR) — это продуманное изучение всех мероприятий по обеспечению безопасности, реализованных для
прикладных программных средств до их выпуска. FSR проводится куратором по обеспечению безопасности при
поддержке штатного коллектива разработчиков и руководящими лицами групп по вопросам приватности. FSR —
это не проведение «проникновения и установления патчей» и не возможность проведения мероприятий по обеспе
чению безопасности, которые ранее игнорировались или были забыты. FSR обычно включает изучение моделей
угроз, запросы исключительных ситуаций, выходные данные инструментальных средств и функционирования от
носительно ранее определенных границ качества/порога ошибок."* FSR гложет приводить к одному из следующих
трех результатов:
a) FSR пройдена — все проблемы безопасности и приватности, идентифицированные в ходе FSR. ре
шены или уменьшены;
45