Практика Agile

В настоящее время широкую известность получила методология гибкой разработки программного обеспечения Agile («живой, подвижный» или «гибкий»). Актуальность этой методологии объясняется несовершенством (недостаточностью) известных «тяжелых» и «неповоротливых» практик разработки программного обеспечения на основе традиционной «водопадной» модели программотехники.

Основными причинами повышенного интереса разработчиков приложений к методологии гибкой разработки программного обеспечения Agile стали:

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

  • заказчик предложил идею, но как ее реализовать на практике, он не знает;

  • команды проекта не может выработать единое мнение о функциональности решения;

  • команда проекта не может договориться об оптимальной программе действий.

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

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

Методология Agile позволяет оперативно вносить изменения и наращивать функциональность решения.

Улучшение коммуникационных возможностей. Agile-подход акцентируется на непосредственном общении постановщиков задачи и разработчиков лицом к лицу. Большинство Agile-команд располагаются в одном офисе, иногда называемом bullpen. В состав команды включается «заказчик» (product owner) или его полномочный представитель, который определяет требования к результату разработки; эту роль может также выполнять менеджер проекта, бизнес-аналитик или клиент. Также в состав команды включают дизайнеров интерфейса, тестировщиков, технических писателей и других специалистов.

Методология Agile декларирует что сотрудничество с заказчиком важнее, чем контрактные обязательства. Отдавая предпочтение непосредственному общению, методология Agile позволяет значительно уменьшить объём письменной документации по сравнению с другими подходами к разработке ПО.

С какими трудностями приходится сталкиваться разработчикам при использовании методологии Agile?

Коллектив разработчиков должен трансформироваться в полноценный так называемый трайб со своими кластерами и функциональными командами (скводами и чаптерами). В качестве инструмента автоматизации деятельности трайба можно выбрать, например, решение Atlassian JIRA, которое способно поддерживать сотни и тысячи активных задач. Нужно научиться работать в спринтах и производить расчет задач по story point’ам, которые можно учитывать, в том числе, и в системе мотивации разработчиков. Наконец, необходимо наладить полноценное управление изменениями, Change с использованием Agile-практик, а также решение оперативных задач по разработке цифровых платформ.

От Agile к SecAgile

Для разработки именно безопасных цифровых платформ рекомендуется добавить в классическую методологию Agile ряд специальных методических приемов.

Необходимость учета требований безопасности

Сегодня к лучшей практике безопасной разработки программного обеспечения относятся требования и рекомендации: SDL PCI DSS, SDL Microsoft, SDL Cisco, 7.3.5 СТО БР ИББС-1.4-2018 и др.

Практика SDL Microsoft

Так, например SDL Microsoft в состав мер безопасной разработки ПО включает следующий типовой набор мер: обучение, задание требований безопасности, проектирование, риск-анализ архитектуры ПО (моделирование угроз безопасности информации), статический и динамический анализа исходного кода программ, тестирование безопасности, выпуск и поддержка.

Однако упомянутая практика не содержит рекомендаций для независимой оценки полноты и достоверности реализованных мер безопасности. Отметим, что требования так называемых «Общих критериев» (ISO/IEC 15408), широко используемых для оценивания программного обеспечения по требованиям безопасности информации, также функционально ограничены. Например, применяются только для программного обеспечения с функциями безопасности, а номенклатура мер не содержит требования статического и динамического анализа, обучения и пр.

Основные этапы методики обоснования мер

Поэтому для снятия указанных ограничений предлагается воспользоваться рекомендациями национальных стандартов:

  • ГОСТ Р 56939 «Защита информации. Разработка безопасного программного обеспечения. Общие требования». Содержит ряд общих требований к реализации мер по разработке безопасного ПО;

  • ГОСТ Р «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Определяет номенклатуру типовых угроз безопасности информации;

  • ГОСТ Р «Защита информации. Разработка безопасного программного обеспечения. Руководство по разработке программного обеспечения». Включает свод практических рекомендаций по реализации мер разработки безопасного ПО согласно ГОСТ Р 56939;

  • ГОСТ Р «Защита информации. Разработка безопасного программного обеспечения. Методика оценки соответствия». Описывает ряд типовых процедур по проверке соответствия организаций — разработчиков ПО требованиям ГОСТ Р 56939.

Такая модифицированная методика SecAgilе позволила решать следующие актуальные задачи разработки безопасного ПО:

  • оценить достаточность мер, направленных на уменьшение количества уязвимостей в разрабатываемом ПО, и их применимость при проведении оценки соответствия ПО;

  • сформировать базовый набор требований к разработке безопасного ПО, позволяющих проводить оценку соответствия процессов данным требованиям;

  • разработать методику обоснованного формирования множества мер разработки безопасного ПО.

Отметим, что для формирования мер и средств контроля и управления безопасностью ПО можно также использовать рекомендации ГОСТ Р ИСО/МЭК 27034-1, а для конкретизации и расширения компонентов доверия — рекомендации ГОСТ Р ИСО/МЭК 15408-3.

Заключение

На практике использование адаптированной методологии SecAgile позволяет:

  • определить характеристики среды разработки безопасных цифровых платформ;

  • осуществить обоснованный выбор процессов, задач и работ из номенклатуры ГОСТ Р ИСО/МЭК 12207 с учетом характеристик среды разработки, а также требований к соответствующим цифровым платформам;

  • уточнить перечень задач и работ с учетом предлагаемой номенклатуры мер по разработке безопасных цифровых платформ из ГОСТ Р 56939;

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

Существенно, что это позволяет реализовать следующие два основных сценария:

  • декларация соответствия: в этом случае разработчиком цифровой платформы должны быть реализованы все меры, предложенные в стандарте ГОСТ Р 56939, и созданы соответствующие свидетельства;

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

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

Сергей Петренко, руководитель направления информационной безопасности Академии АйТи, конструктор и практик в области защиты объектов КИИ РФ, д. т. н., профессор

Источник.