Digital-агентства все больше внимания уделяют безопасности инфраструктуры, в которой ведется разработка, а также начинают смотреть в сторону обеспечения безопасности приложений. Вы наверняка читали про разновидность и критичность уязвимостей, инструменты и методы обеспечения ИБ. Но как игнорирование или обеспечение безопасности приложений влияет на сам процесс заказной разработки?
Что в статье:
Мы не будем в сотый раз повторять, почему так важна безопасность, какие существуют уязвимости или как Red Team побеждает Blue Team в очередной схватке. Это короткая история о том, почему мы добавили security к заказной разработке и как мы это сделали.
На кого рассчитана статья:
Статья может быть интересна руководителям проектов, техническим директорам, тимлидам и всем, кто так или иначе относится к организации процессов разработки приложений.
Дисклеймер:
Данная статья не является панацеей, а лишь сугубо личным мнением автора (Алексей Клинов, руководитель направления информационной безопасности AGIMA).
AGIMA давно занимается комплексным развитием процедур контроля качества и отдела QA. Все наши продукты подвергаются многочисленным внутренним проверкам:
Более подробно о наших процессах можно почитать в статье. Но почему мы решили добавить еще один рубеж тестирования?
Со стороны заказчика
Многие заказчики ищут уязвимости самостоятельно: используют инструментальные сканеры или проводят pen-тесты. Так или иначе, наш код и проекты в целом часто проходят разнообразные проверки со стороны заказчика.
Количество проверок возрастало, отчетов о результатах инструментального сканирования и pen-тестов становилось все больше. Изучение, воспроизведение, утверждение и исправление уязвимостей отнимало много внутренних ресурсов и могло затягиваться на недели.
Из рук в руки, когда проект разрабатывал кто-то другой
Иногда проекты переходят «по наследству» от другого подрядчика. Они могут быть и в состоянии предпрода, и «на бою». Ответственность за работу уже на нас, и вся «телега» багов и уязвимостей, как ни странно, тоже.
Мы предположили, что эффективнее и дешевле иметь в этом собственную экспертизу.
При разработке мы ориентируемся на качество приложения, скорость его ввода в эксплуатацию и стоимость. Добавление дополнительных элементов в виде анализа кода на уязвимости, еще одного рубежа тестирования или сотрудника повлияет на эти показатели. С учетом низкой маржинальности бизнеса это критично для заказной разработки. При этом для оптимизации затрат подход к security-контролю продуктов должен быть универсальным и применяться ко всем проектам. Но заказчики обычно не говорят «сделайте нам такое же приложение как вон у тех ребят, только зеленое». Клиенты хотят не только свой дизайн, но и функционал. Плюс ко всему у каждой сферы бизнеса свои потребности: требования к приложению в финансовой сфере, медицине и ритейле разные. Команда и технологии на каждом проекте могут сильно отличаться.
Очевидно, что контроль безопасности продукта повышает его качество. Но как security-анализ повлияет на стоимость и сроки проектов?
Добавляя дополнительную ревизию кода в смету, мы изначально делаем проект дороже и увеличиваем сроки разработки, все так же как и с другими видами тестирования. Но этот бюджет все равно пришлось бы потратить, просто менее системно и более болезненно. По факту, продукт на выходе получается более «чистым», что уменьшает уровень технического долга, избавляет нас от необходимости тратить много времени и ресурсов на доработки после pen-тестов, и соответственно, сокращается срок вывода продукта в production.
Забегая вперед, в нашем случае внедрение security-анализа оказалось дешевле и быстрее с учетом всего цикла проекта. Издержки в некоторых проектах сократились до 20% в том числе за счет снижения времени на локализацию уязвимостей и устранения их еще до этапа code-review тимлидом.
Было принято решение найти оптимальный путь внедрения информационной безопасности в наши процессы разработки.
Наш взгляд на повышение безопасности приложений:
WAF и защита от DDoS — это дополнительные слои защиты на проде. А для наших целей потребуется анализатор кода на уязвимости и pen-тест.
Немного куба
Выбирая анализатор для старта, мы исключили платные дорогостоящие продукты. Остановились на SonarQube — анализатор, у которого есть условно бесплатная версия. Есть и облачная версия, но бесплатный вариант делает проекты полностью открытыми, что в нашем случае недопустимо.
Поэтому для старта — SonarQube Community Edition. Он поддерживает 15 языков, среди которых Java, JavaScript, C#, PHP и Python. Решение развертывается довольно быстро и особых проблем не вызывает, этому способствует подробный гайд.
Удобная система разграничения прав: можно построить матрицу доступа к каждому проекту.
SonarQube позволяет наблюдать динамику проекта и хранит историю анализа. Мы сами можем устанавливать порог качества для каждого проекта, что позволяет оптимизировать анализ под разные проекты.
Мы протестировали продукт на нескольких проектах:
Решили, что для наших начинаний этого достаточно.
Для себя мы выделили три подхода, которые варьируем в зависимости от проектов и потребностей заказчика:
Полная интеграция в процесс разработки
Мы интегрировали решение в GitLab. Использовали GitLab CI/CD для автоматизации запуска проверок. Для этого потребовался бесплатный плагин Sonar GitLab Plugin. Система оповещает разработчиков о коммитах, не прошедших проверку, и добавляет комментарии с описанием проблемного участка (тип уязвимости, рекомендации по ее исправлению и другие).
В одном из проектов реализовали интеграцию с Bitbucket и Bamboo. В данном случае потребовались платные плагины Sonar for Bamboo и Sonar for Bitbucket Server. После тестовой эксплуатации заказчик был готов на дополнительные затраты, решение отлично вписалось в технологический стек.
Идеальный вариант — когда сроки, бюджет и клиент позволяют интегрировать наши процессы по безопасности в каждодневный цикл работы с кодом. На практике оказалось, что такой подход актуален для длительной разработки и поддержки проектов с частыми релизами.
Ревизия безопасности на контрольных точках
Для нас такой подход оказался оптимален для проектов, где релизы происходят редко, например, раз в квартал. В процессе работы может меняться функциональность или требования к продукту. Если постоянно отсматривать каждую строчку кода на предмет безопасности, тратится много лишнего времени на те куски продукта, от которых впоследствии мы с заказчиком можем отказаться.
Что мы относим к контрольным точкам:
На ключевых проектах мы стали комбинировать интегрированный анализ с ревизией безопасности на контрольных точках. Таким образом мы выявляем уязвимости, которые могли остаться незамеченными в процессе разработки.
Используя такой подход, мы сокращаем количество итераций отладки при вводе продукта в промышленную эксплуатацию. Мы готовим общий пул исправлений и доработок, который включает функциональные ошибки, уязвимости ИБ и требования к инфраструктуре.
Мы собрали статистику по временным затратам с интегрированной процедурой валидации ИБ на контрольных точках и без нее. Замеряли только деятельности отладки и релиза в продуктивную среду.
При комплексном подходе в среднем требуется две итерации отладки. Их суммарная длительность составляет ~15-20% от общего времени разработки.
При подключении третьих лиц на валидацию ИБ получалось в среднем две итерации функциональной отладки и три итерации отладки уязвимостей ИБ / требований к инфраструктуре. Суммарно это составило ~45% от общего времени разработки, без учета времени проведения процедур третьими лицами, только на нашей стороне.
Ситуационная или разовая ревизия безопасности
Для простых проектов решили применять подход с однократной проверкой всей кодовой базы перед финальным релизом. Лендинг достаточно проверить один раз перед выпуском. Внедрять сканирование кода в процесс или делать промежуточные проверки на таких проектах дорого и бессмысленно.
Также ситуационную ревизию стали проводить на проектах, которые к нам перешли от других разработчиков. Прежде чем приступить к дальнейшей разработке, минимизируем имеющийся технический долг продукта. После этого определяем, какой подход к контролю безопасности будем применять при дальнейшем развитии проекта.
Это результат сканирования проекта, который несколько лет не проходил полноценную ревизию на баги и безопасность:
Более 700 артефактов из категории уязвимостей! Конечно, если отфильтровать все ложные срабатывания и незначительные артефакты, оставив только блокеры и критические, картина будет не такая ужасная. Но это тот багаж технического долга, который в любом случае требуется обработать!
Мы ранжируем уязвимости и составляем роадмап, где отмечаем, за сколько итераций критические уязвимости нужно устранить. Это зависит от участка кода, который они затрагивают, какие данные можно получить, используя эти уязвимости. Насколько велика вероятность того, что злоумышленник воспользуется конкретной уязвимостью.
На этот кейс мы затратили более 200 человеко-часов на «просев» и устранение найденных уязвимостей и только после этого приступили к полноценному развитию продукта. Иногда приходится решать и такие кейсы, поскольку быть в неведении гораздо дороже.
И что дальше?
Усилия по внедрению информационной безопасности в процессы заказной разработки принесли нам пользу:
Чем больше мы двигаемся по направлению к усилению информационной безопасности, тем больше видим точек для роста: добавить в наши процедуры проверку не только на TOP-10 OWASP и CWE/SANS, но например, прикрутить отслеживание бюллетеней безопасности или научить нашу CI применять security guide для наших фреймворков.
Мы уже провели свое первое мероприятие по ИБ (Бизнес-ужин Ростелеком-Solar — AGIMA), написали эту статью и планируем и дальше привносить новые практики на наш рынок, как делали это в свое время с адаптивным дизайном (см. Adaptoz или наш словарь адаптивного дизайна, выпущенный в 2013 году) — именно с нас тогда начался этот тренд, и стал сейчас по сути стандартом де-факто. То же самое мы хотим сделать и с информационной безопасностью, ведь «обучая других, обучаешься сам».
Что в статье:
Мы не будем в сотый раз повторять, почему так важна безопасность, какие существуют уязвимости или как Red Team побеждает Blue Team в очередной схватке. Это короткая история о том, почему мы добавили security к заказной разработке и как мы это сделали.
На кого рассчитана статья:
Статья может быть интересна руководителям проектов, техническим директорам, тимлидам и всем, кто так или иначе относится к организации процессов разработки приложений.
Дисклеймер:
Данная статья не является панацеей, а лишь сугубо личным мнением автора (Алексей Клинов, руководитель направления информационной безопасности AGIMA).
С чего все началось
AGIMA давно занимается комплексным развитием процедур контроля качества и отдела QA. Все наши продукты подвергаются многочисленным внутренним проверкам:
- используем чек-листы после каждого этапа/спринта разработки продукта;
- покрываем критический для бизнеса функционал сеткой автотестов;
- стараемся максимально покрывать код unit-тестами;
- используем анализаторы кода, соответствующие стандартам (например, для PHP это PSR 0-4 и т. д.);
- в обязательном порядке проводим нагрузочные испытания.
Более подробно о наших процессах можно почитать в статье. Но почему мы решили добавить еще один рубеж тестирования?
Со стороны заказчика
Многие заказчики ищут уязвимости самостоятельно: используют инструментальные сканеры или проводят pen-тесты. Так или иначе, наш код и проекты в целом часто проходят разнообразные проверки со стороны заказчика.
Количество проверок возрастало, отчетов о результатах инструментального сканирования и pen-тестов становилось все больше. Изучение, воспроизведение, утверждение и исправление уязвимостей отнимало много внутренних ресурсов и могло затягиваться на недели.
Из рук в руки, когда проект разрабатывал кто-то другой
Иногда проекты переходят «по наследству» от другого подрядчика. Они могут быть и в состоянии предпрода, и «на бою». Ответственность за работу уже на нас, и вся «телега» багов и уязвимостей, как ни странно, тоже.
Мы предположили, что эффективнее и дешевле иметь в этом собственную экспертизу.
Что мешало?
При разработке мы ориентируемся на качество приложения, скорость его ввода в эксплуатацию и стоимость. Добавление дополнительных элементов в виде анализа кода на уязвимости, еще одного рубежа тестирования или сотрудника повлияет на эти показатели. С учетом низкой маржинальности бизнеса это критично для заказной разработки. При этом для оптимизации затрат подход к security-контролю продуктов должен быть универсальным и применяться ко всем проектам. Но заказчики обычно не говорят «сделайте нам такое же приложение как вон у тех ребят, только зеленое». Клиенты хотят не только свой дизайн, но и функционал. Плюс ко всему у каждой сферы бизнеса свои потребности: требования к приложению в финансовой сфере, медицине и ритейле разные. Команда и технологии на каждом проекте могут сильно отличаться.
Очевидно, что контроль безопасности продукта повышает его качество. Но как security-анализ повлияет на стоимость и сроки проектов?
Добавляя дополнительную ревизию кода в смету, мы изначально делаем проект дороже и увеличиваем сроки разработки, все так же как и с другими видами тестирования. Но этот бюджет все равно пришлось бы потратить, просто менее системно и более болезненно. По факту, продукт на выходе получается более «чистым», что уменьшает уровень технического долга, избавляет нас от необходимости тратить много времени и ресурсов на доработки после pen-тестов, и соответственно, сокращается срок вывода продукта в production.
Забегая вперед, в нашем случае внедрение security-анализа оказалось дешевле и быстрее с учетом всего цикла проекта. Издержки в некоторых проектах сократились до 20% в том числе за счет снижения времени на локализацию уязвимостей и устранения их еще до этапа code-review тимлидом.
Было принято решение найти оптимальный путь внедрения информационной безопасности в наши процессы разработки.
Первые шаги
Наш взгляд на повышение безопасности приложений:
WAF и защита от DDoS — это дополнительные слои защиты на проде. А для наших целей потребуется анализатор кода на уязвимости и pen-тест.
Немного куба
Выбирая анализатор для старта, мы исключили платные дорогостоящие продукты. Остановились на SonarQube — анализатор, у которого есть условно бесплатная версия. Есть и облачная версия, но бесплатный вариант делает проекты полностью открытыми, что в нашем случае недопустимо.
Поэтому для старта — SonarQube Community Edition. Он поддерживает 15 языков, среди которых Java, JavaScript, C#, PHP и Python. Решение развертывается довольно быстро и особых проблем не вызывает, этому способствует подробный гайд.
Удобная система разграничения прав: можно построить матрицу доступа к каждому проекту.
SonarQube позволяет наблюдать динамику проекта и хранит историю анализа. Мы сами можем устанавливать порог качества для каждого проекта, что позволяет оптимизировать анализ под разные проекты.
Мы протестировали продукт на нескольких проектах:
- Удалось отловить несколько неочевидных уязвимостей в текущих проектах.
- Время на имплементацию было минимальным.
- Мы убедились, что в рамках CI код возвращается на доработку с указанием потенциальных уязвимостей.
Решили, что для наших начинаний этого достаточно.
Что дальше?
Для себя мы выделили три подхода, которые варьируем в зависимости от проектов и потребностей заказчика:
- Полная интеграция в процесс разработки (CI/CD).
- Ревизия безопасности на контрольных точках.
- Ситуационная или разовая ревизия безопасности.
Полная интеграция в процесс разработки
Мы интегрировали решение в GitLab. Использовали GitLab CI/CD для автоматизации запуска проверок. Для этого потребовался бесплатный плагин Sonar GitLab Plugin. Система оповещает разработчиков о коммитах, не прошедших проверку, и добавляет комментарии с описанием проблемного участка (тип уязвимости, рекомендации по ее исправлению и другие).
В одном из проектов реализовали интеграцию с Bitbucket и Bamboo. В данном случае потребовались платные плагины Sonar for Bamboo и Sonar for Bitbucket Server. После тестовой эксплуатации заказчик был готов на дополнительные затраты, решение отлично вписалось в технологический стек.
Идеальный вариант — когда сроки, бюджет и клиент позволяют интегрировать наши процессы по безопасности в каждодневный цикл работы с кодом. На практике оказалось, что такой подход актуален для длительной разработки и поддержки проектов с частыми релизами.
Ревизия безопасности на контрольных точках
Для нас такой подход оказался оптимален для проектов, где релизы происходят редко, например, раз в квартал. В процессе работы может меняться функциональность или требования к продукту. Если постоянно отсматривать каждую строчку кода на предмет безопасности, тратится много лишнего времени на те куски продукта, от которых впоследствии мы с заказчиком можем отказаться.
Что мы относим к контрольным точкам:
- Логические веха при разработке MVP.
- Выпуск определенной версии продукта, содержащей критический функционал взаимодействия с пользователем.
- Определенный релиз, спринт или набор спринтов, в котором также есть критический функционал для взаимодействия с пользователем.
На ключевых проектах мы стали комбинировать интегрированный анализ с ревизией безопасности на контрольных точках. Таким образом мы выявляем уязвимости, которые могли остаться незамеченными в процессе разработки.
Используя такой подход, мы сокращаем количество итераций отладки при вводе продукта в промышленную эксплуатацию. Мы готовим общий пул исправлений и доработок, который включает функциональные ошибки, уязвимости ИБ и требования к инфраструктуре.
Мы собрали статистику по временным затратам с интегрированной процедурой валидации ИБ на контрольных точках и без нее. Замеряли только деятельности отладки и релиза в продуктивную среду.
При комплексном подходе в среднем требуется две итерации отладки. Их суммарная длительность составляет ~15-20% от общего времени разработки.
При подключении третьих лиц на валидацию ИБ получалось в среднем две итерации функциональной отладки и три итерации отладки уязвимостей ИБ / требований к инфраструктуре. Суммарно это составило ~45% от общего времени разработки, без учета времени проведения процедур третьими лицами, только на нашей стороне.
Ситуационная или разовая ревизия безопасности
Для простых проектов решили применять подход с однократной проверкой всей кодовой базы перед финальным релизом. Лендинг достаточно проверить один раз перед выпуском. Внедрять сканирование кода в процесс или делать промежуточные проверки на таких проектах дорого и бессмысленно.
Также ситуационную ревизию стали проводить на проектах, которые к нам перешли от других разработчиков. Прежде чем приступить к дальнейшей разработке, минимизируем имеющийся технический долг продукта. После этого определяем, какой подход к контролю безопасности будем применять при дальнейшем развитии проекта.
Это результат сканирования проекта, который несколько лет не проходил полноценную ревизию на баги и безопасность:
Более 700 артефактов из категории уязвимостей! Конечно, если отфильтровать все ложные срабатывания и незначительные артефакты, оставив только блокеры и критические, картина будет не такая ужасная. Но это тот багаж технического долга, который в любом случае требуется обработать!
Мы ранжируем уязвимости и составляем роадмап, где отмечаем, за сколько итераций критические уязвимости нужно устранить. Это зависит от участка кода, который они затрагивают, какие данные можно получить, используя эти уязвимости. Насколько велика вероятность того, что злоумышленник воспользуется конкретной уязвимостью.
На этот кейс мы затратили более 200 человеко-часов на «просев» и устранение найденных уязвимостей и только после этого приступили к полноценному развитию продукта. Иногда приходится решать и такие кейсы, поскольку быть в неведении гораздо дороже.
Мы не остановились на достигнутом:
- Добавили анализ на большинство проектов.
- Инструменты security-контроля дополнил appScreener от Ростелеком-Solar.
- Добавили ручной аудит и pen-тест для ключевых проектов.
- Внедрили группы критериев и уровни критичности для реализуемого функционала в разрезе влияния на безопасность приложения.
И что дальше?
Усилия по внедрению информационной безопасности в процессы заказной разработки принесли нам пользу:
- Мы снижаем репутационные риски как для себя, так и для наших заказчиков, минимизируя возможность взлома наших приложений.
- У нас практически исчезли длительные этапы отладки приложений после тестов на проникновение сторонними организациями.
- Мы повысили компетенции сотрудников в области ИБ и планируем и дальше качаться в этом направлении: выращивать новых security-лидеров, обогащать свою базу знаний, дорабатывать свои подходы и пробовать новые.
- Мы получили отличное конкурентное преимущество перед другими компаниями, оказывающими услуги заказной разработки и не имеющих внутри компетенций по информационной безопасности.
Чем больше мы двигаемся по направлению к усилению информационной безопасности, тем больше видим точек для роста: добавить в наши процедуры проверку не только на TOP-10 OWASP и CWE/SANS, но например, прикрутить отслеживание бюллетеней безопасности или научить нашу CI применять security guide для наших фреймворков.
Мы уже провели свое первое мероприятие по ИБ (Бизнес-ужин Ростелеком-Solar — AGIMA), написали эту статью и планируем и дальше привносить новые практики на наш рынок, как делали это в свое время с адаптивным дизайном (см. Adaptoz или наш словарь адаптивного дизайна, выпущенный в 2013 году) — именно с нас тогда начался этот тренд, и стал сейчас по сути стандартом де-факто. То же самое мы хотим сделать и с информационной безопасностью, ведь «обучая других, обучаешься сам».