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

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/

​​⚡️ Аттестация по-новому

Официально опубликован Порядок организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну, утверждённый приказом ФСТЭК России от 29 апреля 2021 г.
№ 77.
Указанный Порядок будет применяться для аттестации объектов информатизации с 1 сентября 2021 г.

Из интересного:

1. Рассматриваемый Порядок применяется при аттестации:
- ГИС и МИС (приказ ФСТЭК № 17);
- информационных систем управления производством, используемых организациями ОПК (приказ ФСТЭК №31дсп), в том числе автоматизированных систем станков с ЧПУ;
- Защищаемых помещений.
2. В случае если было принято соответсвующее решение, то рассматриваемый Порядок применяется для аттестации:
- ЗОКИИ (приказ ФСТЭК № 239);
- ИСПДн (приказ ФСТЭК № 21);
- АСУ ТП на КВО, потенциально опасных объектах, объектах, представляющих повышенную опасность для жизни и здоровья людей и окружающей природной среды (приказ ФСТЭК № 31).
3. Порядок оперирует следующими сущностями: владелец ОИ, орган по аттестации, аттестационная комиссия, ФСТЭК России.
4. Определен минимальный состав аттестационной комиссии органа по аттестации: руководитель комиссии и менее двух компетентных экспертов.
5. Появилось прямое требование о дистанцировании, изоляции членов комиссии от влияния владельца аттестуемого ОИ.
6. Установлен срок направления владельцу ОИ заключения по результатам аттестационных испытаний и протоколов аттестационных испытаний - 5 рабочих дней с момента утверждения.
7. Описан порядок обжалования выявленных недостатков в ходе аттестации.
8. Установлена обязанность направления органом по аттестации в ФСТЭК России следующих документов: аттестата соответствия, ТП, акта классификации/акта категорирования, ПМИ, заключений и протоколов.
9. Постулируется, что аттестат соответствия будет выдаваться на весь срок эксплуатации ОИ, но периодический контроль аттестованных ОИ должен проводиться не реже 1 раза в два года. Документы по результатам контроля направляются владельцем ОИ в ФСТЭК России.
10. Описан порядок приостановления и возобновления действия аттестата соответствия ФСТЭК России.
11. Установлена обязанность представления органами по аттестации информации об аттестованных ОИ.

ФСТЭК России придумала, как заполучить акт категорирования объекта КИИ, который предоставлять регулятору ранее не требовалось. Интересно, эта информация будет использоваться для выявления правонарушений по ч. 1 ст. 19.7 прим 15 КОАП (Непредставление или нарушение сроков представления в ФСТЭК России, сведений о результатах присвоения объекту критической информационной инфраструктуры Российской Федерации одной из категорий значимости, предусмотренных законодательством в области обеспечения безопасности критической информационной инфраструктуры Российской Федерации, либо об отсутствии необходимости присвоения ему одной из таких категорий).

P.S.: а куда делся пункт 32 Порядка?

Не знаю как вы, а я люблю (и вижу это полезным) периодически возвращаться к статьям, которые уже читал - со временем и с новым опытом порой на одну и ту же информацию начинаешь смотреть и понимать по-другому.

Перечитывал "Service Discovery in Kubernetes - Combining the Best of Two Worlds" и знать это полезно не только для понимания как все устроено и повышения надежности работы системы, но и для повышения уровня безопасности (и там, где Kubernetes не используется вовсе).

Знаю, что в некоторых компаниях над service discovery много что надстраивают в плане безопасности. На пример, момент инвентаризации сервисов, может ли вообще service использоваться в данном окружении, с кем он и как может общаться и т.д. Сам Service Registry обогащается дополнительной информацией, контекстом и становиться немного умнее (но при этом не стоит забывать и об угрозах и атаках связанным с этим).

В разрезе Kubernetes, я бы это сформулировал как управление созданием ресурсов Service через policy engines, контроль применения NetworkPolicy.

P.S. Внутри этой статьи есть классные отсылки на замечательный сайт "Microservice Architecture", где отдельно отмечу раздел Patterns. Правильная безопасность, начинается с правильной архитектуры - иначе все может превратиться в латание дыр и набор костылей ...