Неожиданно NSA совместно с CISA выложили свой документ "Kubernetes Hardening Guidance"!

Там в 59 страницах есть 7 основных разделов:
- Threat model
- Kubernetes Pod security
- Network separation and hardening
- Authentication and authorization
- Log auditing
- Logging
- Upgrading and application security practices

В данном документе вы не найдете никаких откровений, новшеств по сравнению с той же презентацией от DoD. По мне так рядовой документ (за исключением кто его автор) - подобные документы выпускают с разной периодичностью вендоры разных security решений.

Так документ подойдет новичкам, которые только начинают обращать свое внимание на безопасность Kubernetes. Отдельно наверно отмечу раздел Appendix, где собраны различные примеры тех или иных best practices и харденингов.

P.S. Документ похоже долго ждал публикации и там до сих пор рассматривается деприкейтнутая PSP.

Мотивация внутреннего нарушителя может увеличиться.

https://www.bleepingcomputer.com/news/security/lockbit-ransomware-recruiting-insiders-to-breach-corporate-networks/amp/

Threat Modelling & Supply-Chain (Part 3: Security Controls)

В прошлых постах [1,2] мы определили угрозы, которые, как нам кажется, более или менее полно покрывают перечень действий, определенных нами в рамках процессов над активами.

Следующее, что нам нужно сделать - определить меры безопасности (security controls). Здесь два варианта - начать указывать их на каждом процессе или потоке данных в рамках схемы, либо выписать отдельной табличкой напротив каждой нашей угрозы (чтобы убедиться, что мы закрываемся от всего, что сами для себя определили). Говоря более предметно, давайте вернемся к supply chain атакам. В частности возьмем за основу упоминаемый ранее фреймворк SLSA и рассмотрим угрозу компрометации CI/CD системы.

Когда мы говорим про компрометацию системы, то речь, как правило, заходит о полноценности hardening'а этой системы, а именно о таких доменах, как аутентификация, авторизация, сетевая безопасность, конфигурация, логирование и безопасная работа с секретами. Соответственно в этих доменах и пробуем определить полный перечень мер безопасности.

Вот примеры реализации hardening'а для разных решений CI/CD систем:
- Security Practices in GitLab
- Managing Security of Jenkins
- Securing Jenkins CI Systems
- Security hardening for GitHub Actions
- TeamCity Security Notes (лучше всего на мой взгляд сделано здесь)
- CircleCI Security

К мерам защиты CI/CD может относиться ролевая модель, отсутствие анонимной аутентификации, обязательная интеграция с identity-провайдером, запрет на доступ в Интернет для сборки, требование к изолированности агентов от агентов развертывания и обязательному логированию с последующей отправкой в SIEM-систему. Конечный список требований зависит исключительно от возможностей вашей CI/CD системы.

Рассматривая компрометацию системы хранения кода (Gitlab/Bitbucket) и артефактов (Nexus Repo, Artifactory) формируем требования безопасности по аналогии из тех же доменов.

Если мы говорим про supply chain атаки, то помимо компрометации самих систем, участвующих в процессе разработки, отдельное внимание надо уделить угрозе нарушения целостности перемещаемых активов, а именно коду и артефактов. Здесь я советую снова обратиться к SLSA-фреймворку.

Примеры угроз, реализуемых внутренним нарушителем:
- Публикация вредоносного кода в релизную ветку от имени скомпрометированной УЗ разработчика
- Указание в системе сборки кода из чужой системы хранения кода
- Указание в системе развертывания артефакта из чужой системы хранения артефактов
- Загрузка в Artifactory артефакта не прошедшего систему сборки

Обратите внимание, что при отсутствии проверки целостности и прохождения дополнительной аутентификации между системами сборки, хранения кода и артефактов нам необязательно получать полный доступ над системами. Например, достаточно указать неверные входные значения (сторонний git-репозиторий) в качестве параметров сборки, либо опубликовать артефакт в Artifactory вручную через CLI минуя security-проверки в рамках централизованного процесса сборки. Ещё один пример - изменить скрипт развёртывания так, чтобы установить вредоносный дистрибутив в прод вместо проверенного security-сканерами.

В помощь сюда приходят проекты вроде Notary или Sigstore. Кто-то реализует это посредством подписи SBOM на всех этапах разработки, кто-то ограничивается тэгированием артефактов без возможности перезаписи разработчиком. Неплохим требованием безопасности будет обязательный merge-approval для всех бизнесовых репозиториев, чтобы избежать нарушения целостности master/release ветки при компрометации УЗ разработчика.

#dev #ops #threatmodeling

если нужно доступно объяснить что такое шифровальщик для англоязычного коллеги 🙂

еще раз дублируем, что похожего мы встречали

Хорошое соло, женский вокал
https://mobile.twitter.com/racheltobac/status/1352409636792492035

В стиле рэп
https://m.soundcloud.com/user-315163474/cyber-anthem

Если кто-то похожие песни или произведения видел - поделитесь в комментах. Видел ли кто-то подобное на русском?

Слышали песню, которая выиграла Pwnie Award в этом году? The Ransomware Song, прикольная. А Qualys аж в двух номинациях отметились, молодцы.

Вакансии для старта карьеры в Минцифре.

https://job.gosuslugi.ru/