Международные стандарты безопасной разработки: ликбез

DevSecOps — это не просто модное словечко, а целая философия, объединяющая разработку, безопасность и операции. Но как применить эту философию на практике? Здесь на помощь приходят международные стандарты.

В этой статье мы рассмотрим пять основных международных DevSecOps-стандартов: DSOMM, BSIMM, OWASP SAMM, Microsoft SDL и NIST SP 800-64. Мы разберем их особенности, сильные и слабые стороны, а также поговорим о том, как адаптировать эти стандарты к российским реалиям.

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

Статья написана по материалам лекции, которая входит в нашу программу стажировки для начинающих ИБ-специалистов по потоку DevSecOps.

В области безопасной разработки выделяют 5 основных международных DevSecOps-стандартов: 

1. DSOMM (DevSecOps Maturity Model);

2. BSIMM (Building Security In Maturity Model);

3. OWASP SAMM (Software Assurance Maturity Model);

4. Microsoft SDL (Security Development Lifecycle);

5. NIST SP 800-64 (Security Considerations in the System Development Life Cycle).

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

DSOMM 

DSOMM (DevSecOps Maturity Model) — модель зрелости для интеграции практик безопасности в процессы DevSecOps. Иными словами, это методология, с помощью которой можно оценить уровень зрелости конкретного процесса, реализованного в рамках безопасной разработки, выявить «подводные камни» и понять, как его можно улучшить. 

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

DSOMM определяет пять уровней зрелости по разным направлениям. Он выделяет основные домены, для каждого из которых прописан набор обязательных практик. Соблюдение этих практик позволяет оценить зрелость процессов в компании на определенном уровне. Стандарт доступен в интернете: https://dsomm.owasp.org/. 

DSOMM состоит из разделов, подразделов и уровней. Разделы представляют основные направления работы. Подразделы детализируют каждое направление. Уровни отражают степень зрелости процессов.

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

Преимущества DSOMM заключаются в том, что этот стандарт ориентирован на интеграцию безопасности в CI/CD-процессы. Модель нацелена на автоматизацию всех процессов на каждом этапе жизненного цикла разработки.

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

BSIMM 

BSIMM (Building Security In Maturity Model) — модель оценки зрелости процессов безопасности. Ее особенность — опора на реальные практики 135 компаний, а не только на теорию. BSIMM позволяет организациям сравнить свои процессы безопасности с лидерами отрасли. 

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

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

Методика опубликована на английском языке. Всего стандарт охватывает 12 практик, каждая из которых входит в один из четырех доменов. Каждой практике соответствует свой набор активностей. На скриншоте ниже — пример активностей, которые входят в практику «Стратегия и метрики» (домен «Управление»).

Преимущества BSIMM. Модель основана на реальных данных, может применяться компаниями разного размера и из разных отраслей.

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

OWASP SAMM

OWASP SAMM (Software Assurance Maturity Model) — это фреймворк для оценки и улучшения практик обеспечения безопасности в разработке программного продукта (ПП). Помогает идентифицировать и внедрять лучшие практики безопасности на всех этапах жизненного цикла разработки.

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

Стандарт разделен на пять основных направлений. Уровней нет, но каждое направление включает два стрима:

• Стрим A — направлен на создание и продвижение какой-то практики. 

• Стрим B — направлен на изменение и улучшение. 

Такая структура позволяет компаниям постепенно внедрять и совершенствовать практики безопасности. Стрим A закладывает основу, а Стрим B обеспечивает дальнейшее развитие.

Преимущества OWASP SAMM. Гибкость и адаптивность к разным организациям. Четкие инструкции, которые помогут повысить безопасность разработки.

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

Microsoft SDL

Microsoft SDL (Security Development Lifecycle). SDL — это набор практик и процессов, разработанный Microsoft для обеспечения безопасности программного обеспечения на протяжении всего жизненного цикла. Помогает разработчикам автоматизировать каждый этап разработки ПП.

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

Стандарт состоит из 10 практик-рекомендаций, которые необходимо выполнить, чтобы развить DevSecOps в полной мере: 

