Оссобенности безопасной разработки приложений
Информационная безопасность Информационная безопасность

Как обеспечить безопасность инфраструктуры приложения

Главная>Информационная безопасность>Безопасная разработка приложений
Информационная безопасность Обзор

Безопасная разработка приложений

Дата публикации:
27.12.2019
Посетителей:
3152
Просмотров:
3048
Время просмотра:
2.3

Авторы

Спикер
Георгий Старостин ИБ-директор "Ситимобил", экс-специалист Лаборатории практического анализа защищенности компании «Инфосистемы Джет»

Какие проблемы возникают при встраивании ИБ в разработку ПО?

 

Как обеспечить безопасность инфраструктуры приложения?

 

За что отвечает Security Champion в команде разработки?

 

 

Многие компании используют DevOps при разработке и внедрении своих приложений и продуктов, что помогает ускорить Time-to-Market. Но, как следует из названия, требования к безопасности в таком процессе остаются на вторых ролях. В методологии классического DevOps безопасность, конечно, присутствует, но ее обеспечение отделено от разработки и сводится к работе контрольного органа, который раз в полгода делает аудит кода и раз в год — пентесты. Таким образом, исправление ошибок безопасности может происходить всего несколько раз в год (за это время обычно накапливается огромное количество ошибок — на сотни листов отчета), и либо приложение выходит в релиз с уязвимостями, либо время его вывода на рынок увеличивается в разы. Как интегрировать безопасность в цикл разработки и развертывания ПО и при этом не увеличить Time-to-Market? Использовать методологию DevSecOps.

 

Безопасность при разработке — вещь комплексная, для нее первичен правильно построенный процесс. DevSecOps включает в себя как минимум:

  • построение безопасной инфраструктуры;
  • создание безопасного кода;
  • соблюдение цифровой гигиены на этапе разработки;
  • контроль за уязвимостями на этапе промышленной эксплуатации.

 

Пройдемся по этим пунктам.

Авторы

Теги

Безопасность инфраструктуры

 

Создавать безопасную инфраструктуру и подбирать для нее ИБ-средства все уже более-менее научились: активно используются межсетевые экраны уровня приложений, средства защиты баз данных, NGFW и др. При этом когда мы говорим о безопасности в непрерывной разработке, многим непонятно, как ее обеспечить, ведь инфраструктура приложения может стремительно меняться. Как показывает наша практика, реализовывать процессы обеспечения безопасности применительно к инфраструктуре нужно непрерывно, но маленькими порциями. Эти действия должны быть прозрачны и понятны для ИТ-администраторов и разработчиков. Иначе велик шанс столкнуться с сопротивлением с их стороны. Кроме того, стоит максимально автоматизировать настройку инфраструктурного оборудования, чтобы минимизировать человеческий фактор.

Безопасный код

 

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

 

Следующая часть безопасной разработки — анализ исходного кода. Существует множество средств и инструментов для подобного анализа. При выборе сканера стоит обращать внимание на то, насколько хорошо он работает с языками программирования, используемыми в ваших продуктах, особенно с редкими. Также важно, на каком этапе вы будете проверять код. С одной стороны, можно внедрить процесс сканирования кода только на стадии создания тестовой и финальной сборки. Но в этом случае сильно увеличивается время разработки. Идеальный вариант для ИБ-специалистов — сразу подсвечивать программистам небезопасный код в среде разработки. Но в этом случае у тех, кто ранее мало сталкивался с DevSecOps, могут возникнуть сложности. Разработчики могут просто не понять, что от них требуется. Поэтому нужно выстраивать безопасную разработку именно как процесс.

На заметку

По статистике, компании, внедрившие DevSecOps, устраняют уязвимости, найденные с помощью динамического анализа кода, за 92 дня. Без использования модели DevSecOps этот же процесс занимает 174 дня. В случае использования статистического анализа это занимает соответственно 53 и 113 дней.

Все ИБ-меры должны органично встраиваться в разработку и развертывание ПО. При этом появляется ряд типовых проблем.

 

Первая — непонимание программистами требований ИБ. Когда безопасник начинает указывать на ошибки в коде, то часто слышит в ответ: «А вы кто? Мне мой старший разработчик на code review поставил apply, значит, все в порядке». Избежать этого поможет Security Champion — человек, который находится в команде разработки и заинтересован в безопасности продукта. Программисты с большей вероятностью будут доверять ему, чем «приходяще-уходящему» безопаснику.

 

Чем занимается Security Champion:

  • является единой точкой входа в команду разработки по вопросам безопасности;
  • отвечает за использование ИБ-инструментов на всех этапах разработки и сопровождения приложений;
  • проводит security code review и консультирует команду по ИБ-вопросам.

