Может казаться невозможным разрабатывать программное обеспечение и поддерживать его встроенную безопасность, поскольку вы потенциально добавляете новые уязвимости в продукт по мере его обновления. Следовательно, чтобы снизить риск в процессе разработки программного обеспечения и проектирования, вам необходимо привлечь специалистов по кибербезопасности на протяжении всего жизненного цикла разработки программного обеспечения (SDLC ), чтобы придумать зрелый профиль безопасности. Это руководство полезно только крупным компаниям с большими международными проектами.

Руководящие принципы по снижению рисков SDLC

В разработке программного обеспечения смягчение рисков аналогично процессам, которым следуют традиционные предприятия. В проекте Open Web Application Security Project (OWASP) указано, что модель зрелости Software Assurance (SAMM) должна быть сосредоточена на оценке, разработке и реализации надежной стратегии безопасности программного обеспечения, которая может легко интегрироваться в SDLC.

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

Как SAMM подходит к снижению рисков

Проект Open Web Application Software (OWASP) включает в себя реагирование на риски и снижение рисков на протяжении всего цикла разработки программного обеспечения. Функционально каждая из групп в организации, работающих над процессом разработки программного обеспечения, сохраняет ответственность в разные моменты своего цикла.

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

1. Обязанности функций управления

Согласно определению OWASP, управление фокусируется на бизнес-результатах и результатах, включая стратегию и метрики (SM), политику и соответствие (PC), а также образование и руководство (EG).

• Практика стратегии и метрик (SM): она направлена на создание основы для программы обеспечения безопасности программного обеспечения в вашей организации, чтобы определить измеримые цели безопасности в соответствии с вашим реальным бизнес-риском.
• Практика политики и соответствия (PC): обеспечивает соблюдение, не только внедряя внутренние стандарты безопасности, но и концентрируя внимание на соблюдении внешних нормативных и правовых требований. PC Practice создает аудиты для обеспечения необходимой гарантии.
• Практика обучения и руководства (EG): она направлена на то, чтобы вооружить весь персонал, работающий над жизненным циклом программного обеспечения, ресурсами и знаниями, которые им необходимы для разработки и развертывания безопасного программного обеспечения.

2. Обязанности строительных функций

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

• Практика оценки угроз (ТA). В рамках практики ТA вы сосредотачиваетесь на выявлении и анализе рисков. Это позволяет вам сохранять бдительность в отношении потенциальных угроз, рассматривать предстоящее воздействие, а также вероятность его возникновения. Оценка угроз - это первый шаг к снижению риска в разработке программного обеспечения.
• Практика требований к безопасности (SR): Практика SR сначала анализирует все требования и протоколы безопасности высокого уровня на основе того, как ваша организация намерена использовать разрабатываемое программное обеспечение. Затем SR Practice анализирует новые риски и возможные стратегии их снижения по мере развития вашего программного обеспечения. Поэтому вам следует учитывать взаимодействие с поставщиками и следовать стандартам аудита соглашений об уровне обслуживания (SLA).
• Практика безопасности архитектуры (SA). Практика безопасности позволяет вам создавать безопасность по умолчанию, а не ждать, пока вы не завершите свое программное обеспечение. Эта практика гарантирует, что ваше программное обеспечение остается безопасным в процессе разработки, поскольку оно уязвимо для атак даже до его завершения.

3. Обязанности функций проверки

Проверка относится к процессу постоянного анализа, оценки и тестирования программного обеспечения на наличие новых угроз безопасности.

• Практика проверки проекта (DR): эта практика оценивает дизайн и архитектуру программного обеспечения для выявления и немедленного решения проблем на ранней стадии. Его основная цель - выявление, обнаружение и устранение угроз безопасности, прежде чем они станут дорогостоящими.
• Практика проверки реализации (IR). Практика проверки IR позволяет проверять исходный код и другие конфигурации на наличие уязвимостей в безопасности. На ранних этапах разработки вы можете использовать простые контрольные списки. Тем не менее, зрелые компании-разработчики программного обеспечения полагаются на автоматизацию для обеспечения большего охвата.
• Практика тестирования безопасности (ST): Практика ST рассматривает безопасность в среде выполнения, чтобы функционально посмотреть на нее, как это будет происходить позже после развертывания. Таким образом, эта практика может включать традиционное тестирование на проникновение для случаев высокого уровня или оценку других неправильных конфигураций.
• 

4. Обязанности операционных функций

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

• Практика управления проблемами (IM). Эта практика по существу создает процессы для обработки операционных инцидентов и отчетов о проблемах путем назначения ролей, отслеживания проблем и рисков и организации официальных процессов реагирования на инциденты. Это также требует общения между заинтересованными сторонами.
• Практика усиления защиты окружающей среды (EH). Эта практика защищает разрабатываемое ПО, обеспечивая, чтобы его базовая инфраструктура поддерживала свое состояние безопасности вместо того, чтобы подрывать его. Гибкое развертывание исправлений безопасности требует, чтобы ваша команда разработчиков была информирована и находила эффективные способы проверки операционной среды.
• Практика предоставления поддержки операций (OE). Основное внимание здесь уделяется мониторингу рисков, чтобы проектные группы сообщали обо всех рисках операторам и пользователям. Поэтому вам необходимо создать подробную документацию, которая нужна операторам и пользователям, и делиться ими с каждым выпуском.

Важность встраивания безопасности в разработку программного обеспечения

Поскольку потребность в использовании платформ Software-as-a-Service становится все более популярной во всем мире, и все больше компаний, внедряющих эту услугу, становится очевидным, что SaaS и другие службы программного обеспечения, создают, возможно, наиболее существенные риски утечки данных. Следовательно, из этого следует, что вы сможете получить конкурентное преимущество на рынке, сосредоточившись на безопасности как на своем главном отличителе в качестве поставщика услуг программного обеспечения.

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

Как решения GRC Management позволяют управлять рисками

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

Именно здесь появляются решения по управлению рисками и соответствием требованиям (GRC), поскольку они всегда позволяют вам управлять задачами и определять их приоритеты, позволяя всем участникам знать, что делать. Решения по управлению GRC позволяют назначать задачи группе, отвечающей за анализ рисков, оценку рисков и снижение рисков. 

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