13 октября на вебинаре «Дыры и заборы: Безопасность в Kubernetes» встретились эксперты Марсель Ибраев, Максим Мошаров и Артём Юшковский. Обсудили, как обезопасить свой кластер, показали три кейса взлома Kubernetes и рассказали, как строить безопасность в организации.
Артём Юшковский — MLOps and K8s security engineer, партнер компании Whitespots.io. Артём обучал сотрудников Kubernetes, разрабатывал защищенные решения на базе Kubernetes, тестировал безопасность для компаний.
Провёл вебинар Марсель Ибраев, технический директор Слёрма.
Первый хакер —американец Кевин Митник. Одно из его громких дел: взломать домашний компьютер Цутому Симомуры, ведущего американского специалиста по компьютерной безопасности. Он взламывал исключительно ради своего любопытства и веселья. Был приговорён к году тюрьмы не строгого режима и принудительному лечению от «компьютерной зависимости».
В СССР был свой первый хакер, Мурат Уртембаев из Казахстана. Он хотел восстановить справедливость: на АвтоВАЗе обещали повысить его и увеличить зарплату, но не сдержали слово. Он саботировал сборку: разработал патч к основной программе-счётчику, которая отмеряет циклы подачи узлов на линию конвейера. Ритм счётчика сбивался и заданная деталь поступала на конвейер с опозданием. Получил 1,5 года условно. Его поймали исторически первые безопасники:
Эти ребята, в отличие от хакеров, на фото не улыбаются. IT-безопасностью сначала занимались КГБ.
У специалистов по ИБ копился опыт, формировались чек-листы, но хакеры всё равно были хитрее. В итоге безопасник уже и заблокировал интернет разработчикам, и ПК к столу привинтил и опечатал, а хакер взял и прислал фишинг финансистам, например.
Итак, паттерн «всё запретить» не работает, известные практики не работают, что делать? Безопасник идет к своему коллеге, у которого всё хорошо. Но товарищ говорит «смотри к себе в тетрадку и не списывай». Ведь у него другой бюджет, другие кадры и другие условия. Можно подсмотреть идею, но копировать практику вслепую — плохая затея. Необходимо учитывать специфику процессов компании, иначе получится карго-культ.
Еще одна проблема — парк технологий постоянно растёт, безопаснику приходится быть фулл-стеком. Нужно знать, как настроить фреймворки, чтобы они стали безопасными, и как ни в коем случае нельзя настраивать, чтобы они оставались защищенными.
Знать всё невозможно, и у нас появляется третья проблема: кадровая. Специалистов мало, и денег они хотят много.
В итоге современный безопасник становится наставником. Опираясь на его рекомендации, бизнес сам анализирует риски внедряемых фич, разработка сама пишет безопасный код, тестировщики сами ищут уязвимости, DevOps-инженеры сами организуют безопасный деплоймент. Это идеальный мир, к которому многие стараются идти.
С так называемыми «белыми» хакерами, которые помогают компаниям, всё ещё хуже. Если у безопасников сформировались паттерны, практики и структура, то у белых хакеров две категории: те, кто будет любые уязвимости эскалировать и угонит контроль над кластером, и те, кто пришлёт вам в Bug Bounty невалидные вещи. Bug Bounty — программа, где регистрируется компания и просит хакеров присылать уязвимости за деньги. Сейчас туда приходят не хакеры, а те, кто хочет легко заработать денег и нажиться на уязвимостях.
В итоге бедный инженер, который поддерживает программу на Bug Bounty платформе, видит по 20 новых невалидных репортов в день и пытается в них отыскать что-то важное, чтобы отправить на устранение в бизнес и разработку.
Марсель: ты интересно акцентировал внимание на том, что краеугольный камень безопасности — люди. Действительно ли человеческий фактор настолько страшен?
Максим: Хакер действительно в первую очередь обращает внимание на то, кто работает в компании. Точка входа взлома часто сотрудники: любой инженер, финансист или эйчар. Человеку могут скинуть ссылку с приглашением, в том числе, на вебинар. И это будет фишинг. Атакующий попробует поэксплуатировать уязвимость в браузере, получит доступ на машину жертвы и станет для системы хоть бухгалтером, хоть разработчиком, которому нужно зайти в прод.
Артём: Первый кейс про тип атаки на Kubernetes, когда у атакующего есть доступ на кластер и он хочет выйти за пределы K8s. Например, прочитать сертификаты, которыми аутентифицируют друг друга компоненты кластера, или сходить напрямую в etcd, или в обход Kube API, обратиться к среде выполнения контейнеров: Docker, CRI-O, и т.д. Всё это может быть доступно из привилегированных подов. Администраторы кластера должны быть крайне осторожны, разрешая создание таких подов.
Скрипт атаки: https://github.com/Slurmio/webinar-seck8s/tree/main/01-privileged-pods
Видео: https://www.youtube.com/watch?v=koTqZS-ThZ8&t=1205s
Марсель: Если вы давно работаете с Кубернетес, наверняка знаете, что в дефолтном сетапе он дает запускать всё, что угодно. Это серьёзный вектор атаки: человек, имея доступ только к запуску pod'ов, может сделать с кластером что захочет. И не только с кластером. На мой взгляд, хорошее решение — использовать policy engines, валидировать все, что создается в кластере Кубернетес. Самый распространенный policy engine — OpenPolicy Agent. Про него и другие policy engines более подробно поговорим на интенсиве.
Артём: Второй кейс взлома кластеров Kubernetes описывает распространенный класс атак, где точка входа в кластер — компонент Kubernetes, например, случайно открытая веб-админка dashboard. К сожалению, это очень распространенная точка входа, достаточно посмотреть отчёты от Azure Security Center за три года, где описаны типичные крупномасштабные атаки, обнаруженные на кластера AKS. Чаще всего цель атаки — вычислительные ресурсы кластера: запуск майнеров, особенно на кластерах Kubeflow, богатых GPU-ресурсами. Но иногда атакующие целились на данные приложений. Пример одной из таких атак в июне 2021 г, мы показываем на вебинаре: атакующий, не имея никакого доступа на кластер, находит случайно открытый Kubernetes dashboard, и в нем читает чувствительные данные, которые по неосторожности пишутся одним из Django-серверов в debug-режиме прямо в stdout.
Скрипт атаки: https://github.com/Slurmio/webinar-seck8s/tree/main/02-exposed-dashboard
Видео: https://youtu.be/koTqZS-ThZ8?t=1983
Даже если мы полностью закрыли Kubernetes от всего мира, у атакующего все ещё есть ряд возможностей атаковать кластер. Об этом — третий кейс, мораль которого: не забывайте про Application Security. В этом блоке мы показываем, как внешний атакующий, не имеющий никаких прав на кластер, может их получить, проэксплуатировав ряд уязвимостей приложений, прочитав Service Account токен с повышенными привилегиями и залив шелл на веб-сервер. В итоге — майнер в кластере или DoS веб-приложения.
Примечание: мы специально сконструировали искусственный кейс уязвимого веб-приложения с множеством дыр безопасности, чтобы проиллюстрировать широкие возможности их эксплуатации. Конечно, в реальном мире атаки не столь прямолинейны.
Скрипт атаки: https://github.com/Slurmio/webinar-seck8s/tree/main/03-application-security
Видео: https://youtu.be/koTqZS-ThZ8?t=2863
Марсель: Когда смотришь кейсы в лабораторных условиях, кажется, что в жизни такого не бывает. Реально ли, чтобы такое количество очевидных ошибок совпало в одной истории?
Максим: Именно так и происходит. Мы однажды делали аудит, нашли доступ к тестовому стенду, через него бродили везде на дефолтовых паролях. Получили пользователя на сервере базы данных, смотрим, а там ещё десять таких же свежесозданных пользователей, о которых компания не знает. Месяц прошёл после деплоя приложения, а там уже поселились и майнят.
Марсель: Много активных хакеров, которые сканируют порты. Чего стоят слитые кластера Elastic'а. У меня был случай: в 2020 году я готовил практику к Вечерней Школе Kubernetes на хостинге Scaleway. Поднимал виртуалку, надо было Docker-утилитой присоединиться к Docker-хосту на другом сервере. Я думал: сейчас быстренько всё сделаю и закрою доступ. Выставил Docker socket в локальную сеть внутри облака, с другой виртуалки подключился, прогнал пайплайны. Через семь минут вижу, что у меня запустился контейнер с именем «Ubuntu-что-то там», который я не запускал. В нём был mount хостовой системы, попытки подмены файла shadow, подмены рутовых SSH-ключей. Всё так быстро произошло. Казалось, ну кому мы нужны, никто не заметит, а видимо автоматика работает.
Максим: У theprojectdiscovery есть сканеры subfinder и nuclei. Одна команда ищет все поддомены, а вторая — админки от Куба на них. Автоматизировать поиск достаточно легко, поэтому активных хакеров уже много и будет еще больше.
Марсель: Дальше по логике, если мы рассматриваем микросервисную архитектуру, идёт сборка image. Есть расхожее мнение, что Docker Hub дырявый. Я смотрю отчёты компании SNYK, в которых они публикуют самые зараженные образы из Docker Hub, количество уязвимостей периодически зашкаливает за сотни. Возникает вопрос: что брать за базовый образ? Или собирать свой?
Максим: Есть вариант сканировать, тем же SNYK. Но вы увидите только известные ошибки. Для проактивной защиты лучше сочетать с другой практикой. Мы у себя пересобираем образы, строим их от apline и без root пользователя. Взять такую практику и отмасштабировать на компанию не быстро, но очень полезно — будете точно знать, что внутри образа. Основная проблема — пропадет поддержка. Если у вас всё апдейтилось официально, теперь придется пересобирать почаще.
Артём: Правила для безопасной сборки продакшн-имэджэй: не хранить build tools на продакшн-образах, использовать свои image registry, со своим ограничением прав, и т.д..
Марсель: Дальше появляются абстракции — напрямую контейнер из имейджа не запускается. Манифесты в Кубернетес надо тоже валидировать и проверять. Сейчас набирают популярность решения Policy Engine, они позволяют валидировать количество реплик и хосты ингресса на этапе CI/CD. И вот начинается рантайм, есть ли тут какие-то практики по безопасности?
Максим: Отвечу с точки зрения процессов: стоит научить саппорт работать с ситуациями, когда тикет с вопросом от пользователя содержит слова SQL-инъекция, RCE, уязвимость. О них нужно сообщать в отдел безопасности.
Белый ящик — дать доступ к коду. Если очень страшно за код, сначала пройдите селф-аудит: в интернете полно сканеров: trufflehog, gitleaks, trivy, bandit. После этого отдавайте на сторонний аудит.
Не забудьте после завершения работы забрать учётки у тех, кто с вами больше не работает.
Марсель: Я знаком с внутренней кухней некоторых популярных российских провайдеров и могу сказать, что там все безопасно настроено: изолированы мастера, даже с запущенными привилегированными контейнерами просто так не получишь доступ. Но надо понимать, что это поддерживают люди.
Артем: Не хочется это признавать, но чем старше технология, организация или продукт, тем больше требований к безопасности: больше пройдено аудитов и собрано сертификатов соответствия.
Артём: Если пойти не вверх на бизнес, а вниз на разработчиков, хорошо донести: ограничения по безопасности — не то, что мешает жить, а то, что помогает бизнесу. Чтобы разработчики понимали ценность требований, покажите им, какие могут быть потери — тогда они будут на вашей стороне.
Максим: Внутри команды могут быть заинтересованные в безопасности Секьюрити Чемпионы — «лучшие друзья» безопасника, с которыми он может делиться практиками, обучать. Уровень безопасности в компании действительно повышается с их появлением.
Чтобы держать руку на пульсе, нужно выстраивать измеримые процессы. Если у представителя бизнеса есть кейсы, когда уязвимости репортились и не закрывались, стоит посмотреть на метрику риск-тренда. Её можно поставить на бизнес как KPI. Тогда работать с безопасностью и безопасниками станет проще. Про это расскажем на интенсиве.
Марсель: Бывает сложно донести до руководства, что безопасность — правда важно. Мы готовы подключиться к переговорам. Зайдите на лендинг интенсива, нажмите «Записаться на консультацию», мы свяжемся с вами и организуем встречу с с коллегами из Whitespots.io, где поможем объяснить, как построить мостик между безопасностью и эксплуатацией.
habr.com
Кто эксперты
Максим Мошаров — СЕО и фаундер компании Whitespots.io и отличный технический специалист: сократил внедрение appsec-процессов в компаниях до одного квартала и обучил более тысячи инженеров практикам ИБ.Артём Юшковский — MLOps and K8s security engineer, партнер компании Whitespots.io. Артём обучал сотрудников Kubernetes, разрабатывал защищенные решения на базе Kubernetes, тестировал безопасность для компаний.
Провёл вебинар Марсель Ибраев, технический директор Слёрма.
Как ломают Kubernetes
Максим: На моей практике главная проблема — человеческий фактор. Иногда сказать «не надо эту админку или API выставлять на всеобщее обозрение» — достаточно, чтобы избежать взлома. Админка, открытая API-шка, забытый порт — самое то для взлома. Сегодня мы поговорим о том, как обезопасить свой кластер, но сначала обсудим первых хакеров, проблемы информационной безопасности и разберём кейсы взлома Kubernetes.
Первый хакер —американец Кевин Митник. Одно из его громких дел: взломать домашний компьютер Цутому Симомуры, ведущего американского специалиста по компьютерной безопасности. Он взламывал исключительно ради своего любопытства и веселья. Был приговорён к году тюрьмы не строгого режима и принудительному лечению от «компьютерной зависимости».
В СССР был свой первый хакер, Мурат Уртембаев из Казахстана. Он хотел восстановить справедливость: на АвтоВАЗе обещали повысить его и увеличить зарплату, но не сдержали слово. Он саботировал сборку: разработал патч к основной программе-счётчику, которая отмеряет циклы подачи узлов на линию конвейера. Ритм счётчика сбивался и заданная деталь поступала на конвейер с опозданием. Получил 1,5 года условно. Его поймали исторически первые безопасники:
Эти ребята, в отличие от хакеров, на фото не улыбаются. IT-безопасностью сначала занимались КГБ.
У специалистов по ИБ копился опыт, формировались чек-листы, но хакеры всё равно были хитрее. В итоге безопасник уже и заблокировал интернет разработчикам, и ПК к столу привинтил и опечатал, а хакер взял и прислал фишинг финансистам, например.
Итак, паттерн «всё запретить» не работает, известные практики не работают, что делать? Безопасник идет к своему коллеге, у которого всё хорошо. Но товарищ говорит «смотри к себе в тетрадку и не списывай». Ведь у него другой бюджет, другие кадры и другие условия. Можно подсмотреть идею, но копировать практику вслепую — плохая затея. Необходимо учитывать специфику процессов компании, иначе получится карго-культ.
Еще одна проблема — парк технологий постоянно растёт, безопаснику приходится быть фулл-стеком. Нужно знать, как настроить фреймворки, чтобы они стали безопасными, и как ни в коем случае нельзя настраивать, чтобы они оставались защищенными.
Знать всё невозможно, и у нас появляется третья проблема: кадровая. Специалистов мало, и денег они хотят много.
В итоге современный безопасник становится наставником. Опираясь на его рекомендации, бизнес сам анализирует риски внедряемых фич, разработка сама пишет безопасный код, тестировщики сами ищут уязвимости, DevOps-инженеры сами организуют безопасный деплоймент. Это идеальный мир, к которому многие стараются идти.
С так называемыми «белыми» хакерами, которые помогают компаниям, всё ещё хуже. Если у безопасников сформировались паттерны, практики и структура, то у белых хакеров две категории: те, кто будет любые уязвимости эскалировать и угонит контроль над кластером, и те, кто пришлёт вам в Bug Bounty невалидные вещи. Bug Bounty — программа, где регистрируется компания и просит хакеров присылать уязвимости за деньги. Сейчас туда приходят не хакеры, а те, кто хочет легко заработать денег и нажиться на уязвимостях.
В итоге бедный инженер, который поддерживает программу на Bug Bounty платформе, видит по 20 новых невалидных репортов в день и пытается в них отыскать что-то важное, чтобы отправить на устранение в бизнес и разработку.
Марсель: ты интересно акцентировал внимание на том, что краеугольный камень безопасности — люди. Действительно ли человеческий фактор настолько страшен?
Максим: Хакер действительно в первую очередь обращает внимание на то, кто работает в компании. Точка входа взлома часто сотрудники: любой инженер, финансист или эйчар. Человеку могут скинуть ссылку с приглашением, в том числе, на вебинар. И это будет фишинг. Атакующий попробует поэксплуатировать уязвимость в браузере, получит доступ на машину жертвы и станет для системы хоть бухгалтером, хоть разработчиком, которому нужно зайти в прод.
Артём: Первый кейс про тип атаки на Kubernetes, когда у атакующего есть доступ на кластер и он хочет выйти за пределы K8s. Например, прочитать сертификаты, которыми аутентифицируют друг друга компоненты кластера, или сходить напрямую в etcd, или в обход Kube API, обратиться к среде выполнения контейнеров: Docker, CRI-O, и т.д. Всё это может быть доступно из привилегированных подов. Администраторы кластера должны быть крайне осторожны, разрешая создание таких подов.
Скрипт атаки: https://github.com/Slurmio/webinar-seck8s/tree/main/01-privileged-pods
Видео: https://www.youtube.com/watch?v=koTqZS-ThZ8&t=1205s
Марсель: Если вы давно работаете с Кубернетес, наверняка знаете, что в дефолтном сетапе он дает запускать всё, что угодно. Это серьёзный вектор атаки: человек, имея доступ только к запуску pod'ов, может сделать с кластером что захочет. И не только с кластером. На мой взгляд, хорошее решение — использовать policy engines, валидировать все, что создается в кластере Кубернетес. Самый распространенный policy engine — OpenPolicy Agent. Про него и другие policy engines более подробно поговорим на интенсиве.
Артём: Второй кейс взлома кластеров Kubernetes описывает распространенный класс атак, где точка входа в кластер — компонент Kubernetes, например, случайно открытая веб-админка dashboard. К сожалению, это очень распространенная точка входа, достаточно посмотреть отчёты от Azure Security Center за три года, где описаны типичные крупномасштабные атаки, обнаруженные на кластера AKS. Чаще всего цель атаки — вычислительные ресурсы кластера: запуск майнеров, особенно на кластерах Kubeflow, богатых GPU-ресурсами. Но иногда атакующие целились на данные приложений. Пример одной из таких атак в июне 2021 г, мы показываем на вебинаре: атакующий, не имея никакого доступа на кластер, находит случайно открытый Kubernetes dashboard, и в нем читает чувствительные данные, которые по неосторожности пишутся одним из Django-серверов в debug-режиме прямо в stdout.
Скрипт атаки: https://github.com/Slurmio/webinar-seck8s/tree/main/02-exposed-dashboard
Видео: https://youtu.be/koTqZS-ThZ8?t=1983
Даже если мы полностью закрыли Kubernetes от всего мира, у атакующего все ещё есть ряд возможностей атаковать кластер. Об этом — третий кейс, мораль которого: не забывайте про Application Security. В этом блоке мы показываем, как внешний атакующий, не имеющий никаких прав на кластер, может их получить, проэксплуатировав ряд уязвимостей приложений, прочитав Service Account токен с повышенными привилегиями и залив шелл на веб-сервер. В итоге — майнер в кластере или DoS веб-приложения.
Примечание: мы специально сконструировали искусственный кейс уязвимого веб-приложения с множеством дыр безопасности, чтобы проиллюстрировать широкие возможности их эксплуатации. Конечно, в реальном мире атаки не столь прямолинейны.
Скрипт атаки: https://github.com/Slurmio/webinar-seck8s/tree/main/03-application-security
Видео: https://youtu.be/koTqZS-ThZ8?t=2863
Марсель: Когда смотришь кейсы в лабораторных условиях, кажется, что в жизни такого не бывает. Реально ли, чтобы такое количество очевидных ошибок совпало в одной истории?
Максим: Именно так и происходит. Мы однажды делали аудит, нашли доступ к тестовому стенду, через него бродили везде на дефолтовых паролях. Получили пользователя на сервере базы данных, смотрим, а там ещё десять таких же свежесозданных пользователей, о которых компания не знает. Месяц прошёл после деплоя приложения, а там уже поселились и майнят.
Марсель: Много активных хакеров, которые сканируют порты. Чего стоят слитые кластера Elastic'а. У меня был случай: в 2020 году я готовил практику к Вечерней Школе Kubernetes на хостинге Scaleway. Поднимал виртуалку, надо было Docker-утилитой присоединиться к Docker-хосту на другом сервере. Я думал: сейчас быстренько всё сделаю и закрою доступ. Выставил Docker socket в локальную сеть внутри облака, с другой виртуалки подключился, прогнал пайплайны. Через семь минут вижу, что у меня запустился контейнер с именем «Ubuntu-что-то там», который я не запускал. В нём был mount хостовой системы, попытки подмены файла shadow, подмены рутовых SSH-ключей. Всё так быстро произошло. Казалось, ну кому мы нужны, никто не заметит, а видимо автоматика работает.
Максим: У theprojectdiscovery есть сканеры subfinder и nuclei. Одна команда ищет все поддомены, а вторая — админки от Куба на них. Автоматизировать поиск достаточно легко, поэтому активных хакеров уже много и будет еще больше.
Как проверить безопасность своего кластера
Максим: Можно опираться на CIS Benchmark. Но нужно как минимум добавить сканеры в пайплайны, чтобы отрабатывать каждый merge request. Разово CIS — ок, но акцент должен быть больше на автоматизации. Разработчики или администраторы не будут ходить каждый день по здоровым чек-листам.Марсель: Дальше по логике, если мы рассматриваем микросервисную архитектуру, идёт сборка image. Есть расхожее мнение, что Docker Hub дырявый. Я смотрю отчёты компании SNYK, в которых они публикуют самые зараженные образы из Docker Hub, количество уязвимостей периодически зашкаливает за сотни. Возникает вопрос: что брать за базовый образ? Или собирать свой?
Максим: Есть вариант сканировать, тем же SNYK. Но вы увидите только известные ошибки. Для проактивной защиты лучше сочетать с другой практикой. Мы у себя пересобираем образы, строим их от apline и без root пользователя. Взять такую практику и отмасштабировать на компанию не быстро, но очень полезно — будете точно знать, что внутри образа. Основная проблема — пропадет поддержка. Если у вас всё апдейтилось официально, теперь придется пересобирать почаще.
Артём: Правила для безопасной сборки продакшн-имэджэй: не хранить build tools на продакшн-образах, использовать свои image registry, со своим ограничением прав, и т.д..
Марсель: Дальше появляются абстракции — напрямую контейнер из имейджа не запускается. Манифесты в Кубернетес надо тоже валидировать и проверять. Сейчас набирают популярность решения Policy Engine, они позволяют валидировать количество реплик и хосты ингресса на этапе CI/CD. И вот начинается рантайм, есть ли тут какие-то практики по безопасности?
Максим: Отвечу с точки зрения процессов: стоит научить саппорт работать с ситуациями, когда тикет с вопросом от пользователя содержит слова SQL-инъекция, RCE, уязвимость. О них нужно сообщать в отдел безопасности.
Как обезопасить компанию во время стороннего аудита по безопасности
Максим: Есть два вида аудита: чёрный ящик и белый ящик. В чёрном ящике вы ничего не отдаёте. Нас иногда просят найти «что угодно, где сами захотите. Нам интересно узнать, как нас сейчас видит хакер». Аудитор, если он этичный, расскажет про найденные критичные и не очень точки входа.Белый ящик — дать доступ к коду. Если очень страшно за код, сначала пройдите селф-аудит: в интернете полно сканеров: trufflehog, gitleaks, trivy, bandit. После этого отдавайте на сторонний аудит.
Не забудьте после завершения работы забрать учётки у тех, кто с вами больше не работает.
Насколько безопасен Kubernetes у облачных провайдеров?
Максим: Всегда смотрите на реакцию техподдержки. Если они говорят, что проблемы уязвимости — проблемы клиента, делайте выводы. Обращайте внимание на скорость устранения уязвимостей и публикацию отчетов о прохождении анализа защищенности.Марсель: Я знаком с внутренней кухней некоторых популярных российских провайдеров и могу сказать, что там все безопасно настроено: изолированы мастера, даже с запущенными привилегированными контейнерами просто так не получишь доступ. Но надо понимать, что это поддерживают люди.
Артем: Не хочется это признавать, но чем старше технология, организация или продукт, тем больше требований к безопасности: больше пройдено аудитов и собрано сертификатов соответствия.
Как корректно поступить, если разработчик просит больше доступов и привилегий в безопасности?
Максим: У каждой фичи есть своя цена и ценность. Продукт оунер её точно знает. Нужно составить сценарии «что может пойти не так?» и озвучить их. Решение полностью за бизнесом, но можно предложить минимизировать риски.Артём: Если пойти не вверх на бизнес, а вниз на разработчиков, хорошо донести: ограничения по безопасности — не то, что мешает жить, а то, что помогает бизнесу. Чтобы разработчики понимали ценность требований, покажите им, какие могут быть потери — тогда они будут на вашей стороне.
Про интенсив
Марсель: Подытожим. Этот вебинар мы подготовили из вопросов к интенсиву и кейсов, которые хотелось показать. Главная идея: безопасность — дело каждого сотрудникаМаксим: Внутри команды могут быть заинтересованные в безопасности Секьюрити Чемпионы — «лучшие друзья» безопасника, с которыми он может делиться практиками, обучать. Уровень безопасности в компании действительно повышается с их появлением.
Чтобы держать руку на пульсе, нужно выстраивать измеримые процессы. Если у представителя бизнеса есть кейсы, когда уязвимости репортились и не закрывались, стоит посмотреть на метрику риск-тренда. Её можно поставить на бизнес как KPI. Тогда работать с безопасностью и безопасниками станет проще. Про это расскажем на интенсиве.
Марсель: Бывает сложно донести до руководства, что безопасность — правда важно. Мы готовы подключиться к переговорам. Зайдите на лендинг интенсива, нажмите «Записаться на консультацию», мы свяжемся с вами и организуем встречу с с коллегами из Whitespots.io, где поможем объяснить, как построить мостик между безопасностью и эксплуатацией.
Дыры и заборы в Kubernetes: кейсы взлома, советы как защитить свой кластер и рассказ о первых хакерах
13 октября на вебинаре «Дыры и заборы: Безопасность в Kubernetes» встретились эксперты Марсель Ибраев, Максим Мошаров и Артём Юшковский. Обсудили, как обезопасить свой кластер, показали три кейса...
habr.com