Вторая проблема — возможная задержка релиза. Без проверки ПО на безопасность время от коммита до сборки и тестирования составляет часы или даже минуты. С проверкой (особенно с учетом ситуаций False Negative и False Positive, а также работ по устранению проблем) цикл будет занимать сутки и более. Поэтому при обнаружении уязвимостей решение об остановке или продолжении сборки ПО зависит от предполагаемого использования этой сборки. Например, если она должна идти на стенд к разработчикам, ее не надо останавливать. На этом этапе достаточно обратить внимание программистов на проблемы ИБ. Наличие уязвимостей также не мешает сделать сборку для функционального тестирования, многие его части можно выполнить и с присутствующими дефектами ИБ. А вот на этапе релиза нельзя пропускать бреши в безопасности — это такой же дефект, как и баги.

Еще одну сложность создает большой объем отчетов по безопасности (до нескольких сотен страниц). Они никогда не будут прочитаны целиком, и большая часть уязвимостей не будет исправлена. Бизнес в результате просто примет эти риски. Поэтому нужно сообщать разработчикам о проблемах безопасности в удобной для них форме, например, складывать в бэклог в Jira или заводить дефект-трекеры. И главное — не следует одномоментно вываливать на разработчиков информацию о сотнях дефектов ИБ в разных частях разрабатываемого ПО, обнаруженных в результате работы SAST-сканера. Сосредоточьтесь на том коде, который был написан только что, и постепенно покрывайте другие участки. Идеальный вариант — использовать автоматизацию и настроить обратную связь. Лучше всего интегрировать анализатор кода со средой разработки и проводить проверку перед коммитом. Если подобной интеграции нет, сканирование на дефекты ИБ следует выполнять на этапе pull request и по его результатам отправлять разработчику информацию о состоянии его кода.

 

Отметим, что SAST-анализатор должен поддерживать используемые в проекте:

  • языки и фреймворки;
  • инструменты интеграции (Gitlab CI, Jenkins, TeamCity и т.д.);
  • средства разработки, чтобы программист не осваивал очередной новый инструмент, а использовал уже привычную ему среду.

 

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

На заметку

В современных приложениях используются код и различные библиотеки open source. Их тоже нужно проверять, причем на разных этапах — и CI, и CD. На этапе CI средства анализа кода open source должны найти уязвимости и проверить лицензионную чистоту используемых компонентов. Теперь несколько слов о CD. Ваш продукт выпущен в релиз, и присутствующий в нем код open source замечательно работает месяц и даже год. Но за это время в коде находят уязвимости, соответственно, они появляются и в приложении. Их нужно отслеживать и оперативно устранять.

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

Чек-лист: 7 советов для безболезненного внедрения DevSecOps

 

  • Главное — правильно выстроенный процесс, а не только используемые инструменты.
  • Не надо внедрять всё и сразу. Начните с того, что у вас уже есть, и двигайтесь итерационно.
  • Поставьте знак равенства между функциональными дефектами и дефектами ИБ.
  • Автоматизируйте по максимуму.
  • Выращивайте в своей команде Security Champion и задействуйте его в процессе разработки.
  • Помните, что качество продукта — это общая цель.
  • Выбирайте инструменты, подходящие именно для вашего продукта.

Дмитрий Ключников

руководитель направлений DLP и DevSecOps Центра информационной безопасности компании «Инфосистемы Джет».

Комментарий

 

Для построения инфраструктуры под разработку приложений все большую популярность набирают контейнеры — нечто вроде виртуальных машин, использующих виртуализацию уровня ОС. Их применяют при клиентской разработке — для сайтов и мобильных приложений. Небольшой размер и гибкие возможности масштабирования обуславливают их популярность в банковском секторе и в ритейле. При этом становится все более актуальным вопрос безопасности новой технологии. Контейнерная инфраструктура, описанная через код и работающая через системы оркестрации, едва ли похожа на «классическую» инфраструктуру, для которой можно использовать стандартные системы защиты. Угрозы для работы в среде контейнеризации более чем актуальны: несанкционированное взаимодействие между различными частями инфраструктуры, кража данных, компрометация управляющей среды или хранилища (например, образов контейнеров), вредоносное ПО, повышение привилегий и т.п.

 

Проанализировав практики и рекомендации по безопасности средств контейнеризации, можно выработать стратегию защиты, создать протокол действий, который вне зависимости от конкретных инструментов ИБ позволит декларативно описать целевое состояние безопасности. Актуальные ИБ-практики можно найти в различных стандартах (например, NIST SP) или у производителей сред контейнеризации. Используя свой опыт и исходя из задач заказчиков, так поступили и мы, создав фреймворк по защите подобных сред — Jet Container Security Framework (JCSF). Вне зависимости от технического стека, применяемого заказчиком, используя фреймворк как основу, мы можем сформировать план выстраивания комплексной системы защиты и реализовать его, не ломая логику процесса разработки в микросервисной инфраструктуре.

Уведомления об обновлении тем – в вашей почте

Кадровый голод в ИБ

Как регуляторы влияют на рынок ИБ? Почему tinkoff.ru не торгуется с соискателями? что общего между Positive Technologies и Гнесинкой?

Организованная киберпреступность, кадровый голод и другие ИБ-вопросы. Опыт Росбанка

Каковы основные ИБ-тренды в банковской индустрии? В чем состоит основная сложность использования DevSecOps-подхода? Что разумно отдавать на ИБ-аутсорсинг?

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на тему







      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня