Практики безопасной разработки и DevSecOps
Краткие теоретические сведения
Безопасность приложений (Application Security) - раздел кибербезопасности, в котором объектом защиты является программное обеспечение и его потенциальные уязвимости.
Причем основное внимание уделяется предотвращению появления уязвимостей, а не их обнаружению в уже готовом продукте. Application Security затрагивает практически каждый артефакт и шаг производства программного обеспечения.
Что защищаем:
данные;
алгоритмы;
файлы;
деньги;
иные активы.
Через эксплуатацию уязвимости можно:
парализовать или осложнить деятельность компании;
модифицировать или украсть информацию, использовать ее для шантажа или нанесения репутационного ущерба;
похитить денежные средства.
Граница между такими понятиями, как фича и баг, достаточно размыта и зависит от того, под каким углом зрения мы на них смотрим. Баг при правильном использовании может стать фичей. И наоборот, даже задокументированная особенность приложения может быть проэксплуатирована злоумышленниками как уязвимость. Самые популярные уязвимости описаны в методологии OWASP TOP 10.
Чем отличаются Application Security, SSDLC и DevSecOps? Application Security включает меры по повышению защищенности приложения путем обнаружения, исправления и предотвращения уязвимостей, которые появляются в результате ошибок на этапе проектирования или написания программного кода.
SSDLC (Secure Software Development LifeCycle) — жизненный цикл безопасной разработки программного обеспечения, который включает жизненный цикл разработки SDLC (Software Development LifeCycle).
Пионером в создании подходов SDLC и SSDLC выступила компания Microsoft.
Процесс SSDLC строится по классической каскадной модели: Этап 1. Формирование потребности: формирование основных требований по ИБ.
Этап 2. Проектирование:
формирование перечня рисков;
разработка модели угроз;
формирование требований с учетом рисков и модели угроз;
включение требований в техническое задание;
отражение требований в рамках технического проекта.
Этап 3. Разработка и тестирование:
анализ уязвимостей архитектуры;
статический и динамический анализ приложения;
fuzzing.
Этап 4. Ввод в эксплуатацию:
анализ уязвимостей ПО;
тестирование на проникновение.
Этап 5. Сопровождение:
тестирование ПО на наличие уязвимостей;
мониторинг уязвимостей в используемых библиотеках;
устранение уязвимостей.
Этап 6. Вывод из эксплуатации/внесение изменений: контроль вывода из эксплуатации/начало цикла.
Таким образом, на каждом из этапов разработки SSDLC предполагает ряд мер, которые относятся к обеспечению безопасности. SSDLC является частью Application Security.
DevSecOps — это безопасный конвейер, который является частью SSDLC для конвейера DevOps, в который добавлены технологии информационной безопасности. Причем они присутствуют на всех этапах — от проектирования до выпуска продукта.
Практики и инструменты Application Security
Шаг 1. Проектируем безопасно. Прежде чем перейти к разработке, решение надо спроектировать. В проектировании один из важнейших компонентов - архитектура. Хорошая архитектура позволяет не только обеспечить функциональность и безопасность продукта, но и дает возможность его развивать и масштабировать, сохранять и совершенствовать его безопасность.
Рекомендуем стандарт ASVS 4.0 от OWASP в качестве источника, в котором описаны многие лучшие практики, применявшиеся при создании безопасной архитектуры. Для того чтобы гарантировать соответствие разрабатываемого продукта требованиям безопасности, необходимо учитывать ГОСТы и ISO стандарты.
Шаг 2. Пишем код безопасно. Следующий этап в создании продукта — разработка. С точки зрения Application Security задача ставится как написание безопасного кода.
Здесь есть несколько ключевых моментов:
самые опасные места в программе возникают там, где одна функциональность взаимодействует с другой (приложение — СУБД, приложение - ОС, интеграционные взаимодействия);
рекомендуется использовать безопасные конструкции, предоставляемые фреймворками, языками, конструкторами шаблонов;
важно применять лучшие практики программирования, следить за чистотой кода, потому что безопасный код — это прежде всего качественный код;
для проверки потенциально опасных фрагментов кода советуем использовать плагины, которые встраиваются в среду разработки и позволяют тестировать код еще на этапе программирования.
Шаг 3. Тестируем приложение. После разработки тестируем следующие объекты:
исходный код;
дистрибутивы;
конфигурационные файлы;
запущенные приложения в динамике. Практики тестирования бывают ручные и автоматизированные.
Среди ручных практик выделим Code Review и Penetration Testing. Code Review - это просмотр кода с точки зрения его критичных участков, не очень хорошего стиля программирования и использования тех или иных методов. При наличии компетенции данная практика весьма эффективна.
Penetration Testing - значительно более сложная и дорогостоящая практика. Данное тестирование проводится периодически в качестве аудита на безопасность. Она хорошо дополняет другие практики и позволяет находить такие дефекты, которые не находятся автоматизированными средствами.
Автоматизированные практики тестирования приложений включают:
1. Статический анализ кода (SAST: Static Application Security Testing). Это самая популярная и простая в имплементации практика. Она позволяет находить не очень хорошие языковые конструкции, захардкоженные пароли, осуществлять автоматизацию Code Review.
У SAST есть ряд недостатков:
высокий уровень ложных срабатываний;
патчи к статистическим анализаторам отстают от новых версий фреймворков примерно на полгода-год.
2. Анализ OpenSource компонент (OSS/SCA). Использование готовых компонент, которые можно скачать из Интернета. Это очень упрощает и убыстряет разработку, но в то же время несет достаточно высокие риски. Потому что есть общедоступные базы с эксплойтами именно для этих компонент.
Небезопасные OpenSource библиотеки встречаются не только в собственном коде, но и в системном ПО. Поэтому важно периодически обновлять системный софт.
3. Bytecode анализ (BCA: Bytecode and Container Analysis) — более редкая практика, при которой анализируется уже собранный дистрибутив. Позволяет выявлять секреты и конфиденциальные данные даже с учетом обфускации кода. Используется преимущественно для мобильных приложений.
4. Динамический анализ приложения (DAST: Dynamic Application Security Testing). Суть этой практики в том, что, запуская приложение, мы реализуем различные стандартные проверки на типовые уязвимости. Это очень тяжеловесная и дорогостоящая практика, требующая наличия тестового стенда, но в итоге точность тестирования получается высокой.
5. Тестирование бизнес-функционала (BAST: Behavioral Application Security Testing). Такое тестирование, как правило, проводят на приемке продукта эксперты кибербезопасности. Поэтому данная практика позволяет проверить требования кибербезопасности к функционалу ПО и составить список замечаний в бизнес-терминах.
6. Интерактивный анализ приложений (IAST: Interactive Application Security Testing). Встраиваемое решение, которое может идентифицировать место исправления в коде.
Основным недостатком является сложность реализации, поскольку непросто найти подходящий инструмент для такого тестирования.
Шаг 4. Выпускаем приложение. Итак, тестирование завершено. В результате найдено некоторое количество уязвимостей. Какие-то изъяны в коде удается исправить, но ряд уязвимостей останется. На этом шаге важно оценить риски, которые будут учитывать возможные последствия от эксплуатации уязвимости, а также предложить подходящие меры митигации.
Например:
установить патч/обновить ПО или библиотеку;
убедиться, что уязвимый функционал OpenSource библиотек не используется;
применить внешние средства защиты;
обеспечить online-реагирование на попытку эксплуатации и моментальное отключение узла сети или приложения;
убедиться, что уязвимость не эксплуатируется в вашем окружении.
Шаг 5. После выпуска приложения применяется практика Application Security — Bug Bounty. Она предусматривает выплату награды этичным хакерам за обнаружение проблем в безопасности сервисов и приложений компании. Это дает производителям программного обеспечения способ найти уязвимости, которые не удалось выявить в процессе разработки.
Практические рекомендации для применения Application Security в бизнесе
При выборе практик Application Security и подходов к их применению следует учитывать многие факторы:
размер компании;
направление бизнеса;
зрелость процессов разработки и кибербезопасности в компании;
тип разрабатываемых приложений, используемый технологический стек;
вид обрабатываемой информации и функционал приложений;
количество разрабатываемого ПО.
Реализация практик Application Security в компаниях в зависимости от их размера выглядит следующим образом.
StartUp. На этапе стартапа достаточно учитывать принципы безопасного проектирования и разработки.
Middle. Для средних компаний (с точки зрения бизнеса, количества клиентов или ПО, которое они разрабатывают) можно использовать Code Review и простейшие статические анализаторы. Они не требуют больших трудозатрат и времени на сопровождение.
High. Для крупных компаний (с точки зрения зрелости процессов) необходимо добавить более сложные практики тестирования.
Например, пентест, динамический анализ, Bytecode анализ. Для самых зрелых компаний можно добавить практику Bug Bounty. Как решать проблему ложных срабатываний? Прежде всего надо понять — это действительно ложное срабатывание или просто неэксплуатируемые уязвимости, которые подсвечивает инструмент. Полезно также анализировать статистику по истинно положительным срабатываниям. Если есть комплексные проблемы, то истинные срабатывания позволят обнаружить систематические ошибки. Подходы к процессам Application Security:
1. Децентрализованный. Есть несколько команд, каждая из которых разрабатывает приложение или часть приложения. Команды заботятся о реализации мер безопасности, не согласовывая это друг с другом.
Например, команда 1 использует Code Review и SAST, команда 2 - только Code Review, команда 3 - SAST и OSS. Это не очень зрелый подход с точки зрения безопасности.
2. Централизованный. Характерен для ситуации, когда команды вообще не заботятся о безопасности. Продукт разработки сканирует на безопасность внешний подрядчик или внутренние эксперты по безопасности и присылают список обнаруженных дефектов обратно в команды (возможно, сами что-то исправляют). Один из недостатков такого подхода в том, что он не несет ценности в развитии культуры кибербезопасности.
3. Оптимальный. В этом подходе реализованы лучшие элементы двух предыдущих. А именно: команды разработки заботятся о безопасности продукта. И есть еще центр компетенций за пределами команд, который рассказывает, обучает, помогает внедрять наиболее эффективные практики безопасности. Это самый правильный подход с точки зрения развития киберкультуры.
Пример реализации SSDLC в экосистеме Сбера
В DevOps конвейере запущено несколько инструментов безопасности: статика, Open Source, динамический анализ. Для централизованной работы инструментов безопасности создается собственная платформа Application Security. Она позволит не только тестировать разные решения, но и смотреть корреляцию между результатами, статистику, формировать аналитику и создавать собственный продукт. В DevOps конвейере реализованы механизмы контроля Quality Gate.
Также используется стоп-лист для приложений, в которых необходимо устранить уязвимости как можно скорее. Для того чтобы отслеживать эти процессы, мы пользуемся дашбордами, которые сами проектируем и разрабатываем.
Немного статистики. Каждый день в конвейере экосистемы Сбера запускается более 7000 сканов. Над этим работает больше 1,5 тысячи команд. Для сопровождения решений есть несколько линий поддержки. Кроме того, в самом конвейере присутствуют линии первой поддержки, которые помогают с вопросами по эксплуатации, инструментам разработки и статического анализа.
Культура Application Security
Культура определяется мышлением, отношением людей к тому, что мы делаем, определяется идеей. Application Security разделяет принцип «сдвига влево» в производстве. Это означает, что чем раньше удается выявить потенциальные проблемы и уязвимые места, тем дешевле их исправить.
Поэтому компетенции ИБ и понимание угроз безопасности должны присутствовать у всех участников процесса производства приложения, но в разном объеме и разных ракурсах.
Для формирования культуры ИБ используется Security Awareness, то есть практика развития осведомленности в вопросах безопасности.
С этой целью Сбербанк делает следующее:
пишутся статьи;
проводятся лекции, практические семинары;
создаются обучающие курсы;
делятся опытом;
используются средства информирования — каналы, рассылки, новостные ленты;
развиваются ИТ-сообщества в университетах и компаниях;
организовываются CTF-соревнования;
проводятся лабораторные исследования.
Эти средства служат достижению следующих целей:
повышение осведомленности о возможных последствиях кибератак;
обсуждение примеров эксплуатации уязвимостей;
формирование другого видения безопасности как неотъемлемого атрибута качественного продукта, его конкурентного преимущества.
В командах разработки ключевую роль в этом контексте играют Security Champions - сотрудники, которые являются точкой входа в команду разработки и евангелистами безопасности.
Их роль - способствовать формированию в команде культуры применения лучших практик Application Security. Поэтому знания Security Champions не могут быть чисто теоретическими.
Эти специалисты умеют:
практически применять знания Application Security в разработке приложений, работать над созданием приложения в любой роли;
определять риски ИБ и меры их митигации;
формировать культуру ИБ и внедрение лучших практик Application Security в команде.
