Жизненный цикл разработки программного обеспечения, или то, что известно под аббревиатурой SDLC, - это весь процесс, который происходит в любой новой разработке в организации от идеи до того, как она уже реализована в производстве.
В последнее время стремятся обеспечить безопасность в этом процессе, так как вся разработка имеет свои основные фазы (как показано на следующем изображении слева), то, что делается путем внедрения безопасности, является определение некоторых этапов. При этом во время работы учитывается безопасность (как показано на изображении справа):
Жизненный цикл программного обеспечения и безопасность
На предыдущих изображениях мы видим, что каждая фаза имеет соответствующую фазу безопасности, например, в то время, когда проводятся тесты правильной работы приложения, должен проводиться динамический аудит, в котором они могут быть видны. уязвимости до стадии производства.
Осуществление мер безопасности должно быть сделано с самого начала разработки программного обеспечения жизненного цикла, так как стоимость решения любой проблемы безопасности выше чем позже обнаруживается, как показано на следующем графике:
Безопасность в разработке программного обеспечения
В конце концов, во многих организациях или отделах разработки из-за того, что в них не реализована безопасность, мы склонны делать много заведомо неверных оправданий, например следующие:
- Никто не знает, как это работает, поэтому и нападать не будут. (Злоумышленник потратит необходимое ему время, чтобы узнать, как это работает…) Если до сих пор не было обнаружено уязвимостей (злоумышленник найдет одну или несколько уязвимостей, просто взглянув на нее…) Никто не будет заинтересован в атаке на наше приложение. (Существуют миллионы ботов или автоматизированных систем, которые постоянно сканируют на предмет недостатков безопасности…) Приложение безопасно, потому что оно работает за брандмауэром. (Очевидно, что если у него есть аппаратный элемент безопасности, он более безопасен, но этот факт никогда не будет означать, что он безопасен…) Приложение безопасно, потому что оно использует https. (В этом случае связь безопасна, но разработка не обязательна…) Если она не запущена как администратор / root, вы не можете делать ничего опасного.(Очевидно, это хорошая практика безопасности, но тот факт, что у пользователя низкие привилегии, не означает, что приложение безопасно…)
Среди всех возможных оправданий невыполнения безопасности в SDLC наиболее часто звучит то, что « некогда включать безопасность », поскольку большинство разработок очень сжатые по времени, и важнее запустить что-то в производство. в соответствующий период включить обеспечение в каждую из его частей.
Вы должны думать, что «Предотвращение лучше, чем лечение», поэтому гораздо более продуктивно и менее опасно предотвратить или обнаружить атаку для развития, чем восстановить состояние после успешной атаки.
Чтобы этого не происходило и для его безопасной разработки, необходимо реализовать несколько моделей безопасности, одна из наиболее рекомендуемых обычно реализуемых моделей - это модель зрелости Software Assurance (SAMM - Software Assurance Модель зрелости) - это открытая и гибкая структура, разработанная OWASP.
Эта модель помогает организациям сформулировать и реализовать стратегию безопасности для разработки программного обеспечения, которая соответствует конкретным потребностям каждой организации и имеет, среди прочего, следующие характеристики:
- Он состоит из нескольких коротких циклов (достижимые цели) и последовательных итераций (конечные цели). Гибкость и настраиваемость, основанная на терпимости к риску, критичности разрабатываемых приложений и методологии разработки… Простые, измеримые и четко определенные действия по обеспечению уверенности.
Он призван помочь:
- Оцените существующие в организации методы обеспечения безопасности при разработке программного обеспечения. Постройте сбалансированную программу Software Assurance, выполнив четко определенные итерации. Продемонстрируйте конкретные улучшения в программе Software Assurance. Определите и оцените действия, связанные с безопасностью разработки программного обеспечения в организации.
Все эти цели определены в соответствии со структурой следующего изображения, на котором можно наблюдать различные составляющие его части и взаимосвязь между ними:
Разработка программного обеспечения
Как видно на изображении, эта методология OpenSAMM устанавливает:
- 4 бизнес-функции, связанные с разработкой программного обеспечения 3 практики безопасности для каждой бизнес-функции 3 уровня зрелости для каждой практики безопасности 2 действия по обеспечению безопасности для каждого уровня зрелости
Поэтому всем компаниям рекомендуется выполнять эту структуру на общем уровне всегда в виде внутренних правил и применять ее ко всем разработкам, которые в них производятся. После его внедрения вся безопасность будет осуществляться автономно и будет входить в обычные непрерывные процессы компании.
Для получения дополнительной информации об этой модели и о том, как лучше всего внедрить ее в компаниях, мы можем увидеть ее последнюю версию на испанском языке по следующему веб-адресу:
www.opensamm.org/downloads/SAMM-1.0-es_MX.pdf
Фернандо Сааведра
Менеджер по кибербезопасности
Áudea Информационная безопасность
