Сегодня поговорим о том, что многие делают, но мало кто делает правильно — о безопасной разработке и DevSecOps. Для этого мы пригласили Романа Гаголушко, руководителя отдела консалтинга безопасной разработки в Бастионе. Передаем ему слово.
Небольшой дисклеймер.
За годы работы в сфере безопасности разработки я насмотрелся:
на вопиющие случаи игнорирования базовых принципов безопасности (и не только при разработке);
на неэффективные попытки внедрения Dev «Sec» Ops;
на откровенную и безрезультатную имитацию бурной деятельности;
на такую же безрезультатную трату бюджета при закупке неподходящих инструментов анализа кода;
на безразличие;
на нежелание видеть очевидные вещи;
на непонимание ИБ и БР со стороны разработки.
В этой статье я расскажу о типичных ошибках компаний, которые совершают все (от маленьких и не очень стартапов до больших и не очень корпораций), поделюсь практическими советами по организации процессов безопасной разработки. Напоследок расскажу, как обстоят дела с регулированием, и немного поговорю о трендах.
(Не)Безопасная разработка начинается с людей — прежде всего с руководства и его технического видения продукта. Так давайте попробуем ответить себе на несколько вопросов.
Знает ли руководитель вашей компании, насколько безопасен разрабатываемый продукт?
А его окружение?
Понимает ли он в целом, как организованы процессы безопасной разработки (да и просто разработки) в компании?
Нет? Да? возможно?
На самом деле это очень занимательные вопросы. Конечно, можно пригласить аудиторов и все проверить, и получить в результате большой красивый отчет с графиками и выявленными недостатками.
А после аудита руководитель знает, как обстоят дела по вышеуказанным вопросам?
«Да», — скажете вы! «Возможно», — скажу я…
Первое: по опыту любой аудит можно обойти (обмануть или ввести в заблуждение), показав красивый фантик вместо реального положения дел. Второе: если результаты аудита сначала попадают на проверку (согласование) тем, кто этот аудит проходил, а не на стол руководителю, данному аудиту доверять стоит лишь отчасти. Результаты могли скорректировать «согласователи». Третье: не все методологии, в рамках которых оцениваются процессы безопасной разработки в РФ, подходят для РФ.
А теперь вы точно уверены, что руководитель в курсе положения дел?
Я не хочу сказать, что аудиты и внутренние, и внешние, не дают результата, даже наоборот, иногда они превосходят все ожидания. Аудиты необходимы. Вопрос в другом, хочет ли руководитель знать реальное положение дел в рамках процессов безопасной разработки?
Все начинается с руководителя.
К сожалению, большинство компаний по всему миру не задумываются о безопасности разработки. Даже в финтехе о ней думают недостаточно.
Минутка сторителлинга: расскажу умопомрачительный случай из практики про стартап, делающий платежный шлюз. Сервис подключен к одному из банков, который пропускал «серые» платежи, включая беттинг. Руководство компании получало деньги от инвесторов и обналичивало их. А для разработки наняли двух студентов на фулстек, чтобы те собрали фронт и бэк «на коленке». Для получения платежных данных они предоставляли аудиторам поддельный сертификат PCI DSS. Трафик в сервис поступал через CPA-сеть, из-за чего данные карт оседали в системе.
Иногда о настоящей безопасности говорить бессмысленно, она просто не нужна по умолчанию, но даже в добросовестных компаниях встречается множество проблем. Доказательством тому служит огромное количество торчащих наружу сервисов, с которыми коллеги сталкиваются при проведении пентестов. Очень часто — это следствие неэффективных подходов к организации безопасной разработки и нежелания руководства эти самые подходы улучшать.
Ошибки, в процессе безопасной разработки, которые допускают все
Приведу типичные примеры того, как не стоит делать, и дам рекомендации по правильной организации процессов:
1. Начинать внедрение продвинутого DevSecOps, не наладив базовые процессы безопасной разработки.
Многие менеджеры считают необходимым как можно быстрее внедрить модные инструменты вроде Quality Gates. Результат предсказуем: подключенный к проекту статический анализатор сразу обнаружит множество дефектов и заблокирует сборку. При умелом подходе можно в один момент парализовать всю разработку, подключив Quality Gates ко всем проектам. Не надо так…
Выход: систему контроля качества, как и все жесткие, блокирующие практики стоит внедрять только после того, как вы повысите качество кода другими методами.
Внедрите регулярное проведение проверок SAST с последующей выгрузкой дефектов безопасности в единую систему учета дефектов. Проводите триаж и снижайте количество ложноположительных срабатываний. Раскатите практику проведения экспертизы исходного кода на наличие дефектов безопасности. Внедрите проверку коммитов на наличие секретов, линтеры, прочие инструменты, позволяющие повысить качество кода.
После того как ваши отчеты о проведении SAST станут умещаться на 10 строках, вводите Quality Gates.
2. Нанять не того человека.
Это может быть специалист, который хоть и связан с безопасностью, но никогда не видел разработку изнутри. Скажем, матерый безопасник-теоретик, гуру совещаний и мастер ГОСТов, который освоил теорию, посещал конференции, изучил множество статей, но не понимает, как на практике устроены процессы разработки.
Внедрение или развитие процессов безопасной разработки таким человеком в лучшем случае будет неэффективным. В худшем — вы растеряете часть разработки, которая не сможет выжить в новых реалиях непонятного процесса, и потратите большой бюджет на неэффективные и неподходящие сканеры.
Выход: лучше всего искать на эту должность специалиста, который хочет вырасти (или вырос) в сторону DevSecOps из самой разработки или, например, DevOps. Того, кто понимает процесс разработки, сборки и тестирования ПО изнутри. Понимает боли самого процесса и боли разработчиков.
3. Внедрять различные технические меры индивидуально под каждую команду разработки.
Там, где большие объемы кода, а репозиториев больше двадцати, непродуктивно настраивать проверки для каждого репозитория отдельно. Получится большое количество отчетов и маленькое количество специалистов по безопасной разработке, которые просто не смогут качественно их обработать.
Выход: создавать централизованную систему сканирования всех репозиториев и коммитов, а также агрегировать результаты сканирования в одном месте.
4. Считать, что информационной безопасностью нужно заниматься либо «по полной», инвестируя максимум средств, либо не заниматься вообще.
Выход: настройте процесс минимально, с использованием Open Source инструментов, проводите SAST и SCA c устранением критических уязвимостей.
Да, для эффективной работы ИБ нужны ресурсы, но в вопросе безопасности разработки лучше сделать хотя бы что-то, чем совсем ничего. Ведь согласно закону Парето, 20% усилий обеспечивают 80% результата, а оставшиеся 80% усилий дают оставшиеся 20% результата. Нужно определить именно те 20% усилий, что в вашем случае приведут к 80% результата, а не те, что приведут к 5%. Действуйте с умом и по ситуации.
Отдельно хочется подчеркнуть: Помните! Хуже, полного пренебрежения безопасностью может быть только ее имитация, как в том случае с парой студентов и фиктивным PCI DSS-аудитом.
Типичные ошибки небольших компаний
Для мелких компаний характерна ситуация, когда окружение разработки либо Dev-среда оказываются доступны из внешней сети. Это показывает, что на уровне стартапов часто игнорируют необходимость ограничения сетевого доступа к средам разработки и тестовым контурам.
Редко кто удаляет конфиденциальные данные из истории коммитов и меняет скомпрометированные секреты. Эта проблема встречается даже там, где вроде бы внедрен автоматический поиск секретов внутри репозитория, а сами секреты удаляют из исходного кода после обнаружения.
Если секрет попал в репозиторий, а затем его просто удалили из последней версии, это все равно что повесить объявление с паролем на крыльце подъезда. Да, вы его сорвали через 5 минут, но за это время пароль успели сфотографировать несколько человек. Недостаточно просто удалить пароль из текущей версии кода — нужно обязательно заменить его на новый.
Типичные ошибки крупных компаний
В таких компаниях разработчики обычно используют собственный артефакторий зависимостей, но редко проверяют его содержимое.
Важно не только проксировать зависимости, но и фиксировать определенные их версии, проверять их безопасность и отключать автоматическое обновление.
Почему это необходимо?
Артефакторий работает как промежуточное хранилище, в которое сначала загружаются зависимости из внешних источников. Однако недостаточно просто настроить артефакторий как прокси. Необходимо загрузить конкретную версию программы (зависимости, библиотеки), проверить ее на уязвимости и отключить дальнейшее проксирование. Это нужно, чтобы более новые и не проверенные версии не попадали в вашу инфраструктуру автоматически. Так вы гарантируете, что сотрудники используют только проверенные версии программ.
Если оставить доступ во внешнюю сеть открытым, сохраняется возможность подгрузки новых версий, которые никто не проверял на безопасность. НЕ ОТКЛЮЧАТЬ проксирование после проверки — серьезная ошибка, поскольку так в вашу среду может попасть новый уязвимый компонент.
Часто в компаниях с уже внедренным процессом DevSecOps не контролируется доступ к редактированию правил сканирования. Например, опасный дефект может быть пропущен просто потому, что разработчик вместо исправления уязвимости изменил настройки инструмента, и теперь сканер эту проблему больше не обнаруживает.
Еще одна типичная ошибка крупных компаний — отсутствие централизованных хранилищ информации о найденных дефектах. Большинство хранит результаты проверок различных инструментов в разных системах. Это существенно усложняет оценку динамики изменения защищенности проекта, поскольку специалистам приходится вручную собирать и анализировать разрозненные данные.
Практические советы по организации процессов безопасной разработки
Так много разнообразных ошибок возникает потому, что о безопасной разработке задумываются далеко не сразу. Это и отличает реальность от теории, которую так часто описывают в методичках.
Компании сначала фокусируются на том, как заработать, и лишь потом — как не потерять заработанное из-за уязвимостей в процессах. Поэтому далее мы сосредоточимся на том, как внедрить безопасные практики в уже идущую разработку, ведь это вполне реально сделать на этапе создания новой функциональности или при доработке существующей.
Разберем поэтапно весь процесс на конкретном примере.
Допустим, нам пришла идея добавить в проект капчу, которая будет появляться после авторизации для предотвращения перебора паролей, вместо блокировки количества запросов с одного IP-адреса.
Модель угроз. Под новую фичу необходимо смоделировать угрозы, определяющие потенциальные риски для проекта — ведь если этого не сделать, неясно, от чего защищаться. Выстраивание процесса больше походит на выстрел наугад, чем на выверенные действия.
Анализ измененной архитектуры. Архитектору предстоит проанализировать, а возможно и скорректировать, так как новая функция повлияет на всю архитектуру сервиса авторизации. Если этого не сделать, то все усилия по анализу дефектов в исходном коде пойдут прахом, так как утечка произойдет из-за «дыры» в архитектуре проекта, на которую разработчики не могут повлиять.
Документирование. Затем следует написать техническое задание с учетом механизмов безопасности и передать его руководителю проекта, который направит задачу в разработку.
Применение линтеров и плагинов безопасности. Когда разработчик приступает к работе над кодом, в его среде разработки уже должны быть установлены плагины, сигнализирующие о безопасности изменяемых файлов — например, специальные линтеры, подсвечивающие проблемы безопасности, или плагины, проводящие минимальный SAST на машине разработчика.
Secrets Detection. При попытке загрузить написанный код в репозиторий должны сработать pre-commit хуки, проверяющие код на наличие секретов. Если секрет обнаружен, хуки блокируют загрузку в репозиторий до тех пор, пока разработчик не уберет секретные данные из кода.
Тестирование Docker-образов. После попадания кода в репозиторий запускается CI/CD-процесс, который собирает код в единую сущность (например, Docker-образ) и направляет на DEV-окружение. Docker-образ тоже нужно автоматизированно проверить на наличие дефектов безопасности.
Автоматизированный анализ кода на дефекты безопасности. Код в системе контроля версий должен проверяться различными инструментами безопасности на секреты и конфигурацию, подвергаться SAST, DAST, а также проходить фаззинг-тестирование.
Композиционный анализ. Необходимо провести инвентаризацию внешних зависимостей в коде и проверить их на наличие уязвимостей.
Анализ безопасности Docker-контейнера. В процессе сборки Docker-контейнера нужно проверить его и создать файл инвентаризации, поскольку во время сборки могли подтянуться новые зависимости с новыми уязвимостями. Также на этом этапе следует создать цифровую подпись контейнера, подтверждающую его проверку. При развертывании в окружениях Dev/Stage/Prod необходимо проверять цифровую подпись, чтобы убедиться, что запускается именно проверенный контейнер, а не подмененный.
Анализ безопасности в функционирующем приложении. Когда Docker-контейнер попадает в DEV-окружение или Kubernetes-кластер, в идеале должен работать runtime-снапшот, отслеживающий сетевой трафик внутри Kubernetes и сообщающий об аномалиях при подозрительном поведении контейнера. Также важно мониторить весь трафик, идущий на программную среду. После полного запуска на DEV-контуре можно провести дополнительные виды тестирования, такие как веб-фаззинг и динамический анализ.
Проделав все вышеописанные шаги и обкатав алгоритм, его можно смело, но поэтапно масштабировать на другие задачи, стоящие перед разработкой, а затем и на целые проекты.
Правильно выстроенный процесс обеспечивает проверку кода на каждом промежуточном этапе и упрощает поиск уязвимостей как в самом коде, так и в используемых зависимостях. Он сокращает время до выхода ПО в продуктив за счет уменьшения количества доработок на поздних этапах проекта и в конечном счете снижает общую стоимость разработки.
Это ли не чудо?!
А если серьезно, то выстроить этот процесс правильно возможно только с помощью продуманного сочетания организационных и технических мер и список выше не эталон. Универсальной таблетки нет, и вам нужно найти свои 20% усилий.
Организационные аспекты внедрения DevSecOps
Прежде всего хочется заострить внимание на том, что многие компании внедряют процессы безопасной разработки хаотично, без плана. Такое часто случается, когда DevSecOps появляется по инициативе отдельного сотрудника, а не как часть официальной стратегии компании. Стоит этому энтузиасту уйти — и все, безопасная разработка сходит на нет. Нет регламента — нет и обязанности его соблюдать.
Подобная проблема относится к любым процессам, которые должны работать независимо от конкретных людей, но в нашем случае она особенно остра. DevSecOps быстро коллапсирует без должной регламентации и насаждения ИБ-культуры.
Хорошая практика — ввести знакомство каждого нового сотрудника компании с информационной безопасностью — точно так же, как его знакомят с пожарной безопасностью и правилами использования электросети в первые недели работы. Уже на этапе онбординга нужно рассказать, как в компании выстроены процессы безопасной разработки, что разрешено делать, а чего следует избегать. Очень полезны краткие памятки.
Роль security-чемпионов в команде
В командах разработки стоит выделять (или привлекать со стороны) сотрудников, заинтересованных в безопасности, чтобы сделать из них security-чемпионов. Именно они будут отвечать за безопасность проекта и выстраивать процесс по принципу «разработка ведет разработку».
Представьте компанию с 1000 сотрудников и 100 командами разработки. Она физически не найдет 100 апсеков (от AppSec — Application Security) для анализа безопасности каждого проекта. Честно говоря, даже 10 апсеков найти сложно — рынок таких специалистов сейчас совсем небольшой. Поэтому нужно повышать эффективность имеющейся команды безопасности.
Тут и приходят на помощь security-чемпионы — обычные разработчики, которые интересуются безопасностью и хорошо знают свой проект. Они частично работают как апсеки, частично как разработчики, разгружая этим команду безопасности и ускоряя исправление дефектов. Именно такому человеку, а не случайному разработчику, служба ИБ передает отчет о найденных в коде уязвимостях.
Чтобы вырастить security-чемпионов в компании, отдел Application Security может проводить обучающие мероприятия и митапы, или, что еще эффективнее, записать видеоролики, которые экономят время всех участников.
Когда вы выявите в командах разработки людей с интересом к безопасности, стоит отправлять их на дополнительное обучение, подкрепляя это материальными бонусами. Так вы обеспечите их нужными знаниями, которые помогут вам выстроить процессы безопасной разработки внутри компании.
Технические меры обеспечения безопасности разработки
Внедрение DevSecOps в компании — это целый комплекс мероприятий, в каждом из которых применяется свой чемодан технологий, и для раскрытия этой темы нужна отдельная статья. Нет универсального набора инструментов, подходящего всем компаниям и всем проектам.
Однако мы можем обозначить типы решений! Вот тот минимум, что должен быть у каждого:
мониторинг, оркестрация, контроль уязвимостей — ASPM;
статический анализ кода — SAST;
динамический анализ приложения — DAST;
внутреннее хранилище зависимостей и артефакторий;
композиционный анализ — OSA/SCA.
Внедрение инструментов указанных выше типов, а также устранение найденных с помощью этих инструментов дефектов безопасности позволит обеспечить начальный уровень зрелости процессов безопасной разработки и не допускать дефекты безопасности до продуктива.
В заключение: DevSecOps — это марафон, а не спринт
Внедрение безопасной разработки — не разовая акция, а непрерывный процесс, требующий постоянного внимания и развития. Безопасная разработка — это философия организации, требующая и усилий директора, и участия разработчиков.
Внедрять меры и практики безопасности непросто, и часто даже не хочется этим заниматься, но деваться некуда. Компании, которые видят в DevSecOps только модный тренд или галочку для аудиторов, неизбежно сталкиваются с проблемами: от простых уязвимостей до серьезных утечек данных. Наказания за утечки строже год от года.
Но жизнь не стоит на месте! Есть вызовы — значит есть решения! Хочется верить, что в будущем автоматизация DevSecOps-процессов через ASPM-платформы, работающие по модели «DevSecOps как сервис», изменит ситуацию к лучшему. Такие платформы анализируют подключенные репозитории и выдают результаты в виде отчетов по безопасности и верификации дефектов.
DevSecOps as a Service появился около года назад вместе с общемировым трендом на внедрение безопасной разработки. По моим наблюдениям, первопроходцем стал GitLab со своей платформой, предоставляющей такой инструмент из коробки. За ним подтянулся Microsoft с Security в GitHub. Надеюсь, что в этом направлении начнут двигаться и другие компании. Однако пока в продвинутую безопасную разработку в основном инвестируют техногиганты, в то время как остальные продолжают откладывать и совершать одни и те же ошибки.
Возможно, это непопулярная позиция, но я думаю, что мотивировать большинство вкладываться в DevSecOps прямо здесь и сейчас может только государственное регулирование. И регуляторы уже взялись за кнут, засучив рукава.
Недавно оборотные штрафы для юридических лиц составляли сущие копейки. Сегодня они выросли, появился новый, продуманный ГОСТ, регулирующий безопасную разработку. Растет интерес разработчиков и вместе с тем приходит понимание необходимости мероприятий по выстраиванию процесса безопасности при разработке ПО, как механизма защиты бизнеса от штрафов и претензий регуляторов.
Пока требования и штрафы как инструменты регулирования применяются только к акселераторам на госфинансировании и финтеху, подчиняющемуся Центробанку — частные компании этим особо не озабочены. Однако начало положено, и тренд на ужесточение законодательства ясно прослеживается.
Хочешь не хочешь, а скоро всем придется раскатывать DevSecOps — и лучше с самого начала выстраивать его правильно.
Да, путь к зрелому DevSecOps может занять годы, но каждый шаг в этом направлении уже делает ваш продукт защищеннее, а бизнес — устойчивее к киберугрозам. И помните: лучше построить простую, но работающую систему безопасной разработки, чем годами создавать идеальную, которая так и останется на бумаге.
А какие методы безопасной разработки используете вы? Делитесь в комментариях!