Убедитесь, что вы это точно запатчили.

https://www.bleepingcomputer.com/news/security/fbi-reveals-top-targeted-vulnerabilities-of-the-last-two-years/

Выложены доклады DevSecCon24 - 2021
https://www.youtube.com/playlist?list=PLKWDDWZ_ETtDbTF3Xibc2VagzgHbkoKpA

Программа доступна тут
https://www.devseccon.com/devseccon24-2021/

🔶🔷🔴 Mapping of On-Premises Security Controls Versus Services Offered by Major Cloud Providers

By the link below you can find the fifth version of a diagram that started in March 2017, with just AWS and Azure versus On-Premises. The diagram began as an effort to make a translation between the typical on-premises security controls that everybody, more or less, knows what they do and the various services advertised by major public cloud providers. As the cloud providers tend to assign catchy names to products that quite often transcend the initial functionality of the on-prem control, it becomes harder and harder to stay up-to-date on what service does what.

https://www.managedsentinel.com/mapping-of-on-premises-security-controls-versus-services-offered-by-major-cloud-providers/

#aws #azure #gcp

тут важно понимать что сравнение больше про встроенный или собственный функционал. в маркетплейсах платформ решений ИБ довольно много (особенно для "большой тройки")

Kubernetes Overview Diagrams

Небольшой сборник диаграмм в помощь тем, кто начинает разбираться в Kubernetes. Диаграммы есть к архитектуре, workload's, network, storage, resource requests and limits и на картинке вы в частности видите RBAC.

#k8s #ops

Неожиданно 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