Оценка рисков приложений

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

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

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

Процесс финальной ревизии безопасности приложения.

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

Процесс принятие решенияPMи/или руководством о модификации рисков

Именно в рамках принятия решений о модификации рисков происходит рассмотрение рисков безопасности и принятия решений по их модификации, т.е. риски могут быть: 1) приняты, 2) уменьшены или 3) переданы.

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

Процесс обращения к заказчику по поводу решений о модификации рисков.

Это и есть ситуация, когда необходимо для принятия решения о модификации рисков обращаться к заказчику. Например, это могут быть риски, которые могут потребовать больших затрат ресурсов для их устранения, но, допустим, из-за природы этих рисков заказчик вполне может принять такие риски, но, допустим, вывести этот ослабляющий безопасность функционал из конфигурации по умолчанию. Возможно, заказчик обладает другими средствами, которые позволяют принять или же передать риск, и по сути, программирование может быть ненужно.

Процесс отслеживания ошибок безопасности разработки.

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