Сегодняшняя сверхконкурентная бизнес-среда требует от организаций быстрого развития и сохранения инноваций. В результате 80% и более организаций приняли гибкий подход к разработке. К сожалению, такая более высокая скорость разработки открывает ряд возможностей для использования киберпреступниками, особенно если процессы жизненного цикла программного обеспечения не защищены.
Итак, как организации могут сделать методы гибкой разработки более безопасными? Вот 10 принципов, которые рекомендует ISF:
Определить роли и обязанности
Старшие руководители, ответственные за управление гибкими проектами, должны четко определить роли и обязанности в сфере безопасности. Это включает в себя установление формальных и неформальных линий отчетности, а также действия по управлению проектом, такие как протоколы эскалации, обязательные встречи и отчеты о статусе проекта группам безопасности. Это поможет внедрить безопасность в гибкую разработку приложений, одновременно повышая приверженность, подотчетность и конструктивные отношения между бизнесом, ИТ и ИБ.
Инвестируйте в навыки и обучение
Безопасность — это командный вид спорта. Каждый разработчик должен внести свой вклад в обеспечение отсутствия в коде лазеек в безопасности. Разработчикам часто не хватает знаний и понимания проблем безопасности, и они склонны отдавать приоритет доставке программного обеспечения в ущерб безопасности. Чтобы расширить возможности разработчиков, организации должны инвестировать ресурсы в обучение, наставничество и повышение квалификации. Это включает в себя сочетание обучения и ознакомительных занятий по безопасности, наставничество со стороны старших разработчиков, специализированные обучающие мероприятия по гибкой безопасности, а также доступ к свободно доступным ресурсам, таким как OWASP, CWE, BSIMM (модель зрелости ИБ), SAFECode и CERT.
Применить процесс управления информационными рисками
Дешевле и эффективнее запрограммировать безопасность с самого начала, а не пытаться добавить ее после того, как “пирог вынут из духовки”. Руководство должно установить процессы, которые помогают управлять информационными рисками на протяжении всего жизненного цикла разработки.
Это включает в себя согласование высокоуровневой архитектуры приложений с точки зрения безопасности, определение списка «критичных для безопасности» приложений и функций, выполнение оценки воздействия на бизнес, проведение оценок информационных рисков и уязвимостей на ранних этапах, а также процесс отчетности о вновь выявленных риски. Руководство должно дать указания о том, кто является владельцем информационных рисков, определить процесс анализа рисков и определить, как принимаются решения по управлению рисками .
Укажите требования безопасности, используя формат разработчика
Используйте формат разработчиков (пользовательские истории, спецификации требований к программному обеспечению, отображение историй, каркасы, персонажи и варианты использования) для формулирования требований безопасности, чтобы разработчики могли лучше понимать, определять и реализовывать спецификации безопасности.
Это позволяет рассматривать требования безопасности как функциональные требования в бэклоге продукта, преобразовывая их в задачи (так называемые декомпозиции), включая их в инструменты управления требованиями и включая их в показатели производительности проекта (такие как продолжительность работы и скорость).
Провести моделирование угроз
Регулярно проводить упражнения по моделированию угроз, чтобы понять контекст безопасности приложения, выявить незащищенные аспекты дизайна, выявить, проанализировать и расставить приоритеты угроз; обнаружить наиболее распространенные приемы и методы, используемые для атаки на приложение (подмена, фальсификация, отказ в обслуживании, повышение привилегий), определить, какие угрозы требуют дополнительного тестирования безопасности и, что наиболее важно, разработать стратегии и решения для активного противодействия каждой угрозе.
Используйте безопасные методы программирования
Обязать разработчиков использовать признанные методы безопасного программирования, такие как парное программирование, рефакторинг, непрерывное улучшение/непрерывная разработка (CI/CD), экспертная оценка, итерации безопасности и разработка через тестирование.
Это улучшает нефункциональные качества кода приложения и помогает устранить программные дефекты, позволяющие использовать уязвимости безопасности. Методы безопасного программирования также полезны для направления разработчиков, не имеющих опыта в безопасных методах, использования новых технологий, таких как искусственный интеллект или “мало кода/без кода”, разработки сложного аспекта приложения, интеграции сторонних приложений или соблюдения требований соответствия.
Проводить независимые проверки безопасности
Попросите независимых рецензентов выполнить статический анализ кода (проверьте исходный код для анализа ошибок, ошибок и лазеек в коде приложения) и динамический анализ (проверьте поведение приложения во время выполнения, чтобы выявить необычное или неожиданное поведение). Это дает заинтересованным сторонам уверенность в том, что приложение соответствует требованиям безопасности и не содержит каких-либо уязвимостей.
Автоматизируйте тестирование безопасности
Обычно командам безопасности не представляется возможным вручную тестировать и оценивать каждую итерацию гибкой разработки. Вот почему необходимо использовать тот или иной тип автоматизации, который может постоянно проверять безопасность кода приложения на наличие дефектов и уязвимостей, обеспечивать последовательное и методическое выполнение задач, связанных с безопасностью, анализировать события безопасности, а также снижать нагрузку на группы безопасности и разработчиков. Однако не все можно автоматизировать, и автоматизация не может полностью заменить ручное тестирование. Например, необходима ручная проверка для выявления логических ошибок.
Включите безопасность в критерии приемки
Создавать, сообщать и поддерживать стандартный набор критериев приемлемости безопасности для подтверждения того, что независимая проверка кода приложения была выполнена; тестирование безопасности завершено; разделы кода, включенные в приложение, легко обслуживаются, отслеживаются и происходят из проверенных и авторитетных источников; требования из журнала итераций успешно выполнены; все дефекты, включая уязвимости безопасности, были устранены, а любые изменения спецификации, которые могли повлиять на безопасность, были выявлены и одобрены.
Это помогает сократить технический долг, предоставить гарантии заинтересованным сторонам и убедиться, что критерии приемлемости безопасности полностью соблюдены, прежде чем будет доставлен код приложения.
Оцените эффективность безопасности
Гибкие проекты обычно включают ограниченную оценку эффективности безопасности. Из-за этого организациям сложно определить, соответствует ли безопасность их приложений бизнес-требованиям. Поэтому важно, чтобы организации отслеживали и оценивали соответствующие показатели безопасности по согласованному набору ключевых показателей эффективности.
Метрики безопасности могут включать в себя такие вещи, как тип, количество и серьезность уязвимостей безопасности, результаты независимого тестирования, количество утвержденных и неутвержденных отклонений от политики безопасности, продолжительность времени без нарушений безопасности и другие показатели устранения дефектов.
Если ваша разработка гибкая, то информационная безопасность должна последовать этому примеру. Вот почему всем организациям рекомендуется следовать приведенным выше принципам безопасности и передовым практикам. Успех в области безопасности зависит от уровня сотрудничества и обязательств между всеми сторонами (разработчиками, менеджерами проектов, командами исполнителей и т. д.). Если процессы безопасности могут выполнять быстрые итерации и улучшения, также как и кодирование, только тогда можно обеспечить лучшую безопасность приложений.
Достаточно банальные принципы. Не надоест же людям писать одно и то же ради копирайта.