1. Установите стандарты безопасности, показатели и управление.

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

3. Выполните анализ проекта безопасности и моделирования угроз.

4. Определите и используйте стандарты криптографии.

5. Обеспечьте безопасность цепочки поставок программного продукта.

6. Обеспечьте безопасность инженерной среды.

7. Проведите тестирование безопасности.

8. Обеспечьте безопасность операционной платформы.

9. Внедрите мониторинг безопасности и реагирования.

10.  Проведите обучение по безопасности.

Преимущества Microsoft SDL. Стандарт широко распространен, Microsoft его активно поддерживает и развивает. Методология включает проверенные временем практики, на которые ориентируются разработчики Microsoft. Каждый этап SDL сопровождается подробной документацией, что облегчает внедрение и использование.

Недостатки Microsoft SDL. SDL менее гибок при работе в средах, не связанных с Microsoft. Небольшим компаниям может быть сложно внедрить SDL из-за его комплексности и ресурсоемкости.

NIST SP 800-64

NIST SP 800-64 (Security Considerations in the System Development Life Cycle) — это специализированный документ в семействе стандартов NIST. Хотя стандарты NIST в целом направлены на комплексное обеспечение безопасности, SP 800-64 фокусируется именно на безопасном цикле разработки. Документ, созданный Национальным институтом стандартов и технологий США, предлагает рекомендации по внедрению мер безопасности на каждом этапе создания программного обеспечения. Эти рекомендации применимы как для государственных учреждений, так и для частных компаний, стремящихся повысить безопасность своих разработок.

Стандарт выделяет 5 этапов цикла разработки. Каждый этап представлен в виде пошаговой схемы с рекомендациями по мерам безопасности. 

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

Преимущества NIST SP 800-64. Стандарт предлагает детальные рекомендации, применимые к различным типам систем. Он охватывает не только информационную безопасность и безопасную разработку, но и смежные области. Документ содержит конкретные указания по обеспечению безопасности контейнерной инфраструктуры, рабочего места разработчика, CI/CD и других систем, вовлеченных в процесс разработки. Такой комплексный подход позволяет создать целостную систему безопасности на всех уровнях разработки.

Недостатки NIST SP 800-64. Внедрение стандарта может оказаться сложным для небольших организаций из-за высокой бюрократической нагрузки. Полное соответствие техническим требованиям часто требует значительных финансовых вложений. Стандарт предполагает неукоснительное выполнение всех прописанных мер, что теоретически верно, но на практике может вызвать трудности. Возникает вопрос о том, как эффективно интегрировать эти требования в реальные рабочие процессы без ущерба для продуктивности.

Сопоставление стандартов с точки зрения фокуса

1. DSOMM (DevSecOps Maturity Model)

• Цель и подход. DSOMM направлен на интеграцию безопасности в процессы DevOps, уделяет особое внимание автоматизации и непрерывному совершенствованию.

• Ключевые особенности:

  • Автоматизация. Стимулирует внедрение автоматизированных проверок безопасности в конвейер CI/CD.

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

  • Уровни зрелости. Предлагает модель зрелости для оценки и улучшения практик DevSecOps со временем.

• Преимущества:

  • Ускоряет обнаружение и устранение уязвимостей.

  • Способствует более тесному сотрудничеству между командами.

• Ограничения:

  • Может требовать значительных изменений в процессах и инструментах.

  • Требует высокого уровня автоматизации и технической зрелости.

2. BSIMM (Building Security In Maturity Model)

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

• Ключевые особенности:

  • Индустриальные бенчмарки. Позволяет сравнивать свои практики безопасности с аналогичными организациями в отрасли.

  • Каталог активностей. Предоставляет список из более чем 100 конкретных действий по безопасности, наблюдаемых в успешных программах.

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

• Преимущества:

  • Основан на реальных данных и проверенных практиках.

  • Предлагает широкую перспективу на различные подходы к безопасности.

• Ограничения:

  • Описательный характер может затруднить применение без дополнительной интерпретации.

  • Не предоставляет пошаговых инструкций по внедрению.

3. OWASP SAMM (Software Assurance Maturity Model)

