Алексей Федулаев, Wildberries: Необходимо идти на компромиссы и внедрять компенсирующие меры там, где невозможно применить популярные практики

Алексей Федулаев, DevSecOps Team Lead Wildberries, рассказал порталу Cyber Media о специфике внедрения процессов безопасной разработки, новых трендах в SSDLC, использовании open-source и взаимодействии с аутсорс-командами разработчиков с точки зрения ИБ.

Cyber Media: В процессе внедрения практик безопасной разработки, чего стоит опасаться и чему уделять особое внимание, чтобы в погоне за защищенностью не навредить бизнес-процессам компании?

Алексей Федулаев: На самом деле, часть ответа содержится в самом вопросе. Действительно, зачастую в погоне за защищенностью можно навредить уже существующим бизнес-процессам — например, понизить скорость разработки или даже полностью её заблокировать. Так, конечно же, делать не нужно. В первую очередь, внедряя практики безопасной разработки, стоит обращать внимание именно на удобство и эффективность. Безопасность нужна не ради запретов, а для создания более качественного и более надёжного продукта. Это и должно быть основной ценностью для команды.

Кроме того, необходимо идти на компромиссы и внедрять какие-то компенсирующие меры там, где невозможно применить популярные практики. Шаблонные подходы не всегда работают и нужно придумывать индивидуальные решение под каждый необычный случай. Еще важно, чтобы ИБ не становилась узким горлышком.

Cyber Media: Есть ли какие-то новые тренды или подходы в SSDLC, которые Вы считаете важными и полезными для коллег?

Алексей Федулаев: В первую очередь отмечу концептуальное направление, которое мы приняли для себя в ИБ Wildberries, — это безопасность с человеческим лицом. ИБ — не какой-то надзирательный орган, противодействующий разработчикам, наоборот, мы стараемся вместе с ними сделать более крутые и качественные продукты, которые будут стабильными и надежными. Плюс помогаем защитить продукты от прямых потерь, финансовых и репутационных. Сейчас этот подход сменяет классическую запрещающую безопасность, и мы в Wildberries стараемся донести его ценность до команды, а также сделать процессы простыми и удобными для разработчиков.

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

Также мы в Wildberries используем подход shift left security — он предполагает выявление и устранение уязвимостей на более ранних стадиях. Это и архитектурные ревью, и проверки на этапе кода, и многое другое — всё это позволяет с минимальной стоимостью исправлять ошибки до того, как они попали в прод, и не переделывать потом весь продукт. Естественно, хорошо работает и принцип Zero Trust — в первую очередь мы должны быть защищены от самих себя. Не должно быть никаких пользователей с суперполномочиями, вдруг завтра они попадут в руки злоумышленников.

Cyber Media: В контексте безопасной разработки много говорят о технических сложностях и реже – об организационных, необходимости найти баланс интересов между безопасниками и ИТ-отделом. С какими сложностями можно столкнуться на этом пути и как найти баланс между «тотальной кибербезопасностью» и «пятничным деплоем»?

Алексей Федулаев: Действительно, бывают перекосы. Раньше часто можно было встретить кейсы непринятия безопасности разработчиками, или когда этот тренд не поддерживался руководством сверху — команда ИБ воспринималась как какая-то помеха. В таких условиях внедрить безопасность может быть очень сложно. С другой стороны, бывает так, что безопасность вклинивается в процессы и может их значительно замедлить.

Нельзя сказать, что существует какое-то универсальное решение. В прошлом году я вёл дискуссию на конференции DevOops на эту тему, там как раз собрались руководители из разных компаний, включая директора по безопасности Wildberries Антона Жаболенко, и обсуждали подходы. В этой беседе была поднята интересная тема, что, например, там, где присутствует регулятор, возможно и стоит строить безопасность именно как запрещающую. Когда речь идёт про оборотные штрафы и люди ещё не понимают, как именно действовать, это может стать правильным решением — сначала по максимуму закрутить гайки, а потом уже постепенно откручивать.

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

Cyber Media: С точки зрения безопасной разработки, как правильно выстроить процесс по использованию командой компонентов open-source? В последние два года было немало кейсов, когда разного рода незадекларированные функции и закладки становились причиной инцидентов.

Алексей Федулаев: На самом деле, эта проблема не нова — такое происходило всегда. Однако несколько лет назад действительно случилось какое-то обострение. У меня было несколько докладов на эту тему, могу поделиться одним из последних.

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

Что касается анализа самих пакетов, это можно делать вручную или с помощью средств автоматизированного анализа. К тому же сейчас есть целый класс таких средств как open source analysis, которые позволяют убедиться, что пакет хороший. Например, если появилась новая версия пакета на NPM, но ей не предшествовал релиз или коммит на GitHub, значит скорее всего аккаунт на NPM был взломан. Также необходимо использовать таймфриз пакетов и отслеживать потенциальные риски, например, по резким всплескам issues на GitHub.

Дальше идут уже более продвинутые методы — запуск пакетов в песочнице, отслеживание системных вызовов, отслеживание системных пакета. Если вы скачиваете NPM-пакет для сложения двух чисел, а он что-то пишет вам на файловую систему, скорее всего это шифровальщик. Если читает данные, скорее всего с вашей системы идёт эксфильтрация данных. Сетевые коннекты, определение локали системы, тайм зоны или языка — всё это может свидетельствовать о том, что вы скачали злонамеренный пакет. Многие компании сейчас выстраивают фильтры пакетов — наборы разных утилит, которые проверяют их и статическими, и динамическими методами, анализируя в том числе и репутационные части, например, происхождение пакета. Концепция полного отказа от библиотек либо частичного отказа от библиотек, вышедших после какого-то времени, сейчас уже не работает. Появляются новые функции, пакеты обновляются, в них закрываются уязвимости. Соответственно, приходится жить в новой парадигме и строить такую защиту.

Cyber Media: В рамках работы крупные компании часто привлекают аутстаф-команды или передают на аутсорс не приоритетные проекты. Как в таких случаях выглядит работа штатного специалиста по безопасной разработке?

Алексей Федулаев: При привлечении других компаний может быть несколько вариантов, как правильно поступить. Самое первое и простое — это контроль качества. Есть ряд крупных компаний, у которых достаточно много подрядчиков — они берут на себя часть разработки. У них появляются внутренние подразделения, которые осуществляют приёмку разработанных для компании продуктов в момент их сдачи. Они формируют определённые правила приёмки и заводят собственный набор инструментов — не на стороне подрядчика, потому что подрядчик может в любой момент поменяться.

Второй вариант — когда компания-заказчик работает только с теми подрядчиками, кто развивает у себя безопасную разработку и подтверждает это соответствующей документацией и исследованиями. Какие инструменты есть, как они интегрированы, какие уязвимости выявили и устранили. Получается, что безопасная разработка в этом случае осуществляется силами подрядчика на стороне подрядчика. Штатный специалист по безопасности здесь будет нужен для того, чтобы заниматься проверкой отчетов и проводить аудиты подрядчика. Важно удостовериться, что все необходимые процессы не просто внедрены, а внедрены корректно.

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