В то время как Agile‑разработка становится все более популярной, информационной безопасности становится все сложнее с ней взаимодействовать. Результатом этих проблем становится то, что новые системы оказываются незащищенными, либо в них используются наложенные средства для обеспечения безопасности. В этой статье мы рассмотрим, какие сложности возникают при использовании решений информационной безопасности в Agile.
Но для начала рассмотрим, что из себя представляет методология Agile, и чем она отличается от классической Waterfall.
Waterfall
Waterfall — это подход к управлению проектами и разработке программного обеспечения, при котором соблюдается линейная последовательность событий. В Waterfall каждая фаза проекта является закрытой. Команда не может перейти от одной фазы разработки к другой, пока не завершится текущая фаза. Каждая фаза имеет четко определенные критерии завершения. Критерии проекта формируются на первой стадии Waterfall — стадии требований — и закрепляются в документации (ТЗ). Требования, сформулированные в самом начале, в идеале не меняются в ходе проекта разработки в этой модели.
Такой подход применим для проектов, требующих большого объема документации и имеющих повторяющиеся, предсказуемые процессы. Модель Waterfall особенно эффективна для проектов с четко определенными требованиями и минимальными ожидаемыми изменениями, обеспечивающими последовательность и прослеживаемый контроль.
Agile
Agile — это подход к управлению проектами, в частности проектами по разработке программного обеспечения, в котором приоритетными являются сотрудничество, непрерывная работа и обратная связь с клиентами. Agile разбивает работу на итерационные шаги, которые представляют собой небольшие задачи, которые можно быстро выполнить. Эти итерации выполняются в течение спринтов. Agile‑команды завершают один спринт, после чего переходят к следующему. Требования могут меняться в любой момент проекта в зависимости от изменений потребностей бизнеса или отзывов клиентов. Будущие спринты основываются на результатах предыдущих.
Существует несколько фреймворков — например, Kanban, Scrum и feature‑driven development — которые помогают командам разработчиков внедрить Agile на практике и реализовать 12 принципов, изложенных в Agile Manifesto. Таким образом, Agile лучше всего подходит для проектов, которые имеют гибкие процессы и учитывают обратную связь с клиентами на протяжении всего процесса.
Agile vs. Waterfall
Agile‑разработка программного обеспечения делает акцент на итеративной работе. Это отличает Agile от Waterfall, который подразумевает групповую разработку, где все работы должны быть завершены в одной точке, прежде чем переходить на следующий этап разработки ПО.
Благодаря подходу, основанному на небольших изменениях, сложные процессы разработки программного обеспечения становятся отслеживаемыми и управляемыми для всех заинтересованных сторон. Если команды разработчиков пытаются изменить слишком много кода сразу — например, если они пытаются создать несколько новых функций одновременно, — они рискуют столкнуться с непредвиденными проблемами, которые затянут проект. Эти задержки могут создать проблемы для других заинтересованных сторон — например, для бизнес‑подразделения, которое ожидает, что новая функция будет доступна к дате начала проекта.
Agile ограничивает объем работ и фокусируется на адаптации к изменяющимся обстоятельствам. Эти черты делают Agile полезным для сложных проектов, в которых могут возникнуть непредвиденные проблемы, требующие от команды разработчиков перестройки в ответ на них.
Склонность проектов Waterfall выходить за пределы запланированных сроков и объема означает, что сегодня Waterfall используется редко. В целом, большинство команд предпочитают Agile.
Выбрав Agile‑подход, разработчики могут получить ряд преимуществ, в том числе следующие:
Повышение эффективности. Изолированные изменения помогают разработчикам тратить меньше времени на внедрение ненужной функциональности или поиск источников ошибок.
Более быстрый выпуск программного обеспечения. Agile помогает разработчикам избежать задержек в рамках цикла выпуски ПО. Разработчики могут быстрее переходить к другим задачам, когда они не ждут одного большого релиза. Это также выгодно пользователям, которые быстрее получают новые функции.
В Agile команды могут менять планы, если они решили, что им не подходит та или иная функция. В водопаде команда берет на себя обязательства по множеству взаимозависимых изменений, которые реализуются одновременно. Когда несколько проектов объединяются в рамках разработки Waterfall, отмена или изменение одних правок влияет на другие.
Благодаря тому, что проекты выполняются в срок и в соответствии с поставленными задачами, Agile помогает разработчикам эффективно сотрудничать с заинтересованными сторонами. Среди заинтересованных сторон могут быть бизнес‑пользователи, которые ожидают новую функцию к определенной дате, или ИТ‑команды, которым необходимо обеспечить инфраструктуру для размещения нового релиза приложения.
Пользователи программного обеспечения выигрывают от Agile, поскольку изменения поступают небольшими партиями. Им не приходится сразу адаптироваться к совершенно новой версии приложения, которое было серьезно переработано, как это было бы, если бы разработчики придерживались подхода Waterfall.
Тем не менее, Waterfall может подойти для проектов по разработке программного обеспечения, если верно следующее:
Требования к проекту четко определены, что означает отсутствие необходимости в процессах детального планирования, анализа и проектирования.
Общий объем работ, необходимых для выполнения требований, невелик.
Разработчиков всего несколько человек, и они могут эффективно сотрудничать без использования Agile‑фреймворка.
Сроки выполнения проекта гибкие.
В этих условиях Waterfall может быть предпочтительнее, поскольку он не требует такого большого объема планирования и организации работы.
Проблемы ИБ и Agile
Общепринятым подходом к работе в рамках управления безопасностью является подход Waterfall. Так популярные системы информационной безопасности (например, ISO27 001) используют подход «сверху вниз»: Они подчеркивают, что для обеспечения контроля над информационной безопасностью в организации должны быть разработаны политики, процессы и общие технические средства контроля. Как только все это будет разработано, проекты могут начать опираться на эту основу безопасности и использовать услуги управления безопасностью. Это хорошо работает в проектах, которые следуют модели Waterfall, с четко определенными моментами перехода и результатами. Вопросы информационной безопасности часто рассматриваются в начале и в конце проекта.
Однако, как мы уже рассмотрели, Agile придерживается другой модели: он использует подход, основанный на рисках, для инкрементной разработки, используя короткие циклы разработки, называемые спринтами. Спринт достаточно мал, чтобы быть управляемым, и это заставляет владельца продукта устанавливать приоритеты. Все запросы на новые функции собираются в бэклог. Для каждого спринта производится отбор запросов, исходя из их ценности для бизнеса, срочности, простоты реализации, требований заказчика и т. д. Если функция или требование слишком сложны или потребуют слишком много времени для реализации, они могут быть разбиты на более мелкие части и реализованы в течение нескольких спринтов. Результаты тестирования предыдущих спринтов учитываются в следующих, чтобы способствовать постоянному совершенствованию в ходе выполнения спринтов.
При этом, традиционная безопасность предполагает, что проектная команда переводит общие требования безопасности в соответствующие средства контроля безопасности и у команды есть время, навыки и инструменты для правильной реализации средств контроля. Во время разработки проекта есть достаточно времени и средств для проведения теста или тестов безопасности и обработки полученных результатов. А также, имеется достаточно времени для устранения рисков безопасности, обнаруженных в ходе проекта и тестирования.
Но в Agile‑среде все не так просто. Во‑первых, у владельца продукта есть другие приоритеты, кроме перевода требований безопасности в средства управления. В рамках agile‑подхода время имеет решающее значение, и большинство, если не все, ресурсы направлены на создание следующей итерации необходимых элементов и создание ценности для бизнеса.
Здесь необходимо соблюдение определенного баланса между скоростью разработки программного обеспечения и требованиями безопасности, так как в случае полного игнорирования требований ИБ мы также рискуем получить некачественный продукт, как и в случае игнорирования каких‑либо функциональных требований.
Во‑вторых, у команды разработчиков может не хватать навыков, знаний и опыта для внедрения средств контроля безопасности. Разработчики могут не знать о некоторых уязвимостях, которые могут присутствовать в используемых зависимостях, и не иметь надлежащей подготовки для разработки безопасного кода.
Здесь от команды разработчиков требуется пройти обучение по вопросам информационной безопасности. Так каждый программист должен иметь базовые представления о том, какие есть уязвимости для используемых им средств разработки, как есть небезопасные функции и прочее.
Также не лишним было бы наличие в команде так называемого Secuirty champion — разработчика, хорошо разбирающегося в вопросах информационной безопасности, способного проводить ревью чужого кода на наличие потенциальных ошибок и уязвимостей.
В‑третьих, в проекте отсутствует традиционная фаза тестирования, когда продукт замораживается, где можно проверить все функциональные и нефункциональные требования и устранить проблемы. Система разрабатывается и выпускается в потоке небольших, инкрементных циклов. Каждый цикл определяет, что будет разработано и поставлено в следующем цикле, и «предсказуемость» проекта, возможно, на два или три цикла вперед. Чаще всего разные итерации идут параллельно и встречаются где‑то дальше по дороге.
Тестирование безопасности ограничено продуктами, которые доступны в спринте, и управление безопасностью часто не в состоянии адаптироваться к этой динамике. В результате часть функционала может оказаться не покрыта тестами по безопасности, что в итоге может привести к уязвимостям в выпускаемом программном продукте.
В‑четвертых, существует и культурная проблема. Не все, но большинство разработчиков не испытывают теплых чувств при упоминании термина «информационная безопасность». Они знают, что это создает много накладных расходов, когда от них требуется включить средства контроля безопасности. Прямой выгоды (то есть функциональности) от внедрения средств контроля безопасности нет, но их реализация может занять значительное время разработчиков и помешать им реализовать другие возможности и функции.
Эта проблема должна решаться с помощью внедрения культуры DevSecOps, как этапа развития DevOps. То есть безопасность должна интегрироваться на всех этапах разработки программного обеспечения, начиная от проектирования и заканчивая проведения тестов по безопасности, выпуска решения в продуктивную среду и сопровождения. У разработчиков должно быть понимание того, что безопасность является неотъемлемой частью разработки качественного решения и без нее нельзя достичь хороших результатов.
Заключение
Разработка современных приложений является достаточно сложным процессом, требующим участия различных специалистов, в том числе и специалистов по информационной безопасности. Гибкая модель разработки Agile позволяет ускорить процесс выпуска программного обеспечения, однако при ее использовании нельзя пренебрегать вопросами безопасности. Необходимо встраивать механизмы защиты непосредственно в разрабатываемое решение, тем самым увеличивая общий уровень защищенности выпускаемого программного продукта.
Внедрение безопасности в процесс разработки — это не просто необходимость, а фактор, определяющий успешность проекта. Чтобы глубже разобраться, как эффективно интегрировать принципы безопасности в вашу практику Agile, приглашаем на открытые уроки:
Выстраивание архитектуры мониторинга инфраструктуры организации с использованием SIEM‑систем: оптимизация сбора, обработки и хранения событий безопасности — 23 апреля 20:00
Экономика безопасной разработки — разбор с пристрастием! — 23 апреля 20:00
DevSecOps, AppSec, Pentest: где начинается одно и заканчивается другое? — 7 мая 20:00
Каждый из этих уроков даст вам ключевые знания о том, как оптимизировать процессы разработки и тестирования, не забывая при этом о безопасности на всех этапах.
А полный список уроков по управлению разработкой, как всегда, можно посмотреть в календаре.