Технический директор Palo Alto Networks рассказывает о защите кода в облаке
24 июня 2023 г.В четверг Palo Alto Networks провела ежегодный саммит Code to Cloud Cybersecurity Summit, посвященный облачным технологиям, DevOps и безопасности. Эксперты обсудили тенденции, возможности и проблемы, связанные с программированием и облачными технологиями.
Недавно подразделение 42 компании Palo Alto Networks выпустило отчет об облачных угрозах, в котором говорится, что среднему отделу безопасности требуется шесть дней, чтобы решить проблему безопасности. Исследование State of Cloud-Native Security показало, что 90% организаций не могут обнаруживать, сдерживать и устранять киберугрозы в течение часа. Unit 42 также недавно опубликовал новое исследование угроз API, которое показало, что 14,9% атак в конце 2022 года были нацелены на развертывание в облаке.
Среди спикеров на мероприятии был Ори Сигал, главный технический директор Palo Alto Networks Prisma Cloud, который присоединился к дискуссии о том, как облачная безопасность может быть согласована с агрессивным циклом разработки, в котором работают разработчики.
Перед мероприятием он рассказал TechRepublic о защите процесса разработки программного обеспечения и платформ облачных приложений (CNAPP). (Рисунок А)
Рисунок А
Перейти к:
- CNAPP как платформа
Защита конвейера разработки программного обеспечения
Как общедоступное облако создает уязвимости для CI/CD
Защита цепочки поставок
Prisma Cloud для повышения безопасности CI/CD
Сдвиг влево, чтобы избежать проблемы с гидрой
CNAPP как платформа
TR: Что представляет собой CNAPP (облачная платформа защиты приложений) сейчас? Что подпадает под это знамя и как вы различаете различные подходы к этому, когда речь идет о безопасности DevOps, когда речь идет о… [уменьшении] уязвимостей в приложениях, перемещенных в облако или написанных для облачных сред?
Сигал: Различные компании доходят до того, что их можно считать CNAPP, исходя из их опыта. Некоторые начинали с безопасности контейнеров, например, Twistlock (приобретенный Palo Alto Networks) или Aqua security. Некоторые прибыли… из управления состоянием облачной безопасности. Так что это действительно зависит от того, кого вы спросите. Но мне нравится точка зрения Gartner: акцент делается на целостной облачной безопасности, поэтому речь не идет о «облачной безопасности», «безопасности рабочей нагрузки» или «безопасности кода». Речь идет о предоставлении платформы, которая позволяет вам применять правильные типы элементов управления безопасностью на протяжении всего жизненного цикла разработки, с момента начала написания кода до момента развертывания и мониторинга рабочих нагрузок. И под это определение попадает множество различных категорий продуктов, не все из которых можно было бы непосредственно рассматривать как часть CNAPP.
TR: Какие есть хорошие примеры CNAPP в каскаде или цикле развития? Является ли CNAPP общим термином для любых DevSecOps?
Сигал: Итак, очевидно, сканирование шаблонов инфраструктуры как кода при разработке программного обеспечения, чтобы убедиться, что вы не встраиваете какие-либо риски или неправильные конфигурации слева; выполнение анализа состава программного обеспечения, чтобы избежать или предотвратить риск развертывания [плохого кода или уязвимостей]. Даже статический анализ, который сегодня мы изучаем, но еще не предлагаем, но я думаю, что SAST (статическое тестирование безопасности приложений), DAST (динамическое тестирование безопасности приложений) и IAST (интерактивное тестирование безопасности приложений), все из которых являются безопасностью приложений. тестирования в целом, являются частью этого.
ПОСМОТРЕТЬ: придерживаться традиционной схемы действий — ошибка для облачной безопасности (TechRepublic)
TR: А дальше вправо больше в сторону производства?
Сигал: А затем, когда вы создаете продукт, сканируете и защищаете артефакты, сопровождаете процесс развертывания в облаке, отслеживаете и защищаете рабочие нагрузки во время их выполнения. И это включает в себя защиту во время выполнения, WAF (брандмауэр веб-приложений), безопасность [интерфейса программирования приложений] и вещи, которые на самом деле больше связаны с центрами управления безопасностью, мониторингом рабочих нагрузок.
Защита конвейера разработки программного обеспечения
ТР: Среди всех этих приложений, подпадающих под действие CNAPP, есть ли область, которая не решается в достаточной мере большинством доступных решений?
Сигал: Да, вдобавок ко всему, и то, что мы в настоящее время изучаем в результате приобретения Cider Security — и что больше всего игнорируется или о чем еще не думали — это безопасность CI/CD (непрерывная интеграция). /continuous development) сам конвейер, который в современных средах разработки сам по себе представляет собой очень сложные и сложные приложения.
ТР: Но разве конвейер CI/CD не является просто бусинками на шее? В чем конкретно заключается различие между конвейером CI/CD и пошаговыми процессами DevOps «код-в-облако»?
Сигал: Это не приложение, которое вы создаете для своих клиентов, а скорее приложение, которое вы используете для создания собственного программного обеспечения; сторонние библиотеки, которые вы используете, например, или если мы используем Jenkins или CircleCI для создания кода и создания артефактов, защищаем ли мы и эти точки? Потому что я могу написать самое безопасное облачное приложение и развернуть его, но если кто-то каким-то образом вмешается в сам конвейер — в мой процесс сборки и развертывания — вся безопасность, которую я встраиваю в свой собственный код, не будет иметь смысла.
TR: Потому что кто-то может просто отравить трубопровод.
Сигал: Они могут внедрять вредоносное ПО, как мы видели в случае с SolarWinds в 2020 году и неоднократно видели в последнее время. Так что это то, что мы также сейчас рассматриваем как часть CNAPP, хотя вы не часто увидите, что это описывается таким образом.
Как общедоступное облако создает уязвимости для CI/CD
TR: Как облачные кодовые базы с открытым исходным кодом и гибридная работа влияют на CI/CD?
Сигал: То, как мы создавали программное обеспечение — я не говорю о языках и фреймворках, я говорю просто о самом процессе сборки — мы запускали управление исходным кодом локально, на сервере, даже не центр, а собственная ИТ-инфраструктура. Мы извлекали и загружали код локально, собирали, а затем записывали его на компакт-диск и отправляли нашим клиентам. Сегодня большинство организаций, с которыми мы работаем, используют какой-либо репозиторий GIT, полностью размещенный в общедоступном Интернете, и используют все больше и больше сервисов для сборки. Jenkins, GitLab, CircleCI, например, большинство из которых используются как платформы сборки как услуги.
ТР: То есть не локальный в каком-то смысле и не защищенный периметром?
Сигал: По сути, весь рабочий процесс в какой-то степени размещается в общедоступном Интернете. Кроме того, разработчики часто используют свои собственные ноутбуки для разработки, часто получая доступ к своим репозиториям GIT через браузер. И если они получат и ответят на фишинговое электронное письмо или другую атаку социальной инженерии, они будут уязвимы для злоумышленника, который манипулирует ими и крадет, например, токены сеанса из браузера, что затем дает злоумышленнику прямой доступ к GitHub. репозиторий. Оттуда они могут начать отравлять процесс развития. Итак, с точки зрения нулевого доверия, мы выявляем самые чувствительные моменты в том, как мы сегодня разрабатываем программное обеспечение, поэтому это не очень хорошо контролируется. Так что нет, периметра больше нет.
Защита цепочки поставок
ТР: С точки зрения защиты цепочки поставок, возвращаясь к другим продуктам, предназначенным для обеспечения гигиены конвейера CI/CD, я знаю продукты, некоторые с открытым исходным кодом, такие как in-toto, которые гарантируют подписи для каждого шага. в процессе разработки, поэтому незаметных и уязвимых точек не осталось.
Сигал: Я просмотрел этот проект. Недавно, несколько месяцев назад, мы приобрели компанию в Израиле, стартап под названием Cider, который был настоящим пионером в этой области. И в рамках этого приобретения мы создаем новый модуль безопасности, который применяет защитные ограждения к конвейеру CI/CD.
TR: Что это дает командам безопасности?
Сигал: Для специалиста по безопасности это «зажигает свет», освещая конвейеры разработки, потому что сегодня группы приложений ИТ-безопасности полностью не в курсе, когда дело доходит до процесса CI/CD, из-за того, что мы изменили от модели водопада к модели доставки, а это означает, что большой процент наших клиентов отправляет код несколько раз в день или несколько раз в неделю. Команды испытывают сильный конкурентный стресс, чтобы каждую неделю разрабатывать и продвигать все больше и больше новых вещей, поэтому разработчики очень заняты функциональностью кодирования. Даже ожидать, что они будут использовать статический анализ кода, немного не так. В этой парадигме группы ИТ-безопасности или безопасности приложений не могут быть узкими местами. Они не могут быть блокаторами; они должны восприниматься как помощь.
ТР: И что это означает на практике?
Сегал: Это означает, что они не могут останавливать процессы для сканирования каждого отправляемого кода. И они определенно не имеют никакого представления о природе конвейеров CI/CD, или о том, куда разработчики помещают код, или о том, что представляют собой артефакты и зависимости, или о том, существуют ли риски, например, сборка как... сервисные плагины имеют доступ к коду.
ТР: Под «артефактами» вы подразумеваете двоичные файлы?
Сигал: Это могут быть двоичные файлы, образы контейнеров, код бессерверных функций и даже образы EC2 (платформа облачных вычислений Amazon). Он включает в себя все сторонние пакеты, обычно упакованные в виде изображений или функций, готовых к отправке в облако.
Palo Alto Networks Prisma Cloud для повышения безопасности CI/CD
ТР: Итак, вы выпускаете продукт Palo Alto Prisma Cloud, специально предназначенный для защиты CI/CD.
Сигал: Да, мы планируем добавить модуль безопасности CI/CD на платформу Prisma Cloud, чтобы защитить цепочку поставок программного обеспечения. Вы начинаете с адаптации своих облачных учетных записей, репозиториев кода, процессов сборки. И тогда мы начинаем сканировать все. Мы отсканируем ваш код слева. Мы будем сканировать эти связанные артефакты — например, образы контейнеров — когда они будут созданы, и применим защиту во время выполнения справа. И всем этим управляет и управляет команда Cloud Security, которая отвечает за сквозной процесс для всего, пока вы не переместите его в облако. Он обеспечивает безопасность облачной учетной записи, гарантируя, что у вас нет активов с рисками, развернутых в облаке.
SEE: почему облачная безопасность имеет проблему «лес для деревьев» (TechRepublic)
ТР: Очевидно, что смещение влево имеет первостепенное значение, потому что, как только вы развернете в облаке дефектные или уязвимые кодовые базы, вы создадите гидру, верно?
Сигал: Одна строка кода, например, в файле, который вы пишете, попадает в репозиторий, который может генерировать несколько образов контейнеров, которые развертываются во многих, многих разных кластерах в нескольких облачных учетных записях. И поэтому, если бы вы играли в такую «убей крота» и атаковали проблему справа, вам пришлось бы исправлять и исправлять тысячи экземпляров одной и той же проблемы.
Как Palo Alto Networks избегает «проблемы гидры»
ТР: Если вы ждете, пока она уже не появится, вы имеете дело не с одной проблемой, а с тысячами.
Это становится распространенной проблемой. Как это исправить?
Сигал: Подумайте об этом так: вы сделали ошибку в коде функциональности корзины покупок в своем приложении, которое теперь развернуто в 5000 контейнеров, которые работают с резервированием для поддержки трафика в нескольких облаках — Google Cloud, AWS, Azure, что угодно — в нескольких регионах. Теперь вы получаете предупреждение о сканировании со стороны среды выполнения, в котором говорится, что у вас есть 5000 уязвимых экземпляров. Если ваша платформа достаточно интеллектуальна, вы можете полностью сопоставить ее с этой плохой строкой кода и с этим конкретным кодом, сделанным этим конкретным разработчиком. Вы можете открыть тикет этому разработчику, чтобы исправить проблему и решить ее в этих тысячах случаев. Кроме того, вы захотите расставить эти проблемы по приоритетам: допустим, вы смотрите на результаты на уровне кода и видите тысячу проблем, которые нужно исправить. Как узнать, какая проблема самая серьезная? Если у вас теперь есть информация из реальной среды, вы можете идентифицировать уязвимый код, используемый в производственной критически важной среде, а не проблему, которая существует только в вашей тестовой среде, которая не так серьезна и, безусловно, не представляет неминуемой угрозы. Это те вещи, которые CNAPP предположительно позволяет вам делать.
ТР: Ну, это очень важно, потому что потенциально экономит много времени?
Сигал: Верно, потому что существуют миллионы потенциальных зависимостей, и на самом деле вам нужно сосредоточиться только на тех, которые важны. Наличие этой видимости во время выполнения, а не только взгляд на статическую сторону, может иметь большое значение. Например, в Prisma Cloud наша функция Cloud Workload Protection регистрирует, какие программные пакеты фактически загружены в память в запущенных контейнерах. А это золото. Эти данные — именно то, что вам нужно, чтобы знать, как расставить приоритеты, что вы хотите исправить в первую очередь.
Оригинал