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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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