• Цель и подход: OWASP SAMM предлагает структурированный и пошаговый метод улучшения процессов безопасной разработки.

• Ключевые особенности:

  • Модульная структура. Разделен на бизнес-функции и практики безопасности, что позволяет сфокусироваться на конкретных областях.

  • Оценка и планирование. Предоставляет инструменты для оценки текущего состояния и планирования улучшений.

  • Гибкость. Адаптируется к различным методологиям разработки, включая Agile и Waterfall.

• Преимущества:

  • Предлагает детальный план действий.

  • Поддерживается сообществом и регулярно обновляется.

• Ограничения:

  • Может потребовать значительных ресурсов для полной реализации.

  • Требует вовлечения различных стейкхолдеров для эффективного внедрения.

4. Microsoft SDL (Security Development Lifecycle)

• Цель и подход: Microsoft SDL интегрирует практики безопасности на каждом этапе жизненного цикла разработки, стремясь снизить количество уязвимостей и повысить надежность продукта.

• Ключевые особенности:

  • Фазовый подход. Включает конкретные действия по безопасности на этапах от планирования до выпуска.

  • Лучшие практики. Включает моделирование угроз, стандарты безопасного кодирования и методы тестирования безопасности.

  • Соответствие требованиям. Помогает соблюдать регуляторные и отраслевые стандарты.

• Преимущества:

  • Проверен на практике в крупных проектах.

  • Предоставляет четкие руководства и инструменты.

• Ограничения:

  • Первоначально разработан для внутренних нужд Microsoft, может требовать адаптации.

  • Может быть сложен для малых и средних предприятий без соответствующих ресурсов.

5. NIST SP 800-64 (Security Considerations in the System Development Life Cycle)

• Цель и подход. NIST SP 800-64 предоставляет рекомендации по интеграции безопасности в информационные системы на протяжении всего жизненного цикла.

• Ключевые особенности:

  • Управление рисками. Подчеркивает важность управления рисками с момента создания системы до ее вывода из эксплуатации.

  • Интеграция в SDLC. Рассматривает безопасность на каждом этапе разработки, обеспечивая всесторонний подход.

  • Применимость. Хотя ориентирован на федеральные системы США, принципы могут быть применены в различных организациях.

• Преимущества:

  • Соответствует международным стандартам и лучшим практикам.

  • Помогает в достижении соответствия регуляторным требованиям.

• Ограничения:

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

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

Применение стандартов в реалиях российского рынка

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

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

Организации могут сочетать элементы разных моделей для создания оптимальной программы безопасности, соответствующей их уникальным потребностям. В отечественной разработке чаще используют комбинацию из трех стандартов: DSOMM, BSIMM и SAMM. Эта связка позволяет гибко адаптировать лучшие мировые практики к российским реалиям. Компаниям поменьше может быть проще начать с более легких моделей, таких как OWASP SAMM, а крупные предприятия могут извлечь выгоду из комплексных подходов Microsoft SDL или NIST SP 800-64.

Стандарт NIST, несмотря на свою комплексность, имеет существенный недостаток для российского рынка — избыточную бюрократию. Зарубежные бюрократические процессы плохо приживаются в российской бизнес-среде, что затрудняет полноценное внедрение этого стандарта. Зато BSIMM предоставляет возможность учитывать отраслевые особенности, что особенно полезно для компаний, работающих в специфических секторах экономики.

Внедрение стандартов, требующих значительных инвестиций в ресурсы, как например DSOMM, можно осуществлять поэтапно. Это позволяет компаниям распределить затраты и усилия во времени. Альтернативно, можно провести декомпозицию стандарта и внедрить только наиболее критичные или подходящие техники.

Внедрение рассмотренных стандартов требует учета нескольких ключевых элементов:

• первичной регламентации процесса, определяющего взаимодействие между командами;

• внедрения инструментов анализа ПП; 

• имплементации инструментов анализа ПП на компанию;

• выстраивания эффективного взаимодействия между разработчиками, специалистами по безопасности и инфраструктурой;

• обучения сотрудников практикам безопасной разработки